On (Mon) 01 Sep 2014 [20:52:46], Zhang Haoyu wrote:
> >>> Hi, all
> >>>
> >>> I start a VM with virtio-serial (default ports number: 31), and found
> >>> that virtio-blk performance degradation happened, about 25%, this problem
> >>> can be reproduced 100%.
> >>> without virtio-serial:
> >>> 4k-
https://bugzilla.kernel.org/show_bug.cgi?id=82211
--- Comment #6 from Paolo Bonzini ---
What version of Xen? Can you attach the xen.gz file?
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
th
On 02.09.2014 12:09, Valentine Sinitsyn wrote:
https://www.dropbox.com/s/slbxmxyg74wh9hv/l1mmio-cpu0.txt.gz?dl=0
Forgot to say: the user space is vanilla QEMU 2.1.0 here.
Valentine
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kerne
From: Paul Mackerras
Occasional failures have been seen with split-core mode and migration
where the message "KVM: couldn't grab cpu" appears. This increases
the length of time that we wait from 1ms to 10ms, which seems to
work around the issue.
Signed-off-by: Paul Mackerras
---
arch/powerpc/
This series of patches is based on Alex Graf's kvm-ppc-queue branch.
It contains 3 small patches from the tree that we are shipping on
POWER8 machines: a fix for an error that we see very occasionally,
and two minor improvements. Please apply for 3.18.
Paul.
---
arch/powerpc/include/asm/kvm_host
This provides basic support for the KVM_REG_PPC_ARCH_COMPAT register
in PR KVM. At present the value is sanity-checked when set, but
doesn't actually affect anything yet.
Implementing this makes it possible to use a qemu command-line
argument such as "-cpu host,compat=power7" on a POWER8 machine,
Since the guest can read the machine's PVR (Processor Version Register)
directly and see the real value, we should disallow userspace from
setting any value for the guest's PVR other than the real host value.
Therefore this makes kvm_arch_vcpu_set_sregs_hv() check the supplied
PVR value and return
Hi Paolo,
On 01.09.2014 23:04, Paolo Bonzini wrote:
Valentine, can you produce another trace, this time with both kvm and
kvmmmu events enabled?
I was able to make the trace shorter by grepping only what's happening
on a single CPU core (#0):
https://www.dropbox.com/s/slbxmxyg74wh9hv/l1mmio-c
https://bugzilla.kernel.org/show_bug.cgi?id=82211
--- Comment #5 from Zhou, Chao ---
kvm.git+ qemu.git:fd275235_8b303011
kernel version:3.17.0-rc1
test on Ivytown_EP
qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -net nic,macaddr=00:13:13:51:51:15
-net tap,script=/etc/kvm/qemu-ifup nested-xen.qcow -
https://bugzilla.kernel.org/show_bug.cgi?id=61411
Zhou, Chao changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this mail bec
https://bugzilla.kernel.org/show_bug.cgi?id=61411
--- Comment #1 from Zhou, Chao ---
kvm.git +qemu.git: fd275235_8b303011
test on Ivytown_EP
kernel version: 3.17.0-rc1
enable ignore_msrs(echo 1>/sys/module/kvm/parameters/ignore_msrs), then create
L1 guest
qemu-system-x86_64 --enable-kvm -m 6G -sm
https://bugzilla.kernel.org/show_bug.cgi?id=61411
Zhou, Chao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 28.08.14 15:13, Radim Krčmář wrote:
> The first patch answers a demand for inline arch functions.
> (There is a lot of constant functions that could be inlined as well.)
>
> Second patch digs a bit into the history of KVM and removes a useless
> argument that seemed suspicious when preparing
On 01.09.14 12:17, Mihai Caraman wrote:
> We currently decide at compile-time which of the SPE or AltiVec units to
> support exclusively. Guard kernel defines with CONFIG_SPE_POSSIBLE and
> CONFIG_PPC_E500MC and remove shared defines.
>
> Signed-off-by: Mihai Caraman
Thanks, applied to kvm-ppc
On 01.09.14 16:19, Mihai Caraman wrote:
> Powerpc timer implementation is a copycat version of s390. Now that they
> removed
> the tasklet with commit ea74c0ea1b24a6978a6ebc80ba4dbc7b7848b32d follow this
> optimization.
>
> Signed-off-by: Mihai Caraman
> Signed-off-by: Bogdan Purcareata
What
Hi Paolo,
On 01.09.2014 23:41, Paolo Bonzini wrote:
Il 21/08/2014 14:28, Valentine Sinitsyn ha scritto:
BTW npt_rsvd does *not* fail on the machine I've been testing on today.
I can confirm l1mmio test doesn't fail in kvm-unit-test's master
anymore. npt_rsvd still does. I also needed to disable
Il 21/08/2014 14:28, Valentine Sinitsyn ha scritto:
>> It seems to work for VMX (see the testcase I just sent). For SVM, can
>> you check if this test works for you, so that we can work on a simple
>> testcase?
>
> However, npt_rsvd seems to be broken - maybe that is the reason?
BTW npt_rsvd doe
Il 20/08/2014 08:46, Valentine Sinitsyn ha scritto:
> Looks like it is a bug in KVM. I had a chance to run the same code
> bare-metal ([1], line 310 is uncommented for bare-metal case but present
> for nested SVM), and it seems to work as expected. However, When I trace
> it in nested SVM setup, af
This will cause problems when accessing memory above the first GB, as
in the l1mmio test.
Signed-off-by: Paolo Bonzini
---
x86/svm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/x86/svm.c b/x86/svm.c
index 1e6908a..00b3191 100644
--- a/x86/svm.c
+++ b/x86/svm.c
@@ -8
The first read will fill the nested page table, the second will find a reserved
bit set.
Signed-off-by: Paolo Bonzini
---
x86/svm.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/x86/svm.c b/x86/svm.c
index cb4c736..1e6908a 100644
--- a/x86/svm.c
+++ b/x86/s
Il 22/08/2014 06:33, Valentine Sinitsyn ha scritto:
> On 22.08.2014 02:31, Paolo Bonzini wrote:
>> VMX used the right access size already, the tests are separate for VMX
>> and SVM.
> Sure. So the bug is NPT-specific?
Hmm, unfortunately the test cannot reproduce the bug, at least with 3.16.
It onl
Powerpc timer implementation is a copycat version of s390. Now that they removed
the tasklet with commit ea74c0ea1b24a6978a6ebc80ba4dbc7b7848b32d follow this
optimization.
Signed-off-by: Mihai Caraman
Signed-off-by: Bogdan Purcareata
---
arch/powerpc/include/asm/kvm_host.h | 1 -
arch/powerpc/i
On 01/09/14 16:03, Christian Borntraeger wrote:
> On 01/09/14 15:29, Paolo Bonzini wrote:
>> Il 01/09/2014 15:22, Christian Borntraeger ha scritto:
> If virtio-blk and virtio-serial share an IRQ, the guest operating system
> has to check each virtqueue for activity. Maybe there is some
>>
On 01/09/14 15:29, Paolo Bonzini wrote:
> Il 01/09/2014 15:22, Christian Borntraeger ha scritto:
If virtio-blk and virtio-serial share an IRQ, the guest operating system
has to check each virtqueue for activity. Maybe there is some inefficiency
doing that.
AFAIK virtio-serial
Il 01/09/2014 15:22, Christian Borntraeger ha scritto:
> > > If virtio-blk and virtio-serial share an IRQ, the guest operating system
> > > has to check each virtqueue for activity. Maybe there is some
> > > inefficiency doing that.
> > > AFAIK virtio-serial registers 64 virtqueues (on 31 ports +
On 01/09/14 15:12, Paolo Bonzini wrote:
> Il 01/09/2014 15:09, Christian Borntraeger ha scritto:
>> This is just wild guessing:
>> If virtio-blk and virtio-serial share an IRQ, the guest operating system has
>> to check each virtqueue for activity. Maybe there is some inefficiency doing
>> that.
https://bugzilla.kernel.org/show_bug.cgi?id=82211
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
You are receiving this mail
Il 01/09/2014 15:09, Christian Borntraeger ha scritto:
> This is just wild guessing:
> If virtio-blk and virtio-serial share an IRQ, the guest operating system has
> to check each virtqueue for activity. Maybe there is some inefficiency doing
> that.
> AFAIK virtio-serial registers 64 virtqueues
On 01/09/14 14:52, Zhang Haoyu wrote:
Hi, all
I start a VM with virtio-serial (default ports number: 31), and found that
virtio-blk performance degradation happened, about 25%, this problem can
be reproduced 100%.
without virtio-serial:
4k-read-random 1186 IOPS
https://bugzilla.kernel.org/show_bug.cgi?id=82211
Paolo Bonzini changed:
What|Removed |Added
Summary|[BISECTED][Nested xen on|Cannot boot Xen under KVM
In case the IRQ is forwarded, the VFIO platform IRQ handler does not
need to disable the IRQ anymore. In that mode, when the handler completes
the IRQ is not deactivated but only its priority is lowered.
Some other actor (typically a guest) is supposed to deactivate the IRQ,
allowing at that time
Fix multiple injection of level sensitive forwarded IRQs.
With current code, the second injection fails since the state bitmaps
are not reset (process_maintenance is not called anymore).
New implementation consists in fully bypassing the vgic state
management for forwarded IRQ (checks are ignored i
From: Kim Phillips
Used by KVM-enabled VFIO-based device passthrough support in QEMU.
Signed-off-by: Kim Phillips
---
arch/arm/kvm/Kconfig | 1 +
arch/arm/kvm/Makefile | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index e519a
add a lock related to the rb tree manipulation. The rb tree can be
searched in one thread (irqfd handler for instance) and map/unmap
happen in another.
Signed-off-by: Eric Auger
---
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/vgic.c| 46 +-
2 files
New functions are added to be called from ARM KVM-VFIO device.
- vfio_device_get_external_user enables to get a vfio device from
its fd
- vfio_device_put_external_user puts the vfio device
- vfio_external_base_device returns the struct device*,
useful to access the platform_device
Signed-off-
add new device group commands:
- KVM_DEV_VFIO_DEVICE_FORWARD_IRQ and
KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ
which enable to turn forwarded IRQ mode on/off.
the kvm_arch_forwarded_irq struct embodies a forwarded IRQ
Signed-off-by: Eric Auger
---
v1 -> v2:
- struct kvm_arch_forwarded_irq moved fro
This RFC proposes an integration of "ARM: Forwarding physical
interrupts to a guest VM" (http://lwn.net/Articles/603514/) in
KVM.
It enables to transform a VFIO platform driver IRQ into a forwarded
IRQ. The direct benefit is that, for a level sensitive IRQ, a VM
switch can be avoided on guest virt
>> >> Hi, all
>> >>
>> >> I start a VM with virtio-serial (default ports number: 31), and found
>> >> that virtio-blk performance degradation happened, about 25%, this problem
>> >> can be reproduced 100%.
>> >> without virtio-serial:
>> >> 4k-read-random 1186 IOPS
>> >> with virtio-serial:
>> >
add functions that implement the gateway to the extended
external VFIO API:
- kvm_vfio_device_get_external_user
- kvm_vfio_device_put_external_user
- kvm_vfio_external_base_device
Signed-off-by: Eric Auger
---
v1 -> v2:
- kvm_vfio_external_get_base_device renamed into
kvm_vfio_external_base_d
This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
This is a new control channel which enables KVM to cooperate with
viable VFIO devices.
The kvm-vfio device now holds a list of devices (kvm_vfio_device)
in addition to a list of groups (kvm_vfio_group). The new
infrastructure enables to c
Enables forwarding control for ARM. By defining
__KVM_HAVE_ARCH_KVM_VFIO_FORWARD the patch enables
KVM_DEV_VFIO_DEVICE_FORWARD/UNFORWARD_IRQ command on ARM. As a
result it brings an optimized injection/completion handling for
forwarded IRQ. The ARM specific part is implemented in a new module,
kvm_
>>> Hi, all
>>>
>>> I start a VM with virtio-serial (default ports number: 31), and found that
>>> virtio-blk performance degradation happened, about 25%, this problem can be
>>> reproduced 100%.
>>> without virtio-serial:
>>> 4k-read-random 1186 IOPS
>>> with virtio-serial:
>>> 4k-read-random 8
On (Mon) 01 Sep 2014 [20:38:20], Zhang Haoyu wrote:
> >> Hi, all
> >>
> >> I start a VM with virtio-serial (default ports number: 31), and found that
> >> virtio-blk performance degradation happened, about 25%, this problem can
> >> be reproduced 100%.
> >> without virtio-serial:
> >> 4k-read-ra
https://bugzilla.kernel.org/show_bug.cgi?id=82211
Paolo Bonzini changed:
What|Removed |Added
CC||bonz...@gnu.org
--- Comment #3 from Paolo
>> Hi, all
>>
>> I start a VM with virtio-serial (default ports number: 31), and found that
>> virtio-blk performance degradation happened, about 25%, this problem can be
>> reproduced 100%.
>> without virtio-serial:
>> 4k-read-random 1186 IOPS
>> with virtio-serial:
>> 4k-read-random 871 IOPS
>
Il 01/09/2014 12:44, Tiejun Chen ha scritto:
> Just reuse rsvd_bits() inside kvm_set_mmio_spte_mask()
> for slightly better code.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/x86/kvm/mmu.c | 5 -
> arch/x86/kvm/mmu.h | 5 +
> arch/x86/kvm/x86.c | 2 +-
> 3 files changed, 6 insertions(+),
Just reuse rsvd_bits() inside kvm_set_mmio_spte_mask()
for slightly better code.
Signed-off-by: Tiejun Chen
---
arch/x86/kvm/mmu.c | 5 -
arch/x86/kvm/mmu.h | 5 +
arch/x86/kvm/x86.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/
We currently decide at compile-time which of the SPE or AltiVec units to
support exclusively. Guard kernel defines with CONFIG_SPE_POSSIBLE and
CONFIG_PPC_E500MC and remove shared defines.
Signed-off-by: Mihai Caraman
---
arch/powerpc/include/asm/kvm_asm.h | 20 ++--
1 file chang
Il 01/09/2014 10:36, Eric Auger ha scritto:
> No more needed. irq.h would be void on ARM.
>
> Signed-off-by: Eric Auger
>
> ---
>
> I don't think irq.h is needed anymore since Paul Mackerras' work. However
> I did not compile for all architectures.
> ---
> virt/kvm/eventfd.c | 1 -
> 1 file ch
On 1 September 2014 10:56, Christoffer Dall wrote:
> The thing is that we're not exposing PSCI to user space, we're just
> exposing a system event, so it feels a bit weird to rely on user space's
> correct interpretation of a more generic API, to correctly implement
> PSCI in the kernel.
Yeah; if
On Mon, Sep 01, 2014 at 10:30:17AM +0100, Peter Maydell wrote:
> On 1 September 2014 10:20, Christoffer Dall
> wrote:
> > On Fri, Aug 29, 2014 at 06:39:09PM +0100, Peter Maydell wrote:
> >> Talking with Ard I realised that there's actually a hole in the
> >> specification of this new ABI. Did we
On 08/28/2014 11:49 AM, Stefan Hajnoczi wrote:
On Tue, Aug 26, 2014 at 01:04:30PM +0200, Paolo Bonzini wrote:
Il 26/08/2014 08:47, David Marchand ha scritto:
Using a version message supposes we want to keep ivshmem-server and QEMU
separated (for example, in two distribution packages) while we
Hi
Please, send any topic that you are interested in covering.
Thanks, Juan.
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every two weeks
By popular demand, a google calendar public entry with it
https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY
On 1 September 2014 10:20, Christoffer Dall wrote:
> On Fri, Aug 29, 2014 at 06:39:09PM +0100, Peter Maydell wrote:
>> Talking with Ard I realised that there's actually a hole in the
>> specification of this new ABI. Did we intend these shutdown
>> and reset exits to be:
>> (1) requests from the
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #18 from Joerg Roedel ---
The fix is now upstream and part of Linux v3.17-rc2.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the
On Thu, Aug 28, 2014 at 03:13:03PM +0200, Radim Krčmář wrote:
> In the beggining was on_each_cpu(), which required an unused argument to
> kvm_arch_ops.hardware_{en,dis}able, but this was soon forgotten.
>
> Remove unnecessary arguments that stem from this.
>
> Signed-off-by: Radim Krčmář
For t
On Thu, Aug 28, 2014 at 03:13:02PM +0200, Radim Krčmář wrote:
> Using static inline is going to save few bytes and cycles.
> For example on powerpc, the difference is 700 B after stripping.
> (5 kB before)
>
> This patch also deals with two overlooked empty functions:
> kvm_arch_flush_shadow was n
On Fri, Aug 29, 2014 at 06:39:09PM +0100, Peter Maydell wrote:
> On 25 May 2014 19:18, Christoffer Dall wrote:
> > From: Anup Patel
> >
> > Currently, we don't have an exit reason to notify user space about
> > a system-level event (for e.g. system reset or shutdown) triggered
> > by the VCPU. Th
Now that AltiVec and hardware thread support is in place enable e6500 core.
Signed-off-by: Mihai Caraman
---
v2:
- new patch
arch/powerpc/kvm/e500mc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index bf8f99f..2fdc872 10
ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.
The e6500 core shares TLBs between hardware threads. Without tlb write
conditional instruction, the Linux kernel uses per core mech
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
a kvm_irqfd struct that associates a VM, an eventfd, a virtual IRQ number
(aka. the gsi). When an actor signals the eventfd (
I abandon this patch, I will send a v2 with a minor fix for 85xx.
Mike
> -Original Message-
> From: Mihai Caraman [mailto:mihai.cara...@freescale.com]
> Sent: Friday, August 29, 2014 8:04 PM
> To: kvm-...@vger.kernel.org
> Cc: kvm@vger.kernel.org; Caraman Mihai Claudiu-B02008
> Subject: [
No more needed. irq.h would be void on ARM.
Signed-off-by: Eric Auger
---
I don't think irq.h is needed anymore since Paul Mackerras' work. However
I did not compile for all architectures.
---
virt/kvm/eventfd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/e
On Mon, Sep 01, 2014 at 03:58:02PM +0800, Amos Kong wrote:
> On Mon, Sep 01, 2014 at 09:37:30AM +0300, Michael S. Tsirkin wrote:
> >
>
> Hi Michael,
>
> > On Mon, Sep 01, 2014 at 01:41:54PM +0800, Amos Kong wrote:
> > > One VM only has 128 msix interrupt, virtio-config interrupt
> > > has less wo
On Mon, Sep 01, 2014 at 09:37:30AM +0300, Michael S. Tsirkin wrote:
>
Hi Michael,
> On Mon, Sep 01, 2014 at 01:41:54PM +0800, Amos Kong wrote:
> > One VM only has 128 msix interrupt, virtio-config interrupt
> > has less workload. This patch shares one normal interrupt
Thanks for your quick reply
65 matches
Mail list logo
