Re: [PATCH] KVM: VMX: Use proper slot index for kvm_set_shared_msr

On 10/29/2009 07:13 PM, Avi Kivity wrote:
> On 10/29/2009 06:53 PM, Jan Kiszka wrote:
>> We were missing one indirection here to translate from vmx-local to
>> x86 slot indices, and this caused subtle host crashes.
>>
>
> Ahh, good catch.  How did it work?

And, of course, applied.  Thanks.

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: block virtio excessive VIRTIO_PCI_ISR reads

On 10/29/2009 05:47 PM, Saul Tamari wrote:
> Hi,
>
> The current qemu-kvm from the git indeed adds the MSI-x capability to
> the virtio block device.
> With MSI-x enabled on the virtio block device, there aren't
> VIRTIO_PCI_ISR reads on the unused device.
>    

There shouldn't be VIRTIO_PCI_ISR reads on any device, not just the 
unused ones, if all are MSI-X capable.

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel bug in kvm_intel

Hello,

Avi Kivity wrote:
> Only, that merge doesn't change virt/kvm or arch/x86/kvm.
> 
> Tejun, anything known bad about that merge?  ada3fa15 kills kvm.

Nothing rings a bell at the moment.  How does it kill kvm?  One big
difference caused by that merge is use of sparse areas near the top of
vmalloc area.  This caused vmalloc area shortage on sparc64 and
exposed paging code bug on ppc64 which caused the cpu to fault
repeatedly on the same address.  Maybe something similiar is happening
with kvm?

Thanks.

--

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] viostor driver.Add memory barrier - synch with fix for Linux guests by Michael S. Tsirkin <mst <at> redhat.com>

repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 6906acfc2d5f58df43ebc9c190e1447ff6e63a01
Author: Vadim Rozenfeld<vrozenfe <at> redhat.com>
Date:   Sun Nov 1 11:54:03 2009 +0200

     [PATCH] viostor driver.Add memory read barrier - synch with fix for Linux guests by Michael S. Tsirkin<mst <at> redhat.com>

     Signed-off-by: Vadim Rozenfeld<vrozenfe <at> redhat.com>

diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c
index d099bb8..2911cef 100644
--- a/viostor/virtio_ring.c
+++ b/viostor/virtio_ring.c
 <at>  <at>  -237,6 +237,8  <at>  <at>  vring_get_buf(
          return NULL;
      }

+    rmb();
+
      i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id;
      *len = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].len;

diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c
index d099bb8..2911cef 100644
--- a/viostor/virtio_ring.c
+++ b/viostor/virtio_ring.c

Re: kernel bug in kvm_intel

Hello,

Avi Kivity wrote:
> We get a page fault immediately (next instruction) after returning from
> the guest when running with oprofile.  The page fault address does not
> match anything the instruction does, so presumably it is one of the
> accesses the processor performs in order to service an NMI (ordinary
> interrupts are masked; and the fact that it happens with oprofile
> strengthens this assumption).

Ah... okay, that's tricky but IIRC faults like that can be
distinguished from regular ones via processor state, right?

> If this is correct, the fault is not in the NMI handler itself, but in
> one of the memory areas the cpu looks in to vector the NMI, which can be:
> 
> - the IDT
> - the GDT
> - the TSS
> - the NMI stack
> 
> Except for the IDT these are per-cpu structure, though I don't know
> whether they are allocated with the percpu infrastructure.

Don't know where NMI stack is but all else are percpu.

> Here is the code in question:
> 
>>     3ae7:       75 05                   jne    3aee<vmx_vcpu_run+0x26a>
>>       3ae9:       0f 01 c2                vmlaunch

Re: block virtio excessive VIRTIO_PCI_ISR reads

You are right.
After enabling MSI-x for the virtio block device I now only see
VIRTIO_PCI_QUEUE_NOTIFY writes and there aren't any VIRTIO_PCI_ISR
reads anymore.

Thanks,
Saul

On Sun, Nov 1, 2009 at 11:23 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 10/29/2009 05:47 PM, Saul Tamari wrote:
>>
>> Hi,
>>
>> The current qemu-kvm from the git indeed adds the MSI-x capability to
>> the virtio block device.
>> With MSI-x enabled on the virtio block device, there aren't
>> VIRTIO_PCI_ISR reads on the unused device.
>>
>
> There shouldn't be VIRTIO_PCI_ISR reads on any device, not just the unused
> ones, if all are MSI-X capable.
>
> --
> error compiling committee.c: too many arguments to function
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/11] Handle async PF in non preemptable context.

If async page fault is received by idle task or when preemp_count is
not zero guest cannot reschedule, so make "wait for page" hypercall
and comtinue only after a page is ready.

Signed-off-by: Gleb Natapov <gleb <at> redhat.com>
---
 arch/x86/kernel/kvm.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 79d291f..1bd8b8d 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
 <at>  <at>  -162,10 +162,24  <at>  <at>  int kvm_handle_pf(struct pt_regs *regs, unsigned long error_code)
 	switch (reason) {
 	default:
 		return 0;
-	case KVM_PV_REASON_PAGE_NP:
+	case KVM_PV_REASON_PAGE_NP: {
+		int cpu, idle;
+		cpu = get_cpu();
+		idle = idle_cpu(cpu);
+		put_cpu();
+
+		/*
+		 * We cannot reschedule. Wait for page to be ready.
+		 */
+		if (idle || preempt_count()) {
+			kvm_hypercall0(KVM_HC_WAIT_FOR_ASYNC_PF);
+			break;

RE: [PATCH] viostor driver.Add memory barrier - synch with fix for Linux guests by Michael S. Tsirkin <mst <at> redhat.com>

Committed. Thanks.

> -----Original Message-----
> From: kvm-owner <at> vger.kernel.org [mailto:kvm-owner <at> vger.kernel.org] On
> Behalf Of Vadim Rozenfeld
> Sent: Sunday, November 01, 2009 12:41 PM
> To: kvm <at> vger.kernel.org
> Subject: [PATCH] viostor driver.Add memory barrier - synch with fix for
> Linux guests by Michael S. Tsirkin <mst <at> redhat.com>
> 
> 
> repository: /home/vadimr/shares/kvm-guest-drivers-windows
> branch: XP
> commit 6906acfc2d5f58df43ebc9c190e1447ff6e63a01
> Author: Vadim Rozenfeld<vrozenfe <at> redhat.com>
> Date:   Sun Nov 1 11:54:03 2009 +0200
> 
>      [PATCH] viostor driver.Add memory read barrier - synch with fix
> for Linux guests by Michael S. Tsirkin<mst <at> redhat.com>
> 
>      Signed-off-by: Vadim Rozenfeld<vrozenfe <at> redhat.com>
> 
> diff --git a/viostor/virtio_ring.c b/viostor/virtio_ring.c index
> d099bb8..2911cef 100644
> --- a/viostor/virtio_ring.c
> +++ b/viostor/virtio_ring.c
>  <at>  <at>  -237,6 +237,8  <at>  <at>  vring_get_buf(
>           return NULL;
>       }
> 

Re: [PATCH 5/5] Fix kdump under KVM.

On 10/30/2009 02:23 PM, Chris Lalancette wrote:
> In the meantime, I've gotten the "set_irq from IRQ context" that Avi 
> suggested
> working, and the fixing up of this IOAPIC check is the last bit to actually get
> kdump working.
>    

There are two problems with that:

- kvm_set_irq() calls some notifiers (irq_mask_notifiers, at least, but 
possibly more); need to make sure those are safe from irq context
- kvm_set_irq() will loop on all vcpus, usually incurring a cache miss 
or two; with large vcpu counts this can make the irq-off time quite 
large, hurting our worst-case latency

we can defer the second problem since it's only a performance issue, but 
how did you deal with the first?

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CPU troubles with kvm 83 redhat 5.4 windows 2008 server 64 bits

On 10/29/2009 05:11 PM, Arnaud Maillet wrote:
> Hello world,
>
> I used to use Xen on my server but due to a non-patched cygwin problem
> I installed kvm 83 on my redhat 5.4 with the red hat rpm.
>
> I found some troubles with a windows 2008 server 64 bits guest. When I
> install a software like an anti-virus it takes a lot of time compare
> to Xen ( that takes 10 times more time on kvm) .
>
> The guest task manager displays 100% of the cpu is used but with the
> virt-manager (host) I can see just 7.5% of the cpu is used. Do you
> have any solutions ?
>    

It's probably disk activity.  Can you verify with vmstat?

If so, try using an lvm volume instead of a qcow2 file.

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html