Linus,
The following changes since commit b79013b2449c23f1f505bdf39c5a6c330338b244:
Merge tag 'staging-4.1-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2015-04-13
17:37:33 -0700)
are available in the git repository at:
Christoffer Dall christoffer.d...@linaro.org writes:
On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Bennée wrote:
This adds support for SW breakpoints inserted by userspace.
We do this by trapping all BKPT exceptions in the
hypervisor (MDCR_EL2_TDE).
you mean trapping all exceptions in
2015-04-23 13:46+0200, Paolo Bonzini:
From: Radim Krčmář rkrc...@redhat.com
The kvmclock spec says that the host will increment a version field to
an odd number, then update stuff, then increment it to an even number.
The host is buggy and doesn't do this, and the result is observable
when
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
drivers/net/tun.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 857dca4..3c3d6c0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -206,14 +206,19 @@ struct
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
drivers/net/macvtap.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 27ecc5c..a2f2958 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -49,14
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
include/linux/vringh.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/vringh.h b/include/linux/vringh.h
index a3fa537..3ed62ef 100644
--- a/include/linux/vringh.h
+++
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
drivers/vhost/vhost.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 8c1c792..6a49960 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
On 04/23/2015 02:13 PM, Liang Li wrote:
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Do you have an theory why this is? What does the regression come from?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
include/linux/virtio_config.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index ca3ed78..bd1a582 100644
---
Hi,
This patchset allows vhost to be used with legacy virtio when guest and host
have a different endianness. It is compatible with modern virtio and can be
fully compiled out through kernel config.
FWIW, I could flawlessly kexec/reboot guests from ppc64 to ppc64le and back.
I could also migrate
Currently KVM will clear the FPU bits in CR0.TS in the VMCS, and trap to
re-load them every time the guest accesses the FPU after a switch back into
the guest from the host.
This patch copies the x86 task switch semantics for FPU loading, with the
FPU loaded eagerly after first use if the system
The current memory accessors logic is:
- little endian if little_endian
- native endian (i.e. no byteswap) if !little_endian
If we want to fully support cross-endian vhost, we also need to be
able to convert to big endian.
Instead of changing the little_endian argument to some 3-value enum, this
The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers
that are always little-endian. It can also be used to handle the special
case of a legacy little-endian device implemented by a big-endian host.
Let's add a flag and ioctls for big-endian devices as well. If both flags
are set,
This patch brings cross-endian support to vhost when used to implement
legacy virtio devices. Since it is a relatively rare situation, the
feature availability is controlled by a kernel config option (not set
by default).
The vq-is_le boolean field is added to cache the endianness to be
used for
Am Thu, 23 Apr 2015 17:26:20 +0200
schrieb Greg Kurz gk...@linux.vnet.ibm.com:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
include/linux/virtio_config.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/virtio_config.h
On Thu, Apr 23, 2015 at 02:02:29PM +0200, Paolo Bonzini wrote:
On 23/04/2015 13:51, Marcelo Tosatti wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1174664
That was the missing volatile in an asm. Older compilers didn't catch
it. :(
How do you know that? It looks like
Am Thu, 23 Apr 2015 19:22:15 +0200
schrieb Thomas Huth th...@redhat.com:
Am Thu, 23 Apr 2015 17:26:20 +0200
schrieb Greg Kurz gk...@linux.vnet.ibm.com:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
include/linux/virtio_config.h | 17 +++--
1 file changed, 11
On Thu, 23 Apr 2015 17:26:20 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
include/linux/virtio_config.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/virtio_config.h
On Thu, 23 Apr 2015 17:26:30 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
drivers/net/tun.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 857dca4..3c3d6c0
Commit 47a98b15ba7c (arm/arm64: KVM: support for un-queuing active
IRQs) introduced handling of the GICD_I[SC]ACTIVER registers,
but only for the GICv2 emulation. For the sake of completeness and
as this is a pre-requisite for save/restore of the GICv3 distributor
state, we should also emulate
On 04/23/2015 08:28 AM, Dave Hansen wrote:
On 04/23/2015 02:13 PM, Liang Li wrote:
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Do you have an theory why this is? What does the regression come from?
This is interesting since previous
On Thu, 23 Apr 2015 17:26:52 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
include/linux/vringh.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/vringh.h b/include/linux/vringh.h
On Thu, 23 Apr 2015 17:27:05 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
drivers/vhost/vhost.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
If you try to enable NOHZ_FULL on a guest today, you'll get
the following error when the guest tries to deactivate the
scheduler tick:
WARNING: CPU: 3 PID: 2182 at kernel/time/tick-sched.c:192
can_stop_full_tick+0xb9/0x290()
NO_HZ FULL will not work with unstable sched clock
CPU: 3 PID: 2182
On Thu, 23 Apr 2015 17:26:41 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
drivers/net/macvtap.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index
On Thu, 23 Apr 2015 17:29:06 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
The current memory accessors logic is:
- little endian if little_endian
- native endian (i.e. no byteswap) if !little_endian
If we want to fully support cross-endian vhost, we also need to be
able to convert to
H. Peter Anvin wrote on 2015-04-24:
On 04/23/2015 08:28 AM, Dave Hansen wrote:
On 04/23/2015 02:13 PM, Liang Li wrote:
When compiling kernel on westmere, the performance of eager FPU is
about 0.4% faster than lazy FPU.
Do you have an theory why this is? What does the regression come from?
On 04/23/2015 08:07 AM, Paolo Bonzini wrote:
On 23/04/2015 13:43, Christian Borntraeger wrote:
Couldn't you make this a hidden kconfig option that gets automatically
selected when kvm is enabled? Or is there a non-kvm case that needs it too?
For things like RHEV the default could
On Wed, Apr 22, 2015 at 9:51 AM, Catalin Vasile
catalinvasil...@gmail.com wrote:
On Wed, Apr 22, 2015 at 11:20 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Apr 21, 2015 at 04:07:56PM +0200, Paolo Bonzini wrote:
On 21/04/2015 16:07, Catalin Vasile wrote:
I don't get the part with
On 22/04/2015 23:21, Marcelo Tosatti wrote:
On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote:
On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 17/04/2015 22:18, Marcelo Tosatti wrote:
The bug which this is fixing is very rare, have no memory of a
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Signed-off-by: Liang Li liang.z...@intel.com
Signed-off-by: Xudong
No need to cast the void pointer returned by kmalloc() in
arch/arm/kvm/mmu.c::kvm_alloc_stage2_pgd().
Signed-off-by: Firo Yang fir...@gmail.com
---
arch/arm/kvm/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index
On 23/04/2015 23:13, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
Signed-off-by: Liang
Christoffer Dall christoffer.d...@linaro.org writes:
On Tue, Mar 31, 2015 at 04:08:01PM +0100, Alex Bennée wrote:
This commit defines the API headers for guest debugging. There are two
architecture specific debug structures:
- kvm_guest_debug_arch, allows us to pass in HW debug registers
On 23/04/2015 12:07, Firo Yang wrote:
No need to cast the void pointer returned by kmalloc() in
arch/arm/kvm/mmu.c::kvm_alloc_stage2_pgd().
Signed-off-by: Firo Yang fir...@gmail.com
---
arch/arm/kvm/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Martin Schwidefsky schwidef...@de.ibm.com
Replacing a 2K page table with a 4K page table while a VMA is active
for the affected memory region is fundamentally broken. Rip out the
page table reallocation code and replace it with a simple system
control 'vm.allocate_pgste'. If the system
Paolo, Alex,
we plan to submit this fixup via Martins s390 tree (as it is all in
common s390 memory management).
It fixes a fundamental design bug in our page table handling. Some
background: Normal page tables are 2kb. For KVM we need a special page
table extension that creates another 2k after
On 2015-04-23 12:40, Paolo Bonzini wrote:
On 23/04/2015 23:13, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4%
On 23/04/2015 00:55, Marcelo Tosatti wrote:
On Wed, Apr 22, 2015 at 11:01:49PM +0200, Paolo Bonzini wrote:
On 22/04/2015 22:56, Marcelo Tosatti wrote:
But then why was the task migration notifier even in Jeremy's original
code for Xen?
To cover for the vcpu1 - vcpu2 - vcpu1 case, i
Am 23.04.2015 um 13:37 schrieb Alexander Graf:
Am 23.04.2015 um 13:08 schrieb Christian Borntraeger
borntrae...@de.ibm.com:
From: Martin Schwidefsky schwidef...@de.ibm.com
Replacing a 2K page table with a 4K page table while a VMA is active
for the affected memory region is
Am 23.04.2015 um 13:43 schrieb Christian Borntraeger borntrae...@de.ibm.com:
Am 23.04.2015 um 13:37 schrieb Alexander Graf:
Am 23.04.2015 um 13:08 schrieb Christian Borntraeger
borntrae...@de.ibm.com:
From: Martin Schwidefsky schwidef...@de.ibm.com
Replacing a 2K page table with
Am 23.04.2015 um 14:01 schrieb Alexander Graf:
Am 23.04.2015 um 13:43 schrieb Christian Borntraeger
borntrae...@de.ibm.com:
Am 23.04.2015 um 13:37 schrieb Alexander Graf:
Am 23.04.2015 um 13:08 schrieb Christian Borntraeger
borntrae...@de.ibm.com:
From: Martin Schwidefsky
Am 23.04.2015 um 13:08 schrieb Christian Borntraeger borntrae...@de.ibm.com:
From: Martin Schwidefsky schwidef...@de.ibm.com
Replacing a 2K page table with a 4K page table while a VMA is active
for the affected memory region is fundamentally broken. Rip out the
page table reallocation
From: Radim Krčmář rkrc...@redhat.com
The kvmclock spec says that the host will increment a version field to
an odd number, then update stuff, then increment it to an even number.
The host is buggy and doesn't do this, and the result is observable
when one vcpu reads another vcpu's kvmclock data.
This reverts commits 0a4e6be9ca17c54817cf814b4b5aa60478c6df27
and 80f7fdb1c7f0f9266421f823964fd1962681f6ce.
The task migration notifier was originally introduced in order to support
the pvclock vsyscall with non-synchronized TSC, but KVM only supports it
with synchronized TSC. Hence, on KVM the
On Thu, Apr 23, 2015 at 11:13:23AM +0200, Paolo Bonzini wrote:
On 22/04/2015 23:21, Marcelo Tosatti wrote:
On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote:
On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 17/04/2015 22:18, Marcelo Tosatti
On 23/04/2015 13:51, Marcelo Tosatti wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1174664
That was the missing volatile in an asm. Older compilers didn't catch
it. :(
How do you know that? It looks like memory corruption (look at the
pattern at the end).
I suspect some kind
On 23/04/2015 13:43, Christian Borntraeger wrote:
Couldn't you make this a hidden kconfig option that gets automatically
selected when kvm is enabled? Or is there a non-kvm case that needs it too?
For things like RHEV the default could certainly be enabled, but for normal
distros like
On Thu, 23 Apr 2015 14:01:23 +0200
Alexander Graf ag...@suse.de wrote:
As far as alternative approaches go, I don't have a great idea otoh.
We could have an elf flag indicating that this process needs 4k page
tables to limit the impact to a single process. In fact, could we
maybe still limit
Cc Rik, who is doing the similar work. :)
On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is
On Fri, Apr 24, 2015 at 05:13:03AM +0800, Liang Li wrote:
Romove lazy FPU logic and use eager FPU entirely. Eager FPU does
not have performance regression, and it can simplify the code.
When compiling kernel on westmere, the performance of eager FPU
is about 0.4% faster than lazy FPU.
This adds implementations for the H_CLEAR_REF (test and clear reference
bit) and H_CLEAR_MOD (test and clear changed bit) hypercalls.
When clearing the reference or change bit in the guest view of the HPTE,
we also have to clear it in the real HPTE so that we can detect future
references or
This fixes a bug in the tracking of pages that get modified by the
guest. If the guest creates a large-page HPTE, writes to memory
somewhere within the large page, and then removes the HPTE, we only
record the modified state for the first normal page within the large
page, when in fact the guest
The reference (R) and change (C) bits in a HPT entry can be set by
hardware at any time up until the HPTE is invalidated and the TLB
invalidation sequence has completed. This means that when removing
a HPTE, we need to read the HPTE after the invalidation sequence has
completed in order to obtain
The main purpose of this series is to implement the H_CLEAR_REF and
H_CLEAR_MOD hypercalls defined by PAPR. We are doing this for the
sake of FreeBSD guests as Linux guests don't use them. Along the way
I found a couple of bugs, so the fixes for those are split out as the
first two patches.
The
On 04/23/2015 06:57 PM, Wanpeng Li wrote:
Cc Rik, who is doing the similar work. :)
Hi Liang,
I posted this patch earlier, which should have the same effect as
your patch on more modern systems, while not loading the FPU context
for guests that barely use it on older systems:
This fixes a bug in the tracking of pages that get modified by the
guest. If the guest creates a large-page HPTE, writes to memory
somewhere within the large page, and then removes the HPTE, we only
record the modified state for the first normal page within the large
page, when in fact the guest
The reference (R) and change (C) bits in a HPT entry can be set by
hardware at any time up until the HPTE is invalidated and the TLB
invalidation sequence has completed. This means that when removing
a HPTE, we need to read the HPTE after the invalidation sequence has
completed in order to obtain
This adds implementations for the H_CLEAR_REF (test and clear reference
bit) and H_CLEAR_MOD (test and clear changed bit) hypercalls.
When clearing the reference or change bit in the guest view of the HPTE,
we also have to clear it in the real HPTE so that we can detect future
references or
59 matches
Mail list logo
