Re: kvm problems on new hardware

[Danny ter Haar]

On Thu, 2009-10-29 at 17:07 -0500, Ryan Harper wrote:
> I've seen that in a couple places.  I don't think we have root cause,
> but in at least one situation (running win2k3 with > 4G of ram) the
> work around was to use:
> 
>-cpu pentium3

Thanks for your response.

When i add this option it segv's on bootup, it doesn't even make it to the
bootscreen of debian:


vhost1:~# kvm -m 512 -cdrom  /vz/template/iso/debian-503-amd64-netinst.iso -cpu 
pentium3

kvm[4829]: segfault at c ip 004674ac sp 42323fd0 error 4 in 
kvm[40+21b000]

Does this provide more hints where to look ?

--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Scott Tsai]

Hi, Dustin,
What's the easiest way to see the patches to qemu that Canonical
carries for the different Ubuntu releases?
(I think http://patches.ubuntu.com/ only diffs against Debian for the
last stable Ubuntu release?)

Also, is there a way for an outside developer to get email
notifications when a patch is added to Ubuntu's qemu package?
--
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

Re: kvm problems on new hardware

[Ryan Harper]

* Danny ter Haar  [2009-10-29 13:38]:
> Update:
> I compiled/installed 2.6.32-rc5-git3 on this machine
> 
> I manually start kvm:
> 
> vhost1:~# kvm -m 512 -cdrom  /vz/template/iso/debian-503-amd64-netinst.iso
> 
> The bootscreen comes up, i hit enter to install and i get these messages
> (copied from dmesg)
> 
> handle_exception: unexpected, vectoring info 0x8010 intr info 0x8b0d
> handle_exception: unexpected, vectoring info 0x800d intr info 0x8b0d
> [this line is repeated many times: 
> dmesg |grep 0x8b0d | wc -l 
> 570 ]
> and finally before ending the kvm session i get:
> vmx_handle_exit: unexpected, valid vectoring info (0x800d) and exit 
> reason is 0x8021

I've seen that in a couple places.  I don't think we have root cause,
but in at least one situation (running win2k3 with > 4G of ram) the
work around was to use:

   -cpu pentium3

This relates to what cpu features are exported in the virtual processor,
so if this helps it's masking the real issue, but hopefully can
help narrow down what we have to look at.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
--
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

Re: Daily git testing failure due to build problem

[Lucas Meneghel Rodrigues]

Ok, indeed using the -next branch solves the problems. When the next
merge is done, we won't have this problem anymore.

Thanks for your attention!

On Thu, Oct 29, 2009 at 4:36 PM, Lucas Meneghel Rodrigues
 wrote:
> On Thu, 2009-10-29 at 18:07 +0100, Jan Kiszka wrote:
>> Lucas Meneghel Rodrigues wrote:
>> > Hi folks, today's git test failed due to a build problem. Attached goes
>> > the build log. The relevant snippet I could identify is:
>> >
>> > 10/29 04:57:13 DEBUG|     utils:0085|   CC
>> > [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/i8259.o
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:80:40: error: 
>> > linux/user-return-notifier.h: No such file or directory
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:142: error: field 
>> > ‘urn’ has incomplete type
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
>> > ‘kvm_on_user_return’:
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: type 
>> > defaults to ‘int’ in declaration of ‘__mptr’
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: 
>> > initialization from incompatible pointer type
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:201: error: implicit 
>> > declaration of function ‘user_return_notifier_unregister’
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
>> > ‘kvm_set_shared_msr’:
>> > 10/29 04:57:13 ERROR|     utils:0085| 
>> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:238: error: implicit 
>> > declaration of function ‘user_return_notifier_register’
>> > 10/29 04:57:13 ERROR|     utils:0085| make[3]: *** 
>> > [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.o] Error 1
>> > 10/29 04:57:13 ERROR|     utils:0085| make[3]: *** Waiting for unfinished 
>> > jobs
>> > 10/29 04:57:14 ERROR|     utils:0085| make[2]: *** 
>> > [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] Error 2
>> > 10/29 04:57:14 DEBUG|     utils:0085| make[1]: Leaving directory 
>> > `/usr/src/kernels/2.6.29.6-217.2.8.fc11.x86_64'
>> > 10/29 04:57:14 ERROR|     utils:0085| make[1]: *** 
>> > [_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2
>> > 10/29 04:57:14 ERROR|     utils:0085| make: *** [all] Error 2
>> >
>> > Any doubts let me know!
>>
>> Find a working version in current kvm-kmod.git (at least in next, master
>> should catch up soon).
>
> The tests are made using master for kvm-kmod.git
>
>> Are you also picking up latest kvm-kmod.git for these builds?
>
> If necessary, I can rerun the test against the next branch to see if
> this works. I will fire a job using next to see if it works.
>
> Thanks!
>
>> Jan
>>
>
> --
> 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
>



-- 
Lucas
--
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

Re: kvm problems on new hardware

[Danny ter Haar]

Update:
I compiled/installed 2.6.32-rc5-git3 on this machine

I manually start kvm:

vhost1:~# kvm -m 512 -cdrom  /vz/template/iso/debian-503-amd64-netinst.iso

The bootscreen comes up, i hit enter to install and i get these messages
(copied from dmesg)

handle_exception: unexpected, vectoring info 0x8010 intr info 0x8b0d
handle_exception: unexpected, vectoring info 0x800d intr info 0x8b0d
[this line is repeated many times: 
dmesg |grep 0x8b0d | wc -l 
570 ]
and finally before ending the kvm session i get:
vmx_handle_exit: unexpected, valid vectoring info (0x800d) and exit reason 
is 0x8021


Can somebody make a slightly related guess what this means ?

Bad hardware ? 
cpu ? mem ?

Bueller, anyone ?

--
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

Re: Daily git testing failure due to build problem

[Lucas Meneghel Rodrigues]

On Thu, 2009-10-29 at 18:07 +0100, Jan Kiszka wrote:
> Lucas Meneghel Rodrigues wrote:
> > Hi folks, today's git test failed due to a build problem. Attached goes
> > the build log. The relevant snippet I could identify is:
> > 
> > 10/29 04:57:13 DEBUG| utils:0085|   CC
> > [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/i8259.o
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:80:40: error: 
> > linux/user-return-notifier.h: No such file or directory
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:142: error: field 
> > ‘urn’ has incomplete type
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
> > ‘kvm_on_user_return’:
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: type 
> > defaults to ‘int’ in declaration of ‘__mptr’
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: 
> > initialization from incompatible pointer type
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:201: error: implicit 
> > declaration of function ‘user_return_notifier_unregister’
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
> > ‘kvm_set_shared_msr’:
> > 10/29 04:57:13 ERROR| utils:0085| 
> > /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:238: error: implicit 
> > declaration of function ‘user_return_notifier_register’
> > 10/29 04:57:13 ERROR| utils:0085| make[3]: *** 
> > [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.o] Error 1
> > 10/29 04:57:13 ERROR| utils:0085| make[3]: *** Waiting for unfinished 
> > jobs
> > 10/29 04:57:14 ERROR| utils:0085| make[2]: *** 
> > [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] Error 2
> > 10/29 04:57:14 DEBUG| utils:0085| make[1]: Leaving directory 
> > `/usr/src/kernels/2.6.29.6-217.2.8.fc11.x86_64'
> > 10/29 04:57:14 ERROR| utils:0085| make[1]: *** 
> > [_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2
> > 10/29 04:57:14 ERROR| utils:0085| make: *** [all] Error 2
> > 
> > Any doubts let me know!
> 
> Find a working version in current kvm-kmod.git (at least in next, master
> should catch up soon).

The tests are made using master for kvm-kmod.git

> Are you also picking up latest kvm-kmod.git for these builds?

If necessary, I can rerun the test against the next branch to see if
this works. I will fire a job using next to see if it works.

Thanks!

> Jan
> 

--
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

Re: [PATCH 5/5] Nested VMX patch 5 implements vmlaunch and vmresume

[Gleb Natapov]

On Wed, Oct 28, 2009 at 06:23:42PM +0200, Orit Wasserman wrote:
> 
> 
> Gleb Natapov  wrote on 25/10/2009 11:44:31:
> 
> > From:
> >
> > Gleb Natapov 
> >
> > To:
> >
> > Orit Wasserman/Haifa/i...@ibmil
> >
> > Cc:
> >
> > Abel Gordon/Haifa/i...@ibmil, aligu...@us.ibm.com, Ben-Ami Yassour1/
> > Haifa/i...@ibmil, kvm@vger.kernel.org, md...@us.ibm.com, Muli Ben-
> > Yehuda/Haifa/i...@ibmil
> >
> > Date:
> >
> > 25/10/2009 11:44
> >
> > Subject:
> >
> > Re: [PATCH 5/5] Nested VMX patch 5 implements vmlaunch and vmresume
> >
> > On Thu, Oct 22, 2009 at 05:46:16PM +0200, Orit Wasserman wrote:
> > >
> > >
> > > Gleb Natapov  wrote on 22/10/2009 11:04:58:
> > >
> > > > From:
> > > >
> > > > Gleb Natapov 
> > > >
> > > > To:
> > > >
> > > > Orit Wasserman/Haifa/i...@ibmil
> > > >
> > > > Cc:
> > > >
> > > > Abel Gordon/Haifa/i...@ibmil, aligu...@us.ibm.com, Ben-Ami Yassour1/
> > > > Haifa/i...@ibmil, kvm@vger.kernel.org, md...@us.ibm.com, Muli Ben-
> > > > Yehuda/Haifa/i...@ibmil
> > > >
> > > > Date:
> > > >
> > > > 22/10/2009 11:05
> > > >
> > > > Subject:
> > > >
> > > > Re: [PATCH 5/5] Nested VMX patch 5 implements vmlaunch and vmresume
> > > >
> > > > On Wed, Oct 21, 2009 at 04:43:44PM +0200, Orit Wasserman wrote:
> > > > > > > @@ -4641,10 +4955,13 @@ static void vmx_complete_interrupts
> (struct
> > > > > > vcpu_vmx *vmx)
> > > > > > > int type;
> > > > > > > bool idtv_info_valid;
> > > > > > >
> > > > > > > -   exit_intr_info = vmcs_read32(VM_EXIT_INTR_INFO);
> > > > > > > -
> > > > > > > vmx->exit_reason = vmcs_read32(VM_EXIT_REASON);
> > > > > > >
> > > > > > > +   if (vmx->nested.nested_mode)
> > > > > > > +  return;
> > > > > > > +
> > > > > > Why return here? What the function does that should not be done
> in
> > > > > > nested mode?
> > > > > In nested mode L0 injects an interrupt to L2 only in one scenario,
> > > > > if there is an IDT_VALID event and L0 decides to run L2 again and
> not
> > > to
> > > > > switch back to L1.
> > > > > In all other cases the injection is handled by L1.
> > > > This is exactly the kind of scenario that is handled by
> > > > vmx_complete_interrupts(). (vmx|svm)_complete_interrups() store
> > > > pending event in arch agnostic way and re-injection is handled by
> > > > x86.c You bypass this logic by inserting return here and introducing
> > > > nested_handle_valid_idt() function below.
> > > The only location we can truly know if we are switching to L1 is in
> > > vmx_vcpu_run
> > > because enable_irq_window (that is called after handling the exit) can
> > > decide to
> > > switch to L1 because of an interrupt.
> > enable_irq_window() will be called after L2 VMCS will be setup for event
> > re-injection by previous call to inject_pending_event(). As far as I
> > can see this should work for interrupt injection. For exception we
> > should probably require l2 guest to re execute faulted instruction for
> > now like svm does.
> The main issue is that L0 doesn't inject events to L2 but L1 hypervisor (we
> want to keep the nested hypervisor semantics as
> much as possible). Only if the event was caused by the fact that L2 is a
> nested guest
> and L1 can't handle it L0 will re-inject and event to L2, for example IDT
> event
> with page fault that is caused by a missing entry in SPT02 (the shadow page
> table L0 create for L2).
> In this case when vmx_complete_intterupts is called L0 doesn't know if the
> page fault should be handled by it or
> by L1 (it is decided later when handling the exit).
So what? When it will be decided that L2 exit is needed pending event
will be transfered into L2's idt_vectoring_info. Otherwise event will be
reinfected by usual mechanism. BTW I don't see where you current code
setup L2's idt_vectoring_info if it is decided that L1 should handle
event reinjection.

> In most other cases , L0 will switch to L1 and L1 will decide if there will
> be re-injection
> (depends on the L1 hypervisor logic) and update L2 VMCS accordingly.
> >
> > > In order to simplify our code it was simpler to bypass
> > > vmx_complete_interrupts when it is called (after
> > > running L2) and to add nested_handle_valid_idt just before running L2.
> > > > > >
> > > > > > > +   exit_intr_info = vmcs_read32(VM_EXIT_INTR_INFO);
> > > > > > > +
> > > > > > > /* Handle machine checks before interrupts are enabled */
> > > > > > > if ((vmx->exit_reason == EXIT_REASON_MCE_DURING_VMENTRY)
> > > > > > > || (vmx->exit_reason == EXIT_REASON_EXCEPTION_NMI
> > > > > > > @@ -4747,6 +5064,60 @@ static void fixup_rmode_irq(struct
> vcpu_vmx
> > > > > *vmx)
> > > > > > >| vmx->rmode.irq.vector;
> > > > > > >  }
> > > > > > >
> > > > > > > +static int nested_handle_valid_idt(struct kvm_vcpu *vcpu)
> > > > > > > +{
> > > > > > It seems by this function you are trying to bypass general event
> > > > > > reinjection logic. Why?
> > > > > See above.
> > > > The logic implemented by this function is handled in x86.c in arch
> > > > agnostic way. Is there so

Re: [PATCH] KVM: VMX: Build move_msr_up also for x86-32

[Avi Kivity]

On 10/29/2009 07:02 PM, Jan Kiszka wrote:

It's used now on 32-bit as well.

   


Already have that queued, thanks.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

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

[Avi Kivity]

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?


Signed-off-by: Jan Kiszka
---

IOW: Win7 boots for me again.

  arch/x86/kvm/vmx.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a1976c9..6b818c0 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -660,7 +660,8 @@ static void vmx_save_host_state(struct kvm_vcpu *vcpu)
}
  #endif
for (i = 0; i<  vmx->save_nmsrs; ++i)
-   kvm_set_shared_msr(i, vmx->guest_msrs[i].data);
+   kvm_set_shared_msr(vmx->guest_msrs[i].index,
+  vmx->guest_msrs[i].data);
  }

  static void __vmx_load_host_state(struct vcpu_vmx *vmx)
   



--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

Re: Impossible to compile kvm-88 on Redhat 5.4

[Jan Kiszka]

Arnaud Maillet wrote:
> Hello, when I try to compile kvm-88 on Redhat 5.4 I have this error :
> 
>  CC [M]  /root/kvm-88/kvm/kernel/x86/svm.o
> In file included from :1:
> /root/kvm-88/kvm/kernel/x86/external-module-compat.h:12: erreur:
> redefinition of typedef â
> include/asm/types.h:50: erreur: previous declaration of â was here
> In file included from /root/kvm-88/kvm/kernel/x86/external-module-compat.h:16,
>  from :1:
> /root/kvm-88/kvm/kernel/x86/../external-module-compat-comm.h:609:
> erreur: static declaration of â follows non-static declaration
> include/linux/mm.h:873: erreur: previous declaration of â was here
> make[4]: *** [/root/kvm-88/kvm/kernel/x86/svm.o] Erreur 1
> make[3]: *** [/root/kvm-88/kvm/kernel/x86] Erreur 2
> make[2]: *** [_module_/root/kvm-88/kvm/kernel] Erreur 2
> make[1]: *** [all] Erreur 2
> make: *** [kvm-kmod] Erreur 2
> 
> 
> Maybe I forgot a dep ?

You may want to try recently release kvm-kmod-2.6.31.5 as it fixed a lot
of build issues against older kernels. What kernel version is in RH 5.4?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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

Re: Daily git testing failure due to build problem

[Jan Kiszka]

Lucas Meneghel Rodrigues wrote:
> Hi folks, today's git test failed due to a build problem. Attached goes
> the build log. The relevant snippet I could identify is:
> 
> 10/29 04:57:13 DEBUG| utils:0085|   CC
> [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/i8259.o
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:80:40: error: 
> linux/user-return-notifier.h: No such file or directory
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:142: error: field ‘urn’ 
> has incomplete type
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
> ‘kvm_on_user_return’:
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: type 
> defaults to ‘int’ in declaration of ‘__mptr’
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: 
> initialization from incompatible pointer type
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:201: error: implicit 
> declaration of function ‘user_return_notifier_unregister’
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
> ‘kvm_set_shared_msr’:
> 10/29 04:57:13 ERROR| utils:0085| 
> /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:238: error: implicit 
> declaration of function ‘user_return_notifier_register’
> 10/29 04:57:13 ERROR| utils:0085| make[3]: *** 
> [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.o] Error 1
> 10/29 04:57:13 ERROR| utils:0085| make[3]: *** Waiting for unfinished 
> jobs
> 10/29 04:57:14 ERROR| utils:0085| make[2]: *** 
> [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] Error 2
> 10/29 04:57:14 DEBUG| utils:0085| make[1]: Leaving directory 
> `/usr/src/kernels/2.6.29.6-217.2.8.fc11.x86_64'
> 10/29 04:57:14 ERROR| utils:0085| make[1]: *** 
> [_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2
> 10/29 04:57:14 ERROR| utils:0085| make: *** [all] Error 2
> 
> Any doubts let me know!

Find a working version in current kvm-kmod.git (at least in next, master
should catch up soon).

Are you also picking up latest kvm-kmod.git for these builds?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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

[PATCH] KVM: VMX: Build move_msr_up also for x86-32

[Jan Kiszka]

It's used now on 32-bit as well.

Signed-off-by: Jan Kiszka 
---

 arch/x86/kvm/vmx.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6b818c0..3ebb022 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -885,7 +885,6 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu, 
unsigned nr,
 /*
  * Swap MSR entry in host/guest MSR entry array.
  */
-#ifdef CONFIG_X86_64
 static void move_msr_up(struct vcpu_vmx *vmx, int from, int to)
 {
struct shared_msr_entry tmp;
@@ -894,7 +893,6 @@ static void move_msr_up(struct vcpu_vmx *vmx, int from, int 
to)
vmx->guest_msrs[to] = vmx->guest_msrs[from];
vmx->guest_msrs[from] = tmp;
 }
-#endif
 
 /*
  * Set up the vmcs to automatically save and restore system
--
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

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

[Jan Kiszka]

We were missing one indirection here to translate from vmx-local to
x86 slot indices, and this caused subtle host crashes.

Signed-off-by: Jan Kiszka 
---

IOW: Win7 boots for me again.

 arch/x86/kvm/vmx.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a1976c9..6b818c0 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -660,7 +660,8 @@ static void vmx_save_host_state(struct kvm_vcpu *vcpu)
}
 #endif
for (i = 0; i < vmx->save_nmsrs; ++i)
-   kvm_set_shared_msr(i, vmx->guest_msrs[i].data);
+   kvm_set_shared_msr(vmx->guest_msrs[i].index,
+  vmx->guest_msrs[i].data);
 }
 
 static void __vmx_load_host_state(struct vcpu_vmx *vmx)
--
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

Re: BUG with Win7 and user-return-notifier

[Avi Kivity]

On 10/29/2009 06:14 PM, Jan Kiszka wrote:


OK, EFER is a globally shared msr. But there still needs to be a
consensus on the slot id used for guest_msrs and
shared_msrs_global.msrs, right? move_msr_up works per-vcpu and is
obviously decoupled...

   


move_msr_up() moves a shared_msr_entry, which contains an index into the 
shared_msrs_global structure.  Double indirection:


  msr_index = kvm_shared_msrs_global.msrs[vmx->guest_msrs[index].index].msr

So guest_msrs can be rearranged at will.  Except for your oops.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

Daily git testing failure due to build problem

[Lucas Meneghel Rodrigues]

Hi folks, today's git test failed due to a build problem. Attached goes
the build log. The relevant snippet I could identify is:

10/29 04:57:13 DEBUG| utils:0085|   CC
[M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/i8259.o
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:80:40: error: 
linux/user-return-notifier.h: No such file or directory
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:142: error: field ‘urn’ 
has incomplete type
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
‘kvm_on_user_return’:
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: type 
defaults to ‘int’ in declaration of ‘__mptr’
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:191: warning: 
initialization from incompatible pointer type
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:201: error: implicit 
declaration of function ‘user_return_notifier_unregister’
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c: In function 
‘kvm_set_shared_msr’:
10/29 04:57:13 ERROR| utils:0085| 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.c:238: error: implicit 
declaration of function ‘user_return_notifier_register’
10/29 04:57:13 ERROR| utils:0085| make[3]: *** 
[/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/x86.o] Error 1
10/29 04:57:13 ERROR| utils:0085| make[3]: *** Waiting for unfinished 
jobs
10/29 04:57:14 ERROR| utils:0085| make[2]: *** 
[/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] Error 2
10/29 04:57:14 DEBUG| utils:0085| make[1]: Leaving directory 
`/usr/src/kernels/2.6.29.6-217.2.8.fc11.x86_64'
10/29 04:57:14 ERROR| utils:0085| make[1]: *** 
[_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2
10/29 04:57:14 ERROR| utils:0085| make: *** [all] Error 2

Any doubts let me know!

Thanks,

Lucas

10/29 04:50:16 INFO |  test:0256| Test started. Number of iterations: 1
10/29 04:50:16 INFO |  test:0259| Executing iteration 1 of 1
10/29 04:50:16 ERROR|  warnings:0029| 
/usr/local/autotest/tests/kvm/kvm_utils.py:1: DeprecationWarning: the md5 
module is deprecated; use hashlib instead
10/29 04:50:16 ERROR|  warnings:0029|   import md5, thread, subprocess, time, 
string, random, socket, os, signal, pty
10/29 04:50:16 DEBUG|   kvm:0076| Test parameters:
10/29 04:50:16 DEBUG|   kvm:0080| git_repo = 
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
10/29 04:50:16 DEBUG|   kvm:0080| kmod_repo = 
git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
10/29 04:50:16 DEBUG|   kvm:0080| mode = git
10/29 04:50:16 DEBUG|   kvm:0080| name = kvm_install
10/29 04:50:16 DEBUG|   kvm:0080| shortname = kvm_install
10/29 04:50:16 DEBUG|   kvm:0080| type = kvm_install
10/29 04:50:16 DEBUG|   kvm:0080| user_git_repo = 
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
10/29 04:50:16 DEBUG|   kvm:0086| Contents of environment: {}
10/29 04:50:16 DEBUG|kvm_prepro:0240| Fetching KVM module version...
10/29 04:50:16 DEBUG|kvm_prepro:0252| KVM version: kvm-kmod-devel-88
10/29 04:50:16 DEBUG|kvm_prepro:0256| Fetching KVM userspace version...
10/29 04:50:16 DEBUG|kvm_prepro:0265| Could not fetch KVM userspace version
10/29 04:50:16 DEBUG|kvm_prepro:0266| KVM userspace version: Unknown
10/29 04:50:16 INFO | kvm_utils:0160| Fetching git [REP 
'git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git' BRANCH 'master' TAG 
'HEAD'] -> /usr/local/autotest/tests/kvm/src/kvm
10/29 04:50:16 DEBUG| utils:0053| Running 'git init'
10/29 04:50:17 DEBUG| utils:0085| Initialized empty Git repository in 
/usr/local/autotest/tests/kvm/src/kvm/.git/
10/29 04:50:17 DEBUG| utils:0053| Running 'git fetch -q -f -u -t 
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git master:master'
10/29 04:56:14 DEBUG| utils:0053| Running 'git checkout master'
10/29 04:56:21 ERROR| utils:0085| Checking out files:  17% (5315/30477)   
Checking out files:  18% (5486/30477)   
Checking out files:  19% (5791/30477)   
Checking out files:  20% (6096/30477)   
Checking out files:  21% (6401/30477)   
Checking out files:  22% (6705/30477)   
Checking out files:  23% (7010/30477)   
Checking out files:  24% (7315/30477)   
Checking out files:  25% (7620/30477)   
Checking out files:  26% (7925/30477)   
Checking out files:  27% (8229/30477)   
Checking out files:  28% (8534/30477)   
Checking out files:  29% (8839/30477)   
Checking out files:  30% (9144/30477)   
Checking out files:  31% (9448/30477)   
Checking out files:  32% (9753/30477)   
Checking out files:  33% (10058/30477)   
Checking out files:  34% (10363/30477)   
Checking out files:  35% (10667/30477)   
Checking out files:  35% (10717/30477)   
Checking out files:  3

Re: BUG with Win7 and user-return-notifier

[Avi Kivity]

On 10/29/2009 06:07 PM, Jan Kiszka wrote:


Question: When a VCPU migrates, what syncs the shared_msrs per-cpu vars
before or after that, or why is this no problem?

   


The guest's msrs remain on the old cpu (until a new guest is switched in 
or we return to userspace).  The guest msrs are loaded into the new cpu 
when vmx_save_host_state() is called as part or kvm_arch_vcpu_load().



I'm currently following the theory that guest_msrs contains some
non-EFER entry with 0 value, but shared_msrs has a different index in
the slot passed to kvm_set_shared_msr.
   


That's a global...

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

Impossible to compile kvm-88 on Redhat 5.4

[Arnaud Maillet]

Hello, when I try to compile kvm-88 on Redhat 5.4 I have this error :

 CC [M]  /root/kvm-88/kvm/kernel/x86/svm.o
In file included from :1:
/root/kvm-88/kvm/kernel/x86/external-module-compat.h:12: erreur:
redefinition of typedef â
include/asm/types.h:50: erreur: previous declaration of â was here
In file included from /root/kvm-88/kvm/kernel/x86/external-module-compat.h:16,
 from :1:
/root/kvm-88/kvm/kernel/x86/../external-module-compat-comm.h:609:
erreur: static declaration of â follows non-static declaration
include/linux/mm.h:873: erreur: previous declaration of â was here
make[4]: *** [/root/kvm-88/kvm/kernel/x86/svm.o] Erreur 1
make[3]: *** [/root/kvm-88/kvm/kernel/x86] Erreur 2
make[2]: *** [_module_/root/kvm-88/kvm/kernel] Erreur 2
make[1]: *** [all] Erreur 2
make: *** [kvm-kmod] Erreur 2


Maybe I forgot a dep ?

there is the result of ./configure :

[r...@junon kvm-88]# ./configure --prefix=/usr/local/kvm

Error: libpci check failed
Disable KVM Device Assignment capability.

Install prefix/usr/local/kvm
BIOS directory/usr/local/kvm/share/qemu
binary directory  /usr/local/kvm/bin
Manual directory  /usr/local/kvm/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /root/kvm-88
C compilergcc
Host C compiler   gcc
ARCH_CFLAGS   -m64
make  make
install   install
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
-Werror enabled   no
SDL support   no
curses supportyes
curl support  no
mingw32 support   no
Audio drivers oss
Extra audio cards ac97 es1370 sb16
Mixer emulation   no
VNC TLS support   no
VNC SASL support  no
kqemu support no
xen support   no
CPU emulation yes
brlapi supportno
Documentation no
NPTL support  yes
vde support   no
AIO support   yes
IO thread no
Install blobs yes
KVM support   yes
KVM trace support no
fdt support   no
preadv supportno



Thanks in advance!

As regards
--
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

Re: BUG with Win7 and user-return-notifier

[Jan Kiszka]

Jan Kiszka wrote:
> Avi Kivity wrote:
>> On 10/28/2009 10:40 PM, Jan Kiszka wrote:
 [you can get longer, more detailed traces by using
 /sys/kernel/debug/tracing/trace instead of dmesg]

 Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
 kvm_msr: msr_read c080 = 0x500
 Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
 kvm_msr: msr_write c080 = 0xd01

 So Windows is setting EFER.SCE and EFER.NX while in long mode -
 perfectly reasonable.  Can you rerun with the attached debug patch?

  
>>> Log attached.
>>>
>> So the last bits are:
>>
>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
>> efer d01
>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits
>> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload
>>
>> We're not reloading efer (correctly, as guest efer == host efer), yet
>> vmx_save_host_state() fails while loading efer.  I've looked at
>> move_msr_up() (which is used by setup_msrs() to partition the msr space
>> into reloaded and non-reloaded msrs), and it seems correct.
>>
>> Can you see any way where update_transition_efer() returns false, yet
>> efer turns up in the first save_nmsrs entries of vmx->guest_msrs?
>>
> 
> Question: When a VCPU migrates, what syncs the shared_msrs per-cpu vars
> before or after that, or why is this no problem?
> 
> I'm currently following the theory that guest_msrs contains some
> non-EFER entry with 0 value, but shared_msrs has a different index in
> the slot passed to kvm_set_shared_msr.
> 

OK, EFER is a globally shared msr. But there still needs to be a
consensus on the slot id used for guest_msrs and
shared_msrs_global.msrs, right? move_msr_up works per-vcpu and is
obviously decoupled...

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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

Re: BUG with Win7 and user-return-notifier

[Jan Kiszka]

Avi Kivity wrote:
> On 10/28/2009 10:40 PM, Jan Kiszka wrote:
>>
>>> [you can get longer, more detailed traces by using
>>> /sys/kernel/debug/tracing/trace instead of dmesg]
>>>
>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
>>> kvm_msr: msr_read c080 = 0x500
>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
>>> kvm_msr: msr_write c080 = 0xd01
>>>
>>> So Windows is setting EFER.SCE and EFER.NX while in long mode -
>>> perfectly reasonable.  Can you rerun with the attached debug patch?
>>>
>>>  
>> Log attached.
>>
> 
> So the last bits are:
> 
> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
> efer d01
> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits
> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload
> 
> We're not reloading efer (correctly, as guest efer == host efer), yet
> vmx_save_host_state() fails while loading efer.  I've looked at
> move_msr_up() (which is used by setup_msrs() to partition the msr space
> into reloaded and non-reloaded msrs), and it seems correct.
> 
> Can you see any way where update_transition_efer() returns false, yet
> efer turns up in the first save_nmsrs entries of vmx->guest_msrs?
> 

Question: When a VCPU migrates, what syncs the shared_msrs per-cpu vars
before or after that, or why is this no problem?

I'm currently following the theory that guest_msrs contains some
non-EFER entry with 0 value, but shared_msrs has a different index in
the slot passed to kvm_set_shared_msr.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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

Re: BUG with Win7 and user-return-notifier

[Avi Kivity]

On 10/29/2009 05:45 PM, Jan Kiszka wrote:



static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
{
...
for (i = 0; i<  NR_VMX_MSR; ++i) {
u32 index = vmx_msr_index[i];
u32 data_low, data_high;
u64 data;
int j = vmx->nmsrs;

if (rdmsr_safe(index,&data_low,&data_high)<  0)
continue;
if (wrmsr_safe(index, data_low, data_high)<  0)
continue;
data = data_low | ((u64)data_high<<  32);
vmx->guest_msrs[j].index = i;
vmx->guest_msrs[j].data = 0;
 

 ^
Local 'data' drops on the floor. Is that correct (then it deserves a
cleanup)? Previous version did a "guest = host".
   


Arguably, it's more correct than what we used to have.  This code dates 
back to the day when kvm started in 64-bit mode and so we copied 
important MSRs from the host.


Shouldn't matter for our case.


static void vmx_set_efer(struct kvm_vcpu *vcpu, u64 efer)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct shared_msr_entry *msr = find_msr_entry(vmx, MSR_EFER);

if (!msr)
return;
vcpu->arch.shadow_efer = efer;
if (!msr)
return;
 

One "if (!msr)" too much - really the second one?
   


Yes.  (Either really - if there is no host EFER, the only legal value 
for efer is 0, so whether we update it or not doesn't matter).


Likely introduced by a bad merge.  How code rots.

--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: block virtio excessive VIRTIO_PCI_ISR reads

[Saul Tamari]

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.


Thanks,
Saul


On Thu, Oct 29, 2009 at 12:10 PM, Avi Kivity  wrote:
[snip]
>
> Pick up a new qemu-kvm from git.
>
--
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

[patch 2/3] KVM: x86: disallow KVM_{SET,GET}_LAPIC without allocated in-kernel lapic

[Marcelo Tosatti]

Otherwise kvm might attempt to dereference a NULL pointer.

Signed-off-by: Marcelo Tosatti 

Index: kvm/arch/x86/kvm/x86.c
===
--- kvm.orig/arch/x86/kvm/x86.c
+++ kvm/arch/x86/kvm/x86.c
@@ -1893,6 +1893,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
 
switch (ioctl) {
case KVM_GET_LAPIC: {
+   r = -EINVAL;
+   if (!vcpu->arch.apic)
+   goto out;
lapic = kzalloc(sizeof(struct kvm_lapic_state), GFP_KERNEL);
 
r = -ENOMEM;
@@ -1908,6 +1911,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
break;
}
case KVM_SET_LAPIC: {
+   r = -EINVAL;
+   if (!vcpu->arch.apic)
+   goto out;
lapic = kmalloc(sizeof(struct kvm_lapic_state), GFP_KERNEL);
r = -ENOMEM;
if (!lapic)


--
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

[patch 3/3] KVM: only clear irq_source_id if irqchip is present

[Marcelo Tosatti]

Otherwise kvm might attempt to dereference a NULL pointer.

Signed-off-by: Marcelo Tosatti 

Index: kvm/virt/kvm/irq_comm.c
===
--- kvm.orig/virt/kvm/irq_comm.c
+++ kvm/virt/kvm/irq_comm.c
@@ -243,6 +243,10 @@ void kvm_free_irq_source_id(struct kvm *
printk(KERN_ERR "kvm: IRQ source ID out of range!\n");
goto unlock;
}
+   clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
+   if (!irqchip_in_kernel(kvm))
+   goto unlock;
+
for (i = 0; i < KVM_IOAPIC_NUM_PINS; i++) {
clear_bit(irq_source_id, &kvm->arch.vioapic->irq_states[i]);
if (i >= 16)
@@ -251,7 +255,6 @@ void kvm_free_irq_source_id(struct kvm *
clear_bit(irq_source_id, &pic_irqchip(kvm)->irq_states[i]);
 #endif
}
-   clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
 unlock:
mutex_unlock(&kvm->irq_lock);
 }


--
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

[patch 1/3] KVM: x86: disallow multiple KVM_CREATE_IRQCHIP

[Marcelo Tosatti]

Otherwise kvm will leak memory on multiple KVM_CREATE_IRQCHIP. 
Also serialize multiple accesses with kvm->lock.

Signed-off-by: Marcelo Tosatti 

Index: kvm/arch/x86/kvm/x86.c
===
--- kvm.orig/arch/x86/kvm/x86.c
+++ kvm/arch/x86/kvm/x86.c
@@ -2362,25 +2362,39 @@ long kvm_arch_vm_ioctl(struct file *filp
if (r)
goto out;
break;
-   case KVM_CREATE_IRQCHIP:
+   case KVM_CREATE_IRQCHIP: {
+   struct kvm_pic *vpic;
+
+   mutex_lock(&kvm->lock);
+   r = -EEXIST;
+   if (kvm->arch.vpic)
+   goto create_irqchip_unlock;
r = -ENOMEM;
-   kvm->arch.vpic = kvm_create_pic(kvm);
-   if (kvm->arch.vpic) {
+   vpic = kvm_create_pic(kvm);
+   if (vpic) {
r = kvm_ioapic_init(kvm);
if (r) {
-   kfree(kvm->arch.vpic);
-   kvm->arch.vpic = NULL;
-   goto out;
+   kfree(vpic);
+   goto create_irqchip_unlock;
}
} else
-   goto out;
+   goto create_irqchip_unlock;
+   smp_wmb();
+   kvm->arch.vpic = vpic;
+   smp_wmb();
r = kvm_setup_default_irq_routing(kvm);
if (r) {
+   mutex_lock(&kvm->irq_lock);
kfree(kvm->arch.vpic);
kfree(kvm->arch.vioapic);
-   goto out;
+   kvm->arch.vpic = NULL;
+   kvm->arch.vioapic = NULL;
+   mutex_unlock(&kvm->irq_lock);
}
+   create_irqchip_unlock:
+   mutex_unlock(&kvm->lock);
break;
+   }
case KVM_CREATE_PIT:
u.pit_config.flags = KVM_PIT_SPEAKER_DUMMY;
goto create_pit;
Index: kvm/arch/x86/kvm/irq.h
===
--- kvm.orig/arch/x86/kvm/irq.h
+++ kvm/arch/x86/kvm/irq.h
@@ -86,7 +86,11 @@ static inline struct kvm_pic *pic_irqchi
 
 static inline int irqchip_in_kernel(struct kvm *kvm)
 {
-   return pic_irqchip(kvm) != NULL;
+   int ret;
+
+   ret = (pic_irqchip(kvm) != NULL);
+   smp_rmb();
+   return ret;
 }
 
 void kvm_pic_reset(struct kvm_kpic_state *s);


--
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

[patch 0/3] ioctl fixes v3

[Marcelo Tosatti]

Addressing comments.


--
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

Re: BUG with Win7 and user-return-notifier

[Jan Kiszka]

Jan Kiszka wrote:
> Avi Kivity wrote:
>> On 10/29/2009 10:03 AM, Jan Kiszka wrote:
>>> Avi Kivity wrote:
>>>   
 On 10/28/2009 10:40 PM, Jan Kiszka wrote:
 
>   
>> [you can get longer, more detailed traces by using
>> /sys/kernel/debug/tracing/trace instead of dmesg]
>>
>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
>> kvm_msr: msr_read c080 = 0x500
>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
>> kvm_msr: msr_write c080 = 0xd01
>>
>> So Windows is setting EFER.SCE and EFER.NX while in long mode -
>> perfectly reasonable.  Can you rerun with the attached debug patch?
>>
>>
>>  
> Log attached.
>
>
 So the last bits are:

 Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
 efer d01
 Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all
 bits
 Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload

 We're not reloading efer (correctly, as guest efer == host efer), yet
 vmx_save_host_state() fails while loading efer.  I've looked at
 move_msr_up() (which is used by setup_msrs() to partition the msr space
 into reloaded and non-reloaded msrs), and it seems correct.

 Can you see any way where update_transition_efer() returns false, yet
 efer turns up in the first save_nmsrs entries of vmx->guest_msrs?

  
>>> Without understanding the code completely yet: When you push the slot
>>> containing EFER around, do you also update msr_offset_efer?
>>>
>>>
>> We don't, but msr_offset_efer is only used from
>> update_transition_efer(), which is only ever called from setup_msrs()
>> immediately after updating msr_offset_efer.
> 
> Indeed.
> 
>> Of course, it should be an argument to update_transition_efer(), I'll
>> clean up this leftover.
>>
> 
> OK, will see that I can debug this later today.
> 

Haven't found the actual problem yet, but some oddities:

> static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
> {
> ...
>   for (i = 0; i < NR_VMX_MSR; ++i) {
>   u32 index = vmx_msr_index[i];
>   u32 data_low, data_high;
>   u64 data;
>   int j = vmx->nmsrs;
> 
>   if (rdmsr_safe(index, &data_low, &data_high) < 0)
>   continue;
>   if (wrmsr_safe(index, data_low, data_high) < 0)
>   continue;
>   data = data_low | ((u64)data_high << 32);
>   vmx->guest_msrs[j].index = i;
>   vmx->guest_msrs[j].data = 0;
^
Local 'data' drops on the floor. Is that correct (then it deserves a
cleanup)? Previous version did a "guest = host".

> static void vmx_set_efer(struct kvm_vcpu *vcpu, u64 efer)
> {
>   struct vcpu_vmx *vmx = to_vmx(vcpu);
>   struct shared_msr_entry *msr = find_msr_entry(vmx, MSR_EFER);
> 
>   if (!msr)
>   return;
>   vcpu->arch.shadow_efer = efer;
>   if (!msr)
>   return;

One "if (!msr)" too much - really the second one?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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

[PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]

[Dustin Kirkland]

whitelist host virtio networking features

This patch is a followup to 8eca6b1bc770982595db2f7207c65051572436cb,
fixing crashes when guests with 2.6.25 virtio drivers have saturated
virtio network connections.

https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521

That patch should have been whitelisting *_HOST_* rather than the the
*_GUEST_* features.

I tested this by running an Ubuntu 8.04 Hardy guest (2.6.24 kernel +
2.6.25-virtio driver).  I saturated both the incoming, and outgoing
network connection with nc, seeing sustained 6MB/s up and 6MB/s down
bitrates for ~20 minutes.  Previously, this crashed immediately.  Now,
the guest does not crash and maintains network connectivity throughout
the test.

Signed-off-by: Dustin Kirkland 
Signed-off-by: Mark McLoughlin 
Tested-by: Dustin Kirkland 

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index ce8e6cb..27834fa 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -164,10 +164,10 @@ static uint32_t virtio_net_bad_features(VirtIODevice 
*vdev)
 /* Linux kernel 2.6.25.  It understood MAC (as everyone must),
  * but also these: */
 features |= (1 << VIRTIO_NET_F_MAC);
-features |= (1 << VIRTIO_NET_F_GUEST_CSUM);
-features |= (1 << VIRTIO_NET_F_GUEST_TSO4);
-features |= (1 << VIRTIO_NET_F_GUEST_TSO6);
-features |= (1 << VIRTIO_NET_F_GUEST_ECN);
+features |= (1 << VIRTIO_NET_F_CSUM);
+features |= (1 << VIRTIO_NET_F_HOST_TSO4);
+features |= (1 << VIRTIO_NET_F_HOST_TSO6);
+features |= (1 << VIRTIO_NET_F_HOST_ECN);
 
 return features & virtio_net_get_features(vdev);
 }



signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

[Anthony Liguori]

Christoph Hellwig wrote:

On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote:
  

Which patches are those?



http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9

and

http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=a6e6178185786c582141f993272e00521d3f125a
  


Doesn't look like they've gone on the list yet.

When they do, poke me and I'll make sure to process them quickly.  One 
of my short term goals is to get better at handling easy patches more 
quickly.


Regards,

Anthony Liguori


--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

On Thu, 2009-10-29 at 10:13 -0500, Dustin Kirkland wrote:
> On Thu, 2009-10-29 at 15:01 +, Mark McLoughlin wrote:
> > Sorry, should be VIRTIO_NET_F_CSUM ... the rest is correct
> 
> Brilliant!
> 
> Works like a champ.  I'll send a patch in a subsequent email.  Would you
> add a signed-off-by (or whatever), Mark?

Sure,

Signed-off-by: Mark McLoughlin 

or:

Acked-by: Mark McLoughlin 

whichever works :)

Cheers,
Mark.

--
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

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

[Christoph Hellwig]

On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote:
> Which patches are those?

http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9

and

http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=a6e6178185786c582141f993272e00521d3f125a

--
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

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

[Anthony Liguori]

Christoph Hellwig wrote:

On Thu, Oct 29, 2009 at 01:57:40PM +0100, Gerd Hoffmann wrote:
  
Trying to go forward in review+bisect friendly baby steps.  Here is what 
I have now:


http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1

It is far from being completed, will continue tomorrow.  Should give a 
idea of the direction I'm heading to though.  Comments welcome.



Nice.

I had patches for the header renames, too - the current naming is
really awkward.  Would be great if Anthony could take those ASAP.
  


Which patches are those?

Regards,

Anthony Liguori
--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Dustin Kirkland]

On Thu, 2009-10-29 at 15:01 +, Mark McLoughlin wrote:
> Sorry, should be VIRTIO_NET_F_CSUM ... the rest is correct

Brilliant!

Works like a champ.  I'll send a patch in a subsequent email.  Would you
add a signed-off-by (or whatever), Mark?

:-Dustin


signature.asc
Description: This is a digitally signed message part

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

[Arnaud Maillet]

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 ?

As regards, thanks in advance
--
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

Re: qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Michael S. Tsirkin]

On Thu, Oct 29, 2009 at 04:38:22PM +0200, Avi Kivity wrote:
> On 10/29/2009 02:23 PM, Michael S. Tsirkin wrote:
>> On Thu, Oct 29, 2009 at 09:16:43AM +, Mark McLoughlin wrote:
>>
>>> I agree we shouldn't exit in this scenario
>>>  
>> virtio in qemu generally seems to handle guest errors
>> by calling exit(2). This probably makes it easier to notice
>> the problems, but is likely not the right thing to do.
>>
>
> Right, the thinking was the guest is shooting itself in the foot and  
> hitting, but a guest can delegate control of a device to unprivileged  
> code (for example device assignment in kvm),

When we emulate iommu, yes.

> which would allow this unprivileged code to kill the guest.

With usb emulation, we can have:
drivers/usb/class/usblp.c:343:static const char *usblp_messages[] = {
"ok", "out of paper", "off-line", "on fire" };

> -- 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

On Thu, 2009-10-29 at 10:01 -0500, Dustin Kirkland wrote:
> On Thu, 2009-10-29 at 14:48 +, Mark McLoughlin wrote:
> > Ah, it all makes sense now.
> > 
> > I was getting confused between HOST_* and GUEST_*
> > 
> > this should have been:
> > 
> > features |= (1 << VIRTIO_NET_F_MAC);
> > features |= (1 << VIRTIO_NET_F_HOST_CSUM);
> > features |= (1 << VIRTIO_NET_F_HOST_TSO4);
> > features |= (1 << VIRTIO_NET_F_HOST_TSO6);
> > features |= (1 << VIRTIO_NET_F_HOST_ECN);
> > 
> > Could you try that Dustin?
> 
> Hmm, not sure I'm doing this correctly...  I tried changing the
> following, but looks like I might also have to define these as well,
> since:
> 
> /tmp/qemu-kvm/qemu-kvm/hw/virtio-net.c:167: error:
> ‘VIRTIO_NET_F_HOST_CSUM’ undeclared (first use in this function)

Sorry, should be VIRTIO_NET_F_CSUM ... the rest is correct

Thanks,
mark.

--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Dustin Kirkland]

On Thu, 2009-10-29 at 14:48 +, Mark McLoughlin wrote:
> Ah, it all makes sense now.
> 
> I was getting confused between HOST_* and GUEST_*
> 
> this should have been:
> 
> features |= (1 << VIRTIO_NET_F_MAC);
> features |= (1 << VIRTIO_NET_F_HOST_CSUM);
> features |= (1 << VIRTIO_NET_F_HOST_TSO4);
> features |= (1 << VIRTIO_NET_F_HOST_TSO6);
> features |= (1 << VIRTIO_NET_F_HOST_ECN);
> 
> Could you try that Dustin?

Hmm, not sure I'm doing this correctly...  I tried changing the
following, but looks like I might also have to define these as well,
since:

/tmp/qemu-kvm/qemu-kvm/hw/virtio-net.c:167: error:
‘VIRTIO_NET_F_HOST_CSUM’ undeclared (first use in this function)


diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index ce8e6cb..6582e69 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -164,10 +164,10 @@ static uint32_t virtio_net_bad_features(VirtIODevice 
*vdev)
 /* Linux kernel 2.6.25.  It understood MAC (as everyone must),
  * but also these: */
 features |= (1 << VIRTIO_NET_F_MAC);
-features |= (1 << VIRTIO_NET_F_GUEST_CSUM);
-features |= (1 << VIRTIO_NET_F_GUEST_TSO4);
-features |= (1 << VIRTIO_NET_F_GUEST_TSO6);
-features |= (1 << VIRTIO_NET_F_GUEST_ECN);
+features |= (1 << VIRTIO_NET_F_HOST_CSUM);
+features |= (1 << VIRTIO_NET_F_HOST_TSO4);
+features |= (1 << VIRTIO_NET_F_HOST_TSO6);
+features |= (1 << VIRTIO_NET_F_HOST_ECN);
 
 return features & virtio_net_get_features(vdev);
 }



signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

[Christoph Hellwig]

On Thu, Oct 29, 2009 at 01:57:40PM +0100, Gerd Hoffmann wrote:
> Trying to go forward in review+bisect friendly baby steps.  Here is what 
> I have now:
> 
> http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1
> 
> It is far from being completed, will continue tomorrow.  Should give a 
> idea of the direction I'm heading to though.  Comments welcome.

Nice.

I had patches for the header renames, too - the current naming is
really awkward.  Would be great if Anthony could take those ASAP.

Btw, I also splitted out a cdrom.h from the new scsi.h, not sure if it's
worth it for the two prototypes.

Just wondering, shouldn't scsi-bus.c just become scsi.c now that it's
growing various non-bus glue bits?
--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

On Thu, 2009-10-29 at 09:46 -0500, Dustin Kirkland wrote:
> On Thu, 2009-10-29 at 09:34 -0500, Dustin Kirkland wrote:
> > In the mean time, Hardy's kernel is in git here:
> > 
> > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary
> 
> I'll save you a few clicks...
> 
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/net/virtio_net.c;h=d1a200ff5fd266c05e9a876e5e4e550737f77d84;hb=HEAD

Actually, what would save more clicks is if:

  git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git

was listed in web interface. Took me a while to find:

  https://wiki.ubuntu.com/KernelTeam/KernelGitGuide

:-)

Thanks,
Mark.

--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

On Thu, 2009-10-29 at 09:39 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote:
> >   
> >> Mark McLoughlin wrote:
> >> 
>   tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
>  being called and get an mtu of 1500 on virbr0 using his birdge.sh script.
> 
>  virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 
>  'size' + 10 'virtio_net_hdr')
>  and the guest only had 1524 bytes of space in its input descriptors.
>  
>  
> >>> Okay, that sounds like a bug in Dustin's version of the guest virtio-net
> >>> driver - if it is only supplying 1524 byte buffers, it should not be
> >>> saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature
> >>>   
> >>>   
> >> See:
> >>
> >> commit 8eca6b1bc770982595db2f7207c65051572436cb
> >> Author: aliguori 
> >> Date:   Sun Apr 5 17:40:08 2009 +
> >>
> >> Fix oops on 2.6.25 guest (Rusty Russell)
> >>
> >> I believe this is behind the following:
> >> https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
> >>
> >> virtio_pci in 2.6.25 didn't do feature negotiation correctly: it 
> >> acked every
> >> bit.  Fortunately, we can detect this.
> >>
> >> Signed-off-by: Rusty Russell 
> >> Signed-off-by: Anthony Liguori 
> >>
> >> It looks like Rusty's fix wasn't enough.  If I change virtio-net to only 
> >> advertise F_MAC, we don't run into this problem.
> >> 
> >
> > If it's not acking VBAD_FEATURE, then it doesn't sound like the same
> > issue
> >   
> 
> It was acking VBAD_FEATURE when I tested it.
> 
> But if you look at the patch, it whitelists the following features:
> 
> features |= (1 << VIRTIO_NET_F_MAC);
> features |= (1 << VIRTIO_NET_F_GUEST_CSUM);
> features |= (1 << VIRTIO_NET_F_GUEST_TSO4);
> features |= (1 << VIRTIO_NET_F_GUEST_TSO6);
> features |= (1 << VIRTIO_NET_F_GUEST_ECN);

Ah, it all makes sense now.

I was getting confused between HOST_* and GUEST_*

this should have been:

features |= (1 << VIRTIO_NET_F_MAC);
features |= (1 << VIRTIO_NET_F_HOST_CSUM);
features |= (1 << VIRTIO_NET_F_HOST_TSO4);
features |= (1 << VIRTIO_NET_F_HOST_TSO6);
features |= (1 << VIRTIO_NET_F_HOST_ECN);

Could you try that Dustin?

> Which is why it's ack'ing TSO4.   Removing TSO4 didn't seem to fix it 
> for me.

Odd.

Cheers,
Mark.

--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Dustin Kirkland]

On Thu, 2009-10-29 at 09:34 -0500, Dustin Kirkland wrote:
> In the mean time, Hardy's kernel is in git here:
> 
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary

I'll save you a few clicks...

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/net/virtio_net.c;h=d1a200ff5fd266c05e9a876e5e4e550737f77d84;hb=HEAD

:-dustin


signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Dustin Kirkland]

On Thu, 2009-10-29 at 09:16 +, Mark McLoughlin wrote:
> Hi Dustin,
> 
> On Wed, 2009-10-28 at 14:22 -0500, Dustin Kirkland wrote:
> > I believe that we have identified a regression in qemu-kvm-0.11.0.
> 
> Regression versus which previous version of qemu-kvm?

Okay, sorry for the ambiguity.  I actually had to clarify this for
myself.  The regression is as compared to the kvm-84 package that the
previous version of Ubuntu (9.04 Jaunty) carried.

In this package, we carried the attached patch from Anthony Liguori.

I had incorrectly assumed that this patch made it into the upstream
tree.  As Anthony stated in his earlier email, a different
implementation of the fix from Rusty was committed instead.  The fix as
committed doesn't quite solve the problem as we're experiencing it.

:-Dustin
Work around broken virtio drivers in 2.6.26

Signed-off-by: Anthony Liguori 

diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 9bce3a0..5b615f9 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -120,6 +120,9 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
 
 if (tap_has_vnet_hdr(host)) {
 tap_using_vnet_hdr(host, 1);
+#if 0
+/* Stop advertising advanced features until we work around the fact
+ * that this is totally broken in 2.6.26 kernels */
 features |= (1 << VIRTIO_NET_F_CSUM);
 features |= (1 << VIRTIO_NET_F_GUEST_CSUM);
 features |= (1 << VIRTIO_NET_F_GUEST_TSO4);
@@ -130,6 +133,7 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
 features |= (1 << VIRTIO_NET_F_HOST_ECN);
 features |= (1 << VIRTIO_NET_F_MRG_RXBUF);
 /* Kernel can't actually handle UFO in software currently. */
+#endif
 }
 #endif
 
@@ -374,8 +378,14 @@ static int receive_header(VirtIONet *n, struct iovec *iov, int iovcnt,
 struct virtio_net_hdr *hdr = iov[0].iov_base;
 int offset = 0;
 
+#if 0
 hdr->flags = 0;
 hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE;
+#else
+/* we need to clear out the whole header, including any garbage that may be
+ */
+memset(hdr, 0, sizeof(*hdr));
+#endif
 
 #ifdef TAP_VNET_HDR
 if (tap_has_vnet_hdr(n->vc->vlan->first_client)) {


signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Dustin Kirkland]

On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote:
> Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009:
> > Assuming this is something like the virtio-net in 2.6.26, there was no
> > receivable buffers support so (as Scott points out) it must be that
> > we've read a packet from the tap device which is >1514 bytes (or >1524
> > bytes with IFF_VNET_HDR) but the guest has not supplied buffers which
> > are large enough to take it
> 
> > One thing to check is that the tap device is being initialized by
> > qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO
> > should not be enabled, because the guest cannot handle large GSO packets
> 
> > Another possibility is that the MTU on the bridge in the host is too
> > large and that's what's causing the large packets to be sent
> 
> Using Dustin's image, I see:
>   virtio_net_set_features(features: 0x0930)
>   tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
> being called and get an mtu of 1500 on virbr0 using his birdge.sh script.
> 
> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 
> 10 'virtio_net_hdr')
> and the guest only had 1524 bytes of space in its input descriptors.
> 
> BTW, I can also reproduce this running Dustin's image inside Fedora 11's 
> qemu-0.10.6-9.fc11.x86_64.
> 
> The patch I posted earlier actually only applies to the 0.10 branch, here's a 
> patch that compiles for 0.11:


Hi Scott,

Thanks for this.  Testing this, kvm doesn't crash.  And the guest has
working network connectivity, until I saturate the network connection
with nc.  At that point, the guest loses network connectivity all
together.  So the fix is not quite ideal, yet.

:-Dustin


signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Anthony Liguori]

Mark McLoughlin wrote:

On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote:
  

Mark McLoughlin wrote:


tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
being called and get an mtu of 1500 on virbr0 using his birdge.sh script.

virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 
'virtio_net_hdr')
and the guest only had 1524 bytes of space in its input descriptors.



Okay, that sounds like a bug in Dustin's version of the guest virtio-net
driver - if it is only supplying 1524 byte buffers, it should not be
saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature
  
  

See:

commit 8eca6b1bc770982595db2f7207c65051572436cb
Author: aliguori 
Date:   Sun Apr 5 17:40:08 2009 +

Fix oops on 2.6.25 guest (Rusty Russell)
   
I believe this is behind the following:

https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
   
virtio_pci in 2.6.25 didn't do feature negotiation correctly: it 
acked every

bit.  Fortunately, we can detect this.
   
Signed-off-by: Rusty Russell 

Signed-off-by: Anthony Liguori 

It looks like Rusty's fix wasn't enough.  If I change virtio-net to only 
advertise F_MAC, we don't run into this problem.



If it's not acking VBAD_FEATURE, then it doesn't sound like the same
issue
  


It was acking VBAD_FEATURE when I tested it.

But if you look at the patch, it whitelists the following features:

   features |= (1 << VIRTIO_NET_F_MAC);
   features |= (1 << VIRTIO_NET_F_GUEST_CSUM);
   features |= (1 << VIRTIO_NET_F_GUEST_TSO4);
   features |= (1 << VIRTIO_NET_F_GUEST_TSO6);
   features |= (1 << VIRTIO_NET_F_GUEST_ECN);

Which is why it's ack'ing TSO4.   Removing TSO4 didn't seem to fix it 
for me.


Regards,

Anthony Liguori
--
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

Re: qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Avi Kivity]

On 10/29/2009 02:23 PM, Michael S. Tsirkin wrote:

On Thu, Oct 29, 2009 at 09:16:43AM +, Mark McLoughlin wrote:
   

I agree we shouldn't exit in this scenario
 

virtio in qemu generally seems to handle guest errors
by calling exit(2). This probably makes it easier to notice
the problems, but is likely not the right thing to do.
   


Right, the thinking was the guest is shooting itself in the foot and 
hitting, but a guest can delegate control of a device to unprivileged 
code (for example device assignment in kvm), which would allow this 
unprivileged code to kill the guest.


--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Dustin Kirkland]

On Thu, 2009-10-29 at 14:25 +, Mark McLoughlin wrote:
> On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote:
> > Mark McLoughlin wrote:
> > >
> > >>  tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
> > >> being called and get an mtu of 1500 on virbr0 using his birdge.sh script.
> > >>
> > >> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 
> > >> 'size' + 10 'virtio_net_hdr')
> > >> and the guest only had 1524 bytes of space in its input descriptors.
> > >> 
> > >
> > > Okay, that sounds like a bug in Dustin's version of the guest virtio-net
> > > driver - if it is only supplying 1524 byte buffers, it should not be
> > > saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature
> > >   
> > 
> > See:
> > 
> > commit 8eca6b1bc770982595db2f7207c65051572436cb
> > Author: aliguori 
> > Date:   Sun Apr 5 17:40:08 2009 +
> > 
> > Fix oops on 2.6.25 guest (Rusty Russell)
> >
> > I believe this is behind the following:
> > https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
> >
> > virtio_pci in 2.6.25 didn't do feature negotiation correctly: it 
> > acked every
> > bit.  Fortunately, we can detect this.
> >
> > Signed-off-by: Rusty Russell 
> > Signed-off-by: Anthony Liguori 
> > 
> > It looks like Rusty's fix wasn't enough.  If I change virtio-net to only 
> > advertise F_MAC, we don't run into this problem.
> 
> If it's not acking VBAD_FEATURE, then it doesn't sound like the same
> issue
> 
> It's also not acking e.g. MRG_RXBUF, which suggests that it is
> selectively acking features, and choosing to ack TSO4
> 
> A quick look through the guest driver code should clear up the
> confusion. Dustion, got a pointer?

Hi Mark,

I'm currently testing Scott's patch above.

In the mean time, Hardy's kernel is in git here:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary

Thanks,
:-Dustin


signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> >
> >>tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
> >> being called and get an mtu of 1500 on virbr0 using his birdge.sh script.
> >>
> >> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' 
> >> + 10 'virtio_net_hdr')
> >> and the guest only had 1524 bytes of space in its input descriptors.
> >> 
> >
> > Okay, that sounds like a bug in Dustin's version of the guest virtio-net
> > driver - if it is only supplying 1524 byte buffers, it should not be
> > saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature
> >   
> 
> See:
> 
> commit 8eca6b1bc770982595db2f7207c65051572436cb
> Author: aliguori 
> Date:   Sun Apr 5 17:40:08 2009 +
> 
> Fix oops on 2.6.25 guest (Rusty Russell)
>
> I believe this is behind the following:
> https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
>
> virtio_pci in 2.6.25 didn't do feature negotiation correctly: it 
> acked every
> bit.  Fortunately, we can detect this.
>
> Signed-off-by: Rusty Russell 
> Signed-off-by: Anthony Liguori 
> 
> It looks like Rusty's fix wasn't enough.  If I change virtio-net to only 
> advertise F_MAC, we don't run into this problem.

If it's not acking VBAD_FEATURE, then it doesn't sound like the same
issue

It's also not acking e.g. MRG_RXBUF, which suggests that it is
selectively acking features, and choosing to ack TSO4

A quick look through the guest driver code should clear up the
confusion. Dustion, got a pointer?

Thanks,
Mark.

--
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

[PATCH] Add ks files for RHEL5,RHEL4,RHEL3 series products

[Bear]

Signed-off-by: Bear 
---
 client/tests/kvm/kvm_tests.cfg.sample|   54 +++---
 client/tests/kvm/unattended/RHEL-3-series.ks |   39 ++
 client/tests/kvm/unattended/RHEL-4-series.ks |   40 +++
 client/tests/kvm/unattended/RHEL-5-series.ks |   39 ++
 4 files changed, 166 insertions(+), 6 deletions(-)
 create mode 100644 client/tests/kvm/unattended/RHEL-3-series.ks
 create mode 100644 client/tests/kvm/unattended/RHEL-4-series.ks
 create mode 100644 client/tests/kvm/unattended/RHEL-5-series.ks

diff --git a/client/tests/kvm/kvm_tests.cfg.sample 
b/client/tests/kvm/kvm_tests.cfg.sample
index 573206c..8be0565 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -432,7 +432,14 @@ variants:
 cdrom=linux/RHEL-5.3-i386-DVD.iso
 md5sum=371c62851611fd32ead440df6f24a296
 md5sum_1m=242318dd44152210f6ff6cdda1bfbf51
-
+unattended_install:
+cdrom=linux/RHEL-5.3-i386-DVD.iso
+md5sum=371c62851611fd32ead440df6f24a296
+md5sum_1m=242318dd44152210f6ff6cdda1bfbf51
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-5-series.ks
 - 5.3.x86_64:
 no setup
 image_name = rhel5-64
@@ -441,7 +448,14 @@ variants:
 cdrom=linux/RHEL-5.3-x86_64-DVD.iso
 md5sum=c5ed6b284410f4d8212cafc78fd7a8c5
 md5sum_1m=b999f437583098ea5bbd56fb1de1d011
-
+unattended_install:
+cdrom=linux/RHEL-5.3-x86_64-DVD.iso
+md5sum=c5ed6b284410f4d8212cafc78fd7a8c5
+md5sum_1m=b999f437583098ea5bbd56fb1de1d011
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-5-series.ks
 - 4.7.i386:
 no setup autotest
 image_name = rhel4-32
@@ -450,7 +464,14 @@ variants:
 cdrom=linux/RHEL-4.7-i386-DVD.iso
 md5sum=ee5092653732a88ddbaf8eef2484c500
 md5sum_1m=127081cbed825d7232331a2083975528
-
+unattended_install:
+cdrom=linux/RHEL-4.7-i386-DVD.iso
+md5sum=ee5092653732a88ddbaf8eef2484c500
+md5sum_1m=127081cbed825d7232331a2083975528
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-4-series.ks
 - 4.7.x86_64:
 no setup autotest
 image_name = rhel4-64
@@ -459,7 +480,14 @@ variants:
 cdrom=linux/RHEL-4.7-x86_64-DVD.iso
 md5sum=ea9dae16dd86f7d94092d0e672333292
 md5sum_1m=58fa63eaee68e269f4cb1d2edf479792
-
+unattended_install:
+cdrom=linux/RHEL-4.7-x86_64-DVD.iso
+md5sum=ea9dae16dd86f7d94092d0e672333292
+md5sum_1m=58fa63eaee68e269f4cb1d2edf479792
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-4-series.ks
 - 3.9.i386:
 no setup autotest linux_s3
 image_name = rhel3-32
@@ -468,7 +496,14 @@ variants:
 cdrom=linux/RHEL-3.9-i386-DVD.iso
 md5sum=ddd11a1cb104119039b0fa05df6d52b8
 md5sum_1m=5f10c9417c7b8372b3456c1b5f3f9ed0
-
+unattended_install:
+cdrom=linux/RHEL-3.9-i386-DVD.iso
+md5sum=ddd11a1cb104119039b0fa05df6d52b8
+md5sum_1m=5f10c9417c7b8372b3456c1b5f3f9ed0
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+   

[PATCH] Add ks files for RHEL5,RHEL4,RHEL3 series products

[Bear]

Signed-off-by: Bear 
---
 client/tests/kvm/kvm_tests.cfg.sample|   54 +++---
 client/tests/kvm/unattended/RHEL-3-series.ks |   39 ++
 client/tests/kvm/unattended/RHEL-4-series.ks |   40 +++
 client/tests/kvm/unattended/RHEL-5-series.ks |   39 ++
 4 files changed, 166 insertions(+), 6 deletions(-)
 create mode 100644 client/tests/kvm/unattended/RHEL-3-series.ks
 create mode 100644 client/tests/kvm/unattended/RHEL-4-series.ks
 create mode 100644 client/tests/kvm/unattended/RHEL-5-series.ks

diff --git a/client/tests/kvm/kvm_tests.cfg.sample 
b/client/tests/kvm/kvm_tests.cfg.sample
index 573206c..8be0565 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -432,7 +432,14 @@ variants:
 cdrom=linux/RHEL-5.3-i386-DVD.iso
 md5sum=371c62851611fd32ead440df6f24a296
 md5sum_1m=242318dd44152210f6ff6cdda1bfbf51
-
+unattended_install:
+cdrom=linux/RHEL-5.3-i386-DVD.iso
+md5sum=371c62851611fd32ead440df6f24a296
+md5sum_1m=242318dd44152210f6ff6cdda1bfbf51
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-5-series.ks
 - 5.3.x86_64:
 no setup
 image_name = rhel5-64
@@ -441,7 +448,14 @@ variants:
 cdrom=linux/RHEL-5.3-x86_64-DVD.iso
 md5sum=c5ed6b284410f4d8212cafc78fd7a8c5
 md5sum_1m=b999f437583098ea5bbd56fb1de1d011
-
+unattended_install:
+cdrom=linux/RHEL-5.3-x86_64-DVD.iso
+md5sum=c5ed6b284410f4d8212cafc78fd7a8c5
+md5sum_1m=b999f437583098ea5bbd56fb1de1d011
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-5-series.ks
 - 4.7.i386:
 no setup autotest
 image_name = rhel4-32
@@ -450,7 +464,14 @@ variants:
 cdrom=linux/RHEL-4.7-i386-DVD.iso
 md5sum=ee5092653732a88ddbaf8eef2484c500
 md5sum_1m=127081cbed825d7232331a2083975528
-
+unattended_install:
+cdrom=linux/RHEL-4.7-i386-DVD.iso
+md5sum=ee5092653732a88ddbaf8eef2484c500
+md5sum_1m=127081cbed825d7232331a2083975528
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-4-series.ks
 - 4.7.x86_64:
 no setup autotest
 image_name = rhel4-64
@@ -459,7 +480,14 @@ variants:
 cdrom=linux/RHEL-4.7-x86_64-DVD.iso
 md5sum=ea9dae16dd86f7d94092d0e672333292
 md5sum_1m=58fa63eaee68e269f4cb1d2edf479792
-
+unattended_install:
+cdrom=linux/RHEL-4.7-x86_64-DVD.iso
+md5sum=ea9dae16dd86f7d94092d0e672333292
+md5sum_1m=58fa63eaee68e269f4cb1d2edf479792
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+unattended_file = unattended/RHEL-4-series.ks
 - 3.9.i386:
 no setup autotest linux_s3
 image_name = rhel3-32
@@ -468,7 +496,14 @@ variants:
 cdrom=linux/RHEL-3.9-i386-DVD.iso
 md5sum=ddd11a1cb104119039b0fa05df6d52b8
 md5sum_1m=5f10c9417c7b8372b3456c1b5f3f9ed0
-
+unattended_install:
+cdrom=linux/RHEL-3.9-i386-DVD.iso
+md5sum=ddd11a1cb104119039b0fa05df6d52b8
+md5sum_1m=5f10c9417c7b8372b3456c1b5f3f9ed0
+tftp = "images/tftpboot"
+extra_params += " -bootp /pxelinux.0 -boot n"
+kernel_args = "ks=floppy nicdelay=60"
+   

Re: [patch 1/3] KVM: x86: disallow multiple KVM_CREATE_IRQCHIP

[Marcelo Tosatti]

On Thu, Oct 29, 2009 at 11:32:48AM +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 28, 2009 at 06:42:38PM -0200, Marcelo Tosatti wrote:
> > Otherwise kvm will leak memory on multiple KVM_CREATE_IRQCHIP. 
> > Also serialize multiple accesses with kvm->lock.
> > 
> > Signed-off-by: Marcelo Tosatti 
> > 
> > Index: kvm/arch/x86/kvm/x86.c
> > ===
> > --- kvm.orig/arch/x86/kvm/x86.c
> > +++ kvm/arch/x86/kvm/x86.c
> > @@ -2362,25 +2362,38 @@ long kvm_arch_vm_ioctl(struct file *filp
> > if (r)
> > goto out;
> > break;
> > -   case KVM_CREATE_IRQCHIP:
> > +   case KVM_CREATE_IRQCHIP: {
> > +   struct kvm_pic *vpic;
> > +
> > +   mutex_lock(&kvm->lock);
> > +   r = -EEXIST;
> > +   if (kvm->arch.vpic)
> > +   goto create_irqchip_unlock;
> > r = -ENOMEM;
> > -   kvm->arch.vpic = kvm_create_pic(kvm);
> > -   if (kvm->arch.vpic) {
> > +   vpic = kvm_create_pic(kvm);
> > +   if (vpic) {
> > r = kvm_ioapic_init(kvm);
> > if (r) {
> > -   kfree(kvm->arch.vpic);
> > -   kvm->arch.vpic = NULL;
> > -   goto out;
> > +   kfree(vpic);
> > +   goto create_irqchip_unlock;
> > }
> > } else
> > -   goto out;
> > +   goto create_irqchip_unlock;
> > +   kvm->arch.vpic = vpic;
> > +   smp_wmb();
> 
> Hmm, I think we want the reverse order:
>   smp_wmb();
>   kvm->arch.vpic = vpic;
> 
> The point is preventing vpic pointer
> from being written to memory before vpic data itself.
> Right?

Point is preventing arch.vpic assignment (and everything before) from
reordering with kvm_setup_default_irq_routing (you cannot have a present
irq route without arch.vioapic or arch.vpic set, since kvm_set_irq
assumes they are present).

But, now that you say, we also want a smp_wmb before vpic assignment so
the irqchip_in_kernel() test is safe (that is, everything including
vioapic is in place before irqchip_in_kernel() can succeed).

I'll resend, thanks.

> BTW, the reason that we have wmb here but no read barrier anywhere is
> that this code is x86 specific and reads are not reordered across a
> dependency on x86. Writes are also not reordered on x86, so this really
> acts as a compiler barrier, but I agree it's better to be portable.  So
> maybe, for documentation purposes, we should add read_barrier_depends
> within irqchip_in_kernel()?
> 
> > r = kvm_setup_default_irq_routing(kvm);
> > if (r) {
> > +   mutex_lock(&kvm->irq_lock);
> > kfree(kvm->arch.vpic);
> > kfree(kvm->arch.vioapic);
> > -   goto out;
> > +   kvm->arch.vpic = NULL;
> > +   kvm->arch.vioapic = NULL;
> > +   mutex_unlock(&kvm->irq_lock);
> > }
> > +   create_irqchip_unlock:
> > +   mutex_unlock(&kvm->lock);
> > break;
> > +   }
> > case KVM_CREATE_PIT:
> > u.pit_config.flags = KVM_PIT_SPEAKER_DUMMY;
> > goto create_pit;
> > 
--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Anthony Liguori]

Mark McLoughlin wrote:



tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
being called and get an mtu of 1500 on virbr0 using his birdge.sh script.

virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 
'virtio_net_hdr')
and the guest only had 1524 bytes of space in its input descriptors.



Okay, that sounds like a bug in Dustin's version of the guest virtio-net
driver - if it is only supplying 1524 byte buffers, it should not be
saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature
  


See:

commit 8eca6b1bc770982595db2f7207c65051572436cb
Author: aliguori 
Date:   Sun Apr 5 17:40:08 2009 +

   Fix oops on 2.6.25 guest (Rusty Russell)
  
   I believe this is behind the following:

   https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
  
   virtio_pci in 2.6.25 didn't do feature negotiation correctly: it 
acked every

   bit.  Fortunately, we can detect this.
  
   Signed-off-by: Rusty Russell 

   Signed-off-by: Anthony Liguori 

It looks like Rusty's fix wasn't enough.  If I change virtio-net to only 
advertise F_MAC, we don't run into this problem.


Regards,

Anthony Liguori
--
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

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

[Gerd Hoffmann]

On 10/29/09 05:37, Christoph Hellwig wrote:

So something like
- Get next request
- Attach iovec/bounc-buffer
- handle request (command/write/read)
- complete request (callback)


Btw, from some previuous attempts to sort out this code here are some
thing that I think would be beneficial:


Trying to go forward in review+bisect friendly baby steps.  Here is what 
I have now:


http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1

It is far from being completed, will continue tomorrow.  Should give a 
idea of the direction I'm heading to though.  Comments welcome.


/me leaves to pick up the kids,

  Gerd
--
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

Re: kvm memory leak (Was Re: vhost-net patches)

[Avi Kivity]

On 10/29/2009 02:21 PM, Avi Kivity wrote:

On 10/28/2009 06:46 PM, Michael S. Tsirkin wrote:

On Tue, Oct 27, 2009 at 09:36:18AM -0700, Shirley Ma wrote:

Hello Michael,

On Tue, 2009-10-27 at 17:27 +0200, Michael S. Tsirkin wrote:

Possibly GFP_ATOMIC allocations in vring_add_indirect are failing?
Is there a chance you are tight on guest memory for some reason?
with vhost, virtio does currently consume a bit more memory than
with userspace backend.

I did see memory leak on host every time after exiting guest. I don't
know where. Do you see it?

I don't see a leak specific to vhost. However, even without vhost,
starting up guest increases kmalloc-128 counter in /proc/slabinfo
and this fails to go down when qemu is killed.

Anyone else seeing this?


I'm seeing it, but starting a new guest seems to reclaim this memory.  
I'll enable debug and see what's the cause.




kmemleak doesn't see any kvm memory leaks.

--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Michael S. Tsirkin]

On Thu, Oct 29, 2009 at 09:16:43AM +, Mark McLoughlin wrote:
> I agree we shouldn't exit in this scenario

virtio in qemu generally seems to handle guest errors
by calling exit(2). This probably makes it easier to notice
the problems, but is likely not the right thing to do.

A simple way to tell guest there's a problem is by
writing a value > ring size into used ring.

-- 
MST
--
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

Re: kvm memory leak (Was Re: vhost-net patches)

[Avi Kivity]

On 10/28/2009 06:46 PM, Michael S. Tsirkin wrote:

On Tue, Oct 27, 2009 at 09:36:18AM -0700, Shirley Ma wrote:
   

Hello Michael,

On Tue, 2009-10-27 at 17:27 +0200, Michael S. Tsirkin wrote:
 

Possibly GFP_ATOMIC allocations in vring_add_indirect are failing?
Is there a chance you are tight on guest memory for some reason?
with vhost, virtio does currently consume a bit more memory than
with userspace backend.
   

I did see memory leak on host every time after exiting guest. I don't
know where. Do you see it?
 

I don't see a leak specific to vhost. However, even without vhost,
starting up guest increases kmalloc-128 counter in /proc/slabinfo
and this fails to go down when qemu is killed.

Anyone else seeing this?
   


I'm seeing it, but starting a new guest seems to reclaim this memory.  
I'll enable debug and see what's the cause.


--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Scott Tsai]

> Hmm - 0x930 doesn't seem right. Is that 930 decimal, 0x3a2 hex?

yup. printf format string typo.
--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote:
> Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009:
> > Assuming this is something like the virtio-net in 2.6.26, there was no
> > receivable buffers support so (as Scott points out) it must be that
> > we've read a packet from the tap device which is >1514 bytes (or >1524
> > bytes with IFF_VNET_HDR) but the guest has not supplied buffers which
> > are large enough to take it
> 
> > One thing to check is that the tap device is being initialized by
> > qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO
> > should not be enabled, because the guest cannot handle large GSO packets
> 
> > Another possibility is that the MTU on the bridge in the host is too
> > large and that's what's causing the large packets to be sent
> 
> Using Dustin's image, I see:
>   virtio_net_set_features(features: 0x0930)

Hmm - 0x930 doesn't seem right. Is that 930 decimal, 0x3a2 hex?

>   tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
> being called and get an mtu of 1500 on virbr0 using his birdge.sh script.
> 
> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 
> 10 'virtio_net_hdr')
> and the guest only had 1524 bytes of space in its input descriptors.

Okay, that sounds like a bug in Dustin's version of the guest virtio-net
driver - if it is only supplying 1524 byte buffers, it should not be
saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature

Cheers,
Mark.

--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Scott Tsai]

Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009:
> Assuming this is something like the virtio-net in 2.6.26, there was no
> receivable buffers support so (as Scott points out) it must be that
> we've read a packet from the tap device which is >1514 bytes (or >1524
> bytes with IFF_VNET_HDR) but the guest has not supplied buffers which
> are large enough to take it

> One thing to check is that the tap device is being initialized by
> qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO
> should not be enabled, because the guest cannot handle large GSO packets

> Another possibility is that the MTU on the bridge in the host is too
> large and that's what's causing the large packets to be sent

Using Dustin's image, I see:
virtio_net_set_features(features: 0x0930)
tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
being called and get an mtu of 1500 on virbr0 using his birdge.sh script.

virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 
'virtio_net_hdr')
and the guest only had 1524 bytes of space in its input descriptors.

BTW, I can also reproduce this running Dustin's image inside Fedora 11's 
qemu-0.10.6-9.fc11.x86_64.

The patch I posted earlier actually only applies to the 0.10 branch, here's a 
patch that compiles for 0.11:

>From 06aa7db0705cf747c35cbcbd09d0e37713f16fe4 Mon Sep 17 00:00:00 2001
From: Scott Tsai 
Date: Thu, 29 Oct 2009 10:56:12 +0800
Subject: [PATCH] virtio-net: drop large packets when no mergable_rx_bufs

Currently virtio-net calls exit(1) when it receives a large packet and
the VIRTIO_NET_F_MRG_RXBUF feature isn't set.
Change it to drop the packet instead.

see: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521
---
 hw/virtio-net.c |8 +++-
 hw/virtio.c |   33 +
 2 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index ce8e6cb..2e6725b 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -502,6 +502,8 @@ static int receive_filter(VirtIONet *n, const uint8_t *buf, 
int size)
 return 0;
 }
 
+int buffer_fits_in_virtqueue_top(VirtQueue *vq, int size);
+
 static ssize_t virtio_net_receive2(VLANClientState *vc, const uint8_t *buf, 
size_t size, int raw)
 {
 VirtIONet *n = vc->opaque;
@@ -518,6 +520,10 @@ static ssize_t virtio_net_receive2(VLANClientState *vc, 
const uint8_t *buf, size
 hdr_len = n->mergeable_rx_bufs ?
 sizeof(struct virtio_net_hdr_mrg_rxbuf) : sizeof(struct 
virtio_net_hdr);
 
+/* drop packet instead of truncating it */
+if (!n->mergeable_rx_bufs && !buffer_fits_in_virtqueue_top(n->rx_vq, 
hdr_len + size))
+return;
+
 offset = i = 0;
 
 while (offset < size) {
@@ -531,7 +537,7 @@ static ssize_t virtio_net_receive2(VLANClientState *vc, 
const uint8_t *buf, size
 virtqueue_pop(n->rx_vq, &elem) == 0) {
 if (i == 0)
 return -1;
-fprintf(stderr, "virtio-net truncating packet\n");
+fprintf(stderr, "virtio-net truncating packet: mergable_rx_bufs: 
%d\n", n->mergeable_rx_bufs);
 exit(1);
 }
 
diff --git a/hw/virtio.c b/hw/virtio.c
index 41e7ca2..d9e0353 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -356,6 +356,39 @@ int virtqueue_avail_bytes(VirtQueue *vq, int in_bytes, int 
out_bytes)
 return 0;
 }
 
+/* buffer_fits_in_virtqueue_top: returns true if a 'size' byte buffer could 
fit in the
+ * input descriptors that virtqueue_pop() would have returned
+ */
+int buffer_fits_in_virtqueue_top(VirtQueue *vq, int size);
+
+int buffer_fits_in_virtqueue_top(VirtQueue *vq, int size)
+{
+unsigned int i, max;
+int input_iov_len_sum;
+target_phys_addr_t desc_pa;
+
+if (!virtqueue_num_heads(vq, vq->last_avail_idx))
+return 0;
+
+desc_pa = vq->vring.desc;
+max = vq->vring.num;
+i = virtqueue_get_head(vq, vq->last_avail_idx);
+
+if (vring_desc_flags(desc_pa, i) & VRING_DESC_F_INDIRECT) {
+/* loop over the indirect descriptor table */
+max = vring_desc_len(desc_pa, i) / sizeof(VRingDesc);
+desc_pa = vring_desc_addr(desc_pa, i);
+i = 0;
+}
+
+input_iov_len_sum = 0;
+do {
+if (vring_desc_flags(desc_pa, i) & VRING_DESC_F_WRITE)
+input_iov_len_sum += vring_desc_len(desc_pa, i);
+} while ((i = virtqueue_next_desc(desc_pa, i, max)) != vq->vring.num);
+return input_iov_len_sum >= size;
+}
+
 int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
 {
 unsigned int i, head, max;
-- 
1.6.2.5
--
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

Re: xp guest, blue screen c0000221 on boot

[Gerd Hoffmann]

On 10/28/09 16:27, Andrew Olney wrote:

Thanks. In pursuing this suggestion I discovered that I also can't make
new XP VMs. Setup fails with "the disk may be damaged".

The image was created with

qemu-img create xp_new.img 13G

And the setup command is

kvm -cdrom xp/xp_pro.iso -hda xp_new.img -boot d -m 512 -no-acpi -usb
-usbdevice tablet


I had trouble getting winxp installed within kvm too.  Stopped with all 
sorts of funny errors depending on how I started it (with/without acpi, 
...).  Don't remember the exact errors, but one disk-related was among them.


Happended only on my AMD box though, on the Intel machine it worked 
fine.  Both ran a quite simliar setup (Fedora 11).  Which made me 
suspect hardware problems.  Tried to upgrade the BIOS -> works fine now.


HTH,
  Gerd

--
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

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

[Avi Kivity]

On 10/29/2009 10:34 AM, Chris Lalancette wrote:


I'm starting to take a look at this.  While this may be a generically useful
cleanup, it occurs to me that even if we call "set_irq" from the hrtimer
callback, we still have to do the "kick_vcpus" type thing.  Otherwise, we still
have the problem where if all vcpus are idle, none of them will be doing
vcpu_run anytime soon to actually inject the interrupt into the guest.

Or did I mis-understand what you are proposing?
   


The pic and ioapic code will kick vcpus that they deliver interrupts to, 
that's the natural order of things.  It was the kick from the timer 
(which is only connected indirectly to vcpus via the pic/ioapic) which 
is hacky and special.


As a bonus, if the interrupt is masked, no vcpus will be kicked.

--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: block virtio excessive VIRTIO_PCI_ISR reads

[Avi Kivity]

On 10/28/2009 05:04 PM, Saul Tamari wrote:

yep!

What do I have to do to turn on MSI-x?
Make this PCI capability in QEMU's virtio??

   


Pick up a new qemu-kvm from git.

--
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2873263 ] Segfaults after resize window in monitor virtual console

[SourceForge.net]

Bugs item #2873263, was opened at 2009-10-06 10:30
Message generated for change (Comment added) made by kolobrod
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2873263&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey _ (kolobrod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfaults after resize window in monitor virtual console

Initial Comment:
2.6.30-gentoo-r5 #3 SMP Mon Oct 5 15:31:57 YEKST 2009 x86_64 Intel(R) Core(TM)2 
CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux

app-emulation/kvm-88-r1  USE="alsa esd gnutls ncurses sdl vde -bluetooth 
-havekernel -modules -pulseaudio"

kvm -drive file=/home/sergey/virtual/test.img,if=virtio,media=disk,boot=on -net 
nic,model=virtio -boot c -m 384 -vga std &

Window resize causes segmentation fault while in monitor or serial virtual 
console (Ctrl+Alt+1, Ctrl+Alt+2). This problem appears even before any OS is 
booted.
It seems that after resizing window in target system display virtual console 
other consoles begin to resize normally.
-no-kvm-irqchip or -no-kvm-pit or -no-kvm does not help.

--

>Comment By: Sergey _ (kolobrod)
Date: 2009-10-29 15:10

Message:
I've managet to run it with gdb:

# gdb --args kvm
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
(gdb) run
Starting program: /usr/bin/kvm 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fd10b8e0720 (LWP 32145)]
[New Thread 0x7fd10690d950 (LWP 32148)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd10b8e0720 (LWP 32145)]
console_refresh (s=0x223c820) at console.c:254
254 console.c: No such file or directory.
in console.c
(gdb) bt
#0  console_refresh (s=0x223c820) at console.c:254
#1  0x004aa2d6 in sdl_refresh (ds=0x21f6fb0) at sdl.c:723
#2  0x0040bf47 in gui_update (opaque=) at
/var/tmp/portage/app-emulation/kvm-88-r1/work/qemu-kvm-devel-88/console.h:217
#3  0x0040bb61 in main_loop_wait (timeout=)
at
/var/tmp/portage/app-emulation/kvm-88-r1/work/qemu-kvm-devel-88/vl.c:1259
#4  0x0051eb3b in kvm_main_loop () at
/var/tmp/portage/app-emulation/kvm-88-r1/work/qemu-kvm-devel-88/qemu-kvm.c:2194
#5  0x0041013a in main (argc=1, argv=0x7fffeed54de8, envp=) at
/var/tmp/portage/app-emulation/kvm-88-r1/work/qemu-kvm-devel-88/vl.c:4550
(gdb) 


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2873263&group_id=180599
--
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

Re: [patch 1/3] KVM: x86: disallow multiple KVM_CREATE_IRQCHIP

[Michael S. Tsirkin]

On Wed, Oct 28, 2009 at 06:42:38PM -0200, Marcelo Tosatti wrote:
> Otherwise kvm will leak memory on multiple KVM_CREATE_IRQCHIP. 
> Also serialize multiple accesses with kvm->lock.
> 
> Signed-off-by: Marcelo Tosatti 
> 
> Index: kvm/arch/x86/kvm/x86.c
> ===
> --- kvm.orig/arch/x86/kvm/x86.c
> +++ kvm/arch/x86/kvm/x86.c
> @@ -2362,25 +2362,38 @@ long kvm_arch_vm_ioctl(struct file *filp
>   if (r)
>   goto out;
>   break;
> - case KVM_CREATE_IRQCHIP:
> + case KVM_CREATE_IRQCHIP: {
> + struct kvm_pic *vpic;
> +
> + mutex_lock(&kvm->lock);
> + r = -EEXIST;
> + if (kvm->arch.vpic)
> + goto create_irqchip_unlock;
>   r = -ENOMEM;
> - kvm->arch.vpic = kvm_create_pic(kvm);
> - if (kvm->arch.vpic) {
> + vpic = kvm_create_pic(kvm);
> + if (vpic) {
>   r = kvm_ioapic_init(kvm);
>   if (r) {
> - kfree(kvm->arch.vpic);
> - kvm->arch.vpic = NULL;
> - goto out;
> + kfree(vpic);
> + goto create_irqchip_unlock;
>   }
>   } else
> - goto out;
> + goto create_irqchip_unlock;
> + kvm->arch.vpic = vpic;
> + smp_wmb();

Hmm, I think we want the reverse order:
smp_wmb();
kvm->arch.vpic = vpic;

The point is preventing vpic pointer
from being written to memory before vpic data itself.
Right?

BTW, the reason that we have wmb here but no read barrier anywhere is
that this code is x86 specific and reads are not reordered across a
dependency on x86. Writes are also not reordered on x86, so this really
acts as a compiler barrier, but I agree it's better to be portable.  So
maybe, for documentation purposes, we should add read_barrier_depends
within irqchip_in_kernel()?

>   r = kvm_setup_default_irq_routing(kvm);
>   if (r) {
> + mutex_lock(&kvm->irq_lock);
>   kfree(kvm->arch.vpic);
>   kfree(kvm->arch.vioapic);
> - goto out;
> + kvm->arch.vpic = NULL;
> + kvm->arch.vioapic = NULL;
> + mutex_unlock(&kvm->irq_lock);
>   }
> + create_irqchip_unlock:
> + mutex_unlock(&kvm->lock);
>   break;
> + }
>   case KVM_CREATE_PIT:
>   u.pit_config.flags = KVM_PIT_SPEAKER_DUMMY;
>   goto create_pit;
> 
--
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

Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

Hi Dustin,

On Wed, 2009-10-28 at 14:22 -0500, Dustin Kirkland wrote:
> I believe that we have identified a regression in qemu-kvm-0.11.0.

Regression versus which previous version of qemu-kvm?

> The kvm process crashes for older guests with virtio networking, when
> the guest's incoming network connection is saturated.  The subject
> guest is Ubuntu 8.04 Hardy, 2.6.24 kernel with virtio backports.

It'd be good to see your virtio_net code

e.g. it should not have the VIRTIO_NET_F_GUEST_TSO4 feature set if it
doesn't have the "big_packets" code in try_fill_recv()

> For your convenience, I have uploaded a stock, ~260MB Ubuntu 8.04 disk
> image (user/pw = ubuntu) that I'm using to reproduce the problem at:
>  * http://rookery.canonical.com/~kirkland/hardy.img.bz2
> 
> The command line is:
>  * sudo /usr/bin/kvm -m 512 -net nic,model=virtio -net
> tap,script=/home/kirkland/bin/bridge.sh -drive
> file=hardy.img,if=virtio,index=0,boot=on
> 
> The bridge script is:
>  * http://rookery.canonical.com/~kirkland/bridge.sh
> 
> I'm saturating the guest's incoming network connection, with:
>   u...@guest$ nc -lp 1234 > /dev/null
> and
>   u...@host$ cat /dev/urandom | nc -w 3 guest_ip 1234
> 
> In less than a second of sending, the vm crashes with:
>   virtio-net truncating packet

Assuming this is something like the virtio-net in 2.6.26, there was no
receivable buffers support so (as Scott points out) it must be that
we've read a packet from the tap device which is >1514 bytes (or >1524
bytes with IFF_VNET_HDR) but the guest has not supplied buffers which
are large enough to take it

One thing to check is that the tap device is being initialized by
qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO
should not be enabled, because the guest cannot handle large GSO packets

Another possibility is that the MTU on the bridge in the host is too
large and that's what's causing the large packets to be sent

I agree we shouldn't exit in this scenario, but let's figure out what's
causing it to occur

Cheers,
Mark.

--
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

[PATCH] tests: The order of the fields are in reverse one isr stack.

[Gleb Natapov]

Signed-off-by: Gleb Natapov 
diff --git a/kvm/user/test/x86/apic.c b/kvm/user/test/x86/apic.c
index 4e89c77..b6718ec 100644
--- a/kvm/user/test/x86/apic.c
+++ b/kvm/user/test/x86/apic.c
@@ -19,11 +19,11 @@ typedef struct {
 } idt_entry_t;
 
 typedef struct {
-ulong rflags;
-ulong cs;
-ulong rip;
-ulong func;
 ulong regs[sizeof(ulong)*2];
+ulong func;
+ulong rip;
+ulong cs;
+ulong rflags;
 } isr_regs_t;
 
 #ifdef __x86_64__
--
Gleb.
--
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

[PATCH] tests: Move typedefs to one place.

[Gleb Natapov]

Signed-off-by: Gleb Natapov 
diff --git a/kvm/user/test/lib/libcflat.h b/kvm/user/test/lib/libcflat.h
index 1f96cb8..1da4013 100644
--- a/kvm/user/test/lib/libcflat.h
+++ b/kvm/user/test/lib/libcflat.h
@@ -22,6 +22,12 @@
 
 #include 
 
+typedef unsigned char u8;
+typedef unsigned short u16;
+typedef unsigned u32;
+typedef unsigned long ulong;
+typedef unsigned long long u64;
+
 extern void exit(int code);
 extern void panic(char *fmt, ...);
 
diff --git a/kvm/user/test/lib/x86/apic.c b/kvm/user/test/lib/x86/apic.c
index 1fc3888..7bb98ed 100644
--- a/kvm/user/test/lib/x86/apic.c
+++ b/kvm/user/test/lib/x86/apic.c
@@ -4,12 +4,6 @@
 static void *g_apic = (void *)0xfee0;
 static void *g_ioapic = (void *)0xfec0;
 
-typedef unsigned char u8;
-typedef unsigned short u16;
-typedef unsigned u32;
-typedef unsigned long ulong;
-typedef unsigned long long u64;
-
 struct apic_ops {
 u32 (*reg_read)(unsigned reg);
 void (*reg_write)(unsigned reg, u32 val);
diff --git a/kvm/user/test/x86/apic.c b/kvm/user/test/x86/apic.c
index 1edfba5..4e89c77 100644
--- a/kvm/user/test/x86/apic.c
+++ b/kvm/user/test/x86/apic.c
@@ -2,12 +2,6 @@
 #include "apic.h"
 #include "vm.h"
 
-typedef unsigned char u8;
-typedef unsigned short u16;
-typedef unsigned u32;
-typedef unsigned long ulong;
-typedef unsigned long long u64;
-
 typedef struct {
 unsigned short offset0;
 unsigned short selector;
diff --git a/kvm/user/test/x86/tsc.c b/kvm/user/test/x86/tsc.c
index 204b1fd..394a9c6 100644
--- a/kvm/user/test/x86/tsc.c
+++ b/kvm/user/test/x86/tsc.c
@@ -1,7 +1,5 @@
 #include "libcflat.h"
 
-typedef unsigned long long u64;
-
 u64 rdtsc(void)
 {
unsigned a, d;
--
Gleb.
--
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

Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation

[Gerd Hoffmann]

On 10/29/09 05:37, Christoph Hellwig wrote:


  - try to create generic scsi device/request structures that the hba
driver can access, and which contain additional private data for
scsi-disk/generic.  Information in the generic one would include
the information about the data transfer, the tag and the command
block.


Agreed.  For scsi device this did already happen as part of the 
qdev-ification work.  It certainly makes sense to do that for scsi 
requests too.  May also allow to kill some code duplication in 
scsi-disk.c and scsi-generic.c



  - try to get rid of the tag indexing stuff by just using a pointer to
the generic scsi request in the hba drivers.  That should get rid
of a lot of useless list searching.


Indeed.

cheers,
  Gerd
--
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

[PATCH] viostor driver. fix PREfast warnings.

[Vadim Rozenfeld]

repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit bf13fc498a576236cff8cbc707a4e5a1e70e22fb
Author: Vadim Rozenfeld
Date:   Thu Oct 29 10:37:41 2009 +0200

[PATCH] viostor driver. fix PREfast warnings.

Signed-off-by: Vadim Rozenfeld

diff --git a/viostor/virtio_pci.c b/viostor/virtio_pci.c
index a72b019..78a6d29 100644
--- a/viostor/virtio_pci.c
+++ b/viostor/virtio_pci.c
@@ -183,6 +183,10 @@ VirtIODeviceFindVirtualQueue(

 // activate the queue
 pa = ScsiPortGetPhysicalAddress(DeviceExtension, NULL, info->queue,&dummy);
+if(!pa.QuadPart) {
+ScsiPortWritePortUlong((PULONG)(adaptExt->device_base + 
VIRTIO_PCI_QUEUE_PFN),(ULONG)0);
+return NULL;
+}
 pageNum = (ULONG)(pa.QuadPart>>  PAGE_SHIFT);
 RhelDbgPrint(TRACE_LEVEL_FATAL, ("[%s] queue phys.address %08lx:%08lx, pfn 
%lx\n", __FUNCTION__, pa.u.HighPart, pa.u.LowPart, pageNum));
 ScsiPortWritePortUlong((PULONG)(adaptExt->device_base + 
VIRTIO_PCI_QUEUE_PFN),(ULONG)(pageNum));
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 8b91e62..c36b85b 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -247,29 +247,6 @@ VirtIoFindAdapter(
 return SP_RETURN_NOT_FOUND;
 }

-if (!ScsiPortValidateRange(DeviceExtension,
-   ConfigInfo->AdapterInterfaceType,
-   ConfigInfo->SystemIoBusNumber,
-   accessRange->RangeStart,
-   accessRange->RangeLength,
-   
(BOOLEAN)!accessRange->RangeInMemory)) {
-
-ScsiPortLogError(DeviceExtension,
- NULL,
- 0,
- 0,
- 0,
- SP_INTERNAL_ADAPTER_ERROR,
- __LINE__);
-
-RhelDbgPrint(TRACE_LEVEL_FATAL, ("Range validation failed %x for %x 
bytes\n",
-   (*ConfigInfo->AccessRanges)[0].RangeStart.LowPart,
-   (*ConfigInfo->AccessRanges)[0].RangeLength));
-
-return SP_RETURN_ERROR;
-}
-
-
 ConfigInfo->NumberOfBuses   = 1;
 ConfigInfo->MaximumNumberOfTargets  = 1;
 ConfigInfo->MaximumNumberOfLogicalUnits = 1;
@@ -707,7 +684,7 @@ VirtIoAdapterControl(
 RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("ScsiRestartAdapter\n"));
 adaptExt->pci_vq_info.vq = NULL;
 #ifdef MSI_SUPPORTED
-if(!adaptExt->dump_mode&  adaptExt->msix_vectors) {
+if(!adaptExt->dump_mode&&  adaptExt->msix_vectors) {
adaptExt->pci_vq_info.vq = 
VirtIODeviceFindVirtualQueue(DeviceExtension, 0, adaptExt->msix_vectors);
 }
 #endif

diff --git a/viostor/virtio_pci.c b/viostor/virtio_pci.c
index a72b019..78a6d29 100644
--- a/viostor/virtio_pci.c
+++ b/viostor/virtio_pci.c
@@ -183,6 +183,10 @@ VirtIODeviceFindVirtualQueue(
 
 // activate the queue
 pa = ScsiPortGetPhysicalAddress(DeviceExtension, NULL, info->queue, 
&dummy);
+if(!pa.QuadPart) {
+ScsiPortWritePortUlong((PULONG)(adaptExt->device_base + 
VIRTIO_PCI_QUEUE_PFN),(ULONG)0);
+return NULL;
+}
 pageNum = (ULONG)(pa.QuadPart >> PAGE_SHIFT);
 RhelDbgPrint(TRACE_LEVEL_FATAL, ("[%s] queue phys.address %08lx:%08lx, pfn 
%lx\n", __FUNCTION__, pa.u.HighPart, pa.u.LowPart, pageNum));
 ScsiPortWritePortUlong((PULONG)(adaptExt->device_base + 
VIRTIO_PCI_QUEUE_PFN),(ULONG)(pageNum));
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index 8b91e62..c36b85b 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -247,29 +247,6 @@ VirtIoFindAdapter(
 return SP_RETURN_NOT_FOUND;
 }
 
-if (!ScsiPortValidateRange(DeviceExtension,
-   ConfigInfo->AdapterInterfaceType,
-   ConfigInfo->SystemIoBusNumber,
-   accessRange->RangeStart,
-   accessRange->RangeLength,
-   
(BOOLEAN)!accessRange->RangeInMemory)) {
-
-ScsiPortLogError(DeviceExtension,
- NULL,
- 0,
- 0,
- 0,
- SP_INTERNAL_ADAPTER_ERROR,
- __LINE__);
-
-RhelDbgPrint(TRACE_LEVEL_FATAL, ("Range validation failed %x for %x 
bytes\n",
-   (*ConfigInfo->AccessRanges)[0].RangeStart.LowPart,
-   (*ConfigInfo->AccessRanges)[0].RangeLength));
-
-return SP_RETURN_ERROR;
-}
-
-
 ConfigInfo->NumberOfBuses   = 1;
 ConfigInfo->MaximumNumberOfTargets  = 1;
 ConfigInfo->MaximumNumberOfLogicalUnits = 1;
@@ -707,7 +684,7 @@ VirtIoAdapterControl(
 RhelDbgPrint(TRACE_LEVEL_VERBOSE, ("ScsiRestartAdapter\n"));
 ad

Re: [ANNOUNCE] kvm-kmod-2.6.31.5

[Jan Kiszka]

Dietmar Maurer wrote:
 Locally, you could
 simply comment out the double definition for now.
>>> Yes, that will work. Many thanks for the fast help!
>>>
>> Is native_read_tsc the only conflict with hardy's kernel?
> 
> yes.
> 

Then you may want to have a look at [1]. If you want to test it, apply
that commit to your tree and patch native_read_tsc to
kvm_native_read_tsc in svm.c.

Jan

[1]http://git.kernel.org/?p=virt/kvm/kvm-kmod.git;a=commitdiff;h=05614f03734680065746a3ca374ba00f71785126



signature.asc
Description: OpenPGP digital signature

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

[Chris Lalancette]

Avi Kivity wrote:
> On 10/28/2009 12:13 PM, Chris Lalancette wrote:
>>> The kick from i8254 code is pretty bad, as you mention.  I forget why it
>>> is needed at all - shouldn't kvm_set_irq() end up kicking the correct
>>>  
>> As I understand it, that's not quite how it works.  From what I can see, what
>> happens is that the i8254 is programmed as an hrtimer.  When the hrtimer
>> expires, we get a callback in kvm_timer_fn (or pit_timer_fn, in my new code).
>> That code is running in interrupt context, however, so you can't directly 
>> call
>> "set_irq" at that point.  Instead, we update the "pending" variable and defer
>> work until later on.  That "later on" is when we are doing a vcpu_run, at 
>> which
>> point we check the "pending" variable, and if set, inject the interrupt.
>>
>> The problem is that if the vcpu(s) are in idle when the hrtimer expires, and 
>> we
>> don't kick them, no vcpu will wake up, and hence none of them will ever run
>> "set_irq" to get it injected into the guest.
>>
> 
> Oh yes, I remember now.
> 
>> If you have other ideas on how we might accomplish this, I'd definitely be
>> interested in hearing them.
>>
> 
> We could schedule work to run in thread context.  Previous to the user 
> return notifier work, this would cause a reloading of a bunch of msrs 
> and would thus be quite expensive, but now switching to kernel threads 
> and back is pretty cheap.
> 
> So we could try schedule_work().  My only worry is that it uses 
> wake_up() instead of wake_up_sync(), so it could introduce delay.  I'd 
> much prefer a variant the schedules immediately.
> 
> An alternative is to make irq injection work from irq context.  It's not 
> difficult to do technically - convert mutexes to spin_lock_irqsave() - 
> I'm just worried about long irqoff times with large guests (ioapic needs 
> to iterate over all vcpus sometimes).  This is useful for other cases - 
> device assignment interrupt injection, irqfd for vhost/vbus.  So maybe 
> we should go this path, and worry about reducing irqoff times later when 
> we bump KVM_MAX_VCPUS.
> 

I'm starting to take a look at this.  While this may be a generically useful
cleanup, it occurs to me that even if we call "set_irq" from the hrtimer
callback, we still have to do the "kick_vcpus" type thing.  Otherwise, we still
have the problem where if all vcpus are idle, none of them will be doing
vcpu_run anytime soon to actually inject the interrupt into the guest.

Or did I mis-understand what you are proposing?

-- 
Chris Lalancette
--
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

Re: BUG with Win7 and user-return-notifier

[Jan Kiszka]

Avi Kivity wrote:
> On 10/29/2009 10:03 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>   
>>> On 10/28/2009 10:40 PM, Jan Kiszka wrote:
>>> 
   
> [you can get longer, more detailed traces by using
> /sys/kernel/debug/tracing/trace instead of dmesg]
>
> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
> kvm_msr: msr_read c080 = 0x500
> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
> kvm_msr: msr_write c080 = 0xd01
>
> So Windows is setting EFER.SCE and EFER.NX while in long mode -
> perfectly reasonable.  Can you rerun with the attached debug patch?
>
>
>  
 Log attached.


>>> So the last bits are:
>>>
>>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
>>> efer d01
>>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all
>>> bits
>>> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload
>>>
>>> We're not reloading efer (correctly, as guest efer == host efer), yet
>>> vmx_save_host_state() fails while loading efer.  I've looked at
>>> move_msr_up() (which is used by setup_msrs() to partition the msr space
>>> into reloaded and non-reloaded msrs), and it seems correct.
>>>
>>> Can you see any way where update_transition_efer() returns false, yet
>>> efer turns up in the first save_nmsrs entries of vmx->guest_msrs?
>>>
>>>  
>> Without understanding the code completely yet: When you push the slot
>> containing EFER around, do you also update msr_offset_efer?
>>
>>
> 
> We don't, but msr_offset_efer is only used from
> update_transition_efer(), which is only ever called from setup_msrs()
> immediately after updating msr_offset_efer.

Indeed.

> 
> Of course, it should be an argument to update_transition_efer(), I'll
> clean up this leftover.
> 

OK, will see that I can debug this later today.

Jan



signature.asc
Description: OpenPGP digital signature

RE: [ANNOUNCE] kvm-kmod-2.6.31.5

[Dietmar Maurer]

> >> Locally, you could
> >> simply comment out the double definition for now.
> >
> > Yes, that will work. Many thanks for the fast help!
> >
> 
> Is native_read_tsc the only conflict with hardy's kernel?

yes.

--
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

Re: BUG with Win7 and user-return-notifier

[Avi Kivity]

On 10/29/2009 10:03 AM, Jan Kiszka wrote:

Avi Kivity wrote:
   

On 10/28/2009 10:40 PM, Jan Kiszka wrote:
 
   

[you can get longer, more detailed traces by using
/sys/kernel/debug/tracing/trace instead of dmesg]

Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
kvm_msr: msr_read c080 = 0x500
Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
kvm_msr: msr_write c080 = 0xd01

So Windows is setting EFER.SCE and EFER.NX while in long mode -
perfectly reasonable.  Can you rerun with the attached debug patch?


 

Log attached.

   

So the last bits are:

Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
efer d01
Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits
Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload

We're not reloading efer (correctly, as guest efer == host efer), yet
vmx_save_host_state() fails while loading efer.  I've looked at
move_msr_up() (which is used by setup_msrs() to partition the msr space
into reloaded and non-reloaded msrs), and it seems correct.

Can you see any way where update_transition_efer() returns false, yet
efer turns up in the first save_nmsrs entries of vmx->guest_msrs?

 

Without understanding the code completely yet: When you push the slot
containing EFER around, do you also update msr_offset_efer?

   


We don't, but msr_offset_efer is only used from 
update_transition_efer(), which is only ever called from setup_msrs() 
immediately after updating msr_offset_efer.


Of course, it should be an argument to update_transition_efer(), I'll 
clean up this leftover.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

Re: BUG with Win7 and user-return-notifier

[Jan Kiszka]

Jan Kiszka wrote:
> Avi Kivity wrote:
>> On 10/28/2009 10:40 PM, Jan Kiszka wrote:
 [you can get longer, more detailed traces by using
 /sys/kernel/debug/tracing/trace instead of dmesg]

 Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
 kvm_msr: msr_read c080 = 0x500
 Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
 kvm_msr: msr_write c080 = 0xd01

 So Windows is setting EFER.SCE and EFER.NX while in long mode -
 perfectly reasonable.  Can you rerun with the attached debug patch?

  
>>> Log attached.
>>>
>> So the last bits are:
>>
>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
>> efer d01
>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits
>> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload
>>
>> We're not reloading efer (correctly, as guest efer == host efer), yet
>> vmx_save_host_state() fails while loading efer.  I've looked at
>> move_msr_up() (which is used by setup_msrs() to partition the msr space
>> into reloaded and non-reloaded msrs), and it seems correct.
>>
>> Can you see any way where update_transition_efer() returns false, yet
>> efer turns up in the first save_nmsrs entries of vmx->guest_msrs?
>>
> 
> Without understanding the code completely yet: When you push the slot
> containing EFER around, do you also update msr_offset_efer?

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4264e09..0b1f461 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -928,8 +928,10 @@ static void setup_msrs(struct vcpu_vmx *vmx)
}
 #endif
vmx->msr_offset_efer = index = __find_msr_index(vmx, MSR_EFER);
-   if (index >= 0 && update_transition_efer(vmx))
+   if (index >= 0 && update_transition_efer(vmx)) {
+   vmx->msr_offset_efer = save_nmsrs;
move_msr_up(vmx, index, save_nmsrs++);
+   }
 
vmx->save_nmsrs = save_nmsrs;
 

?

Untested as I don't want to crash my notebook ATM. :)

Jan



signature.asc
Description: OpenPGP digital signature

Re: BUG with Win7 and user-return-notifier

[Jan Kiszka]

Avi Kivity wrote:
> On 10/28/2009 10:40 PM, Jan Kiszka wrote:
>>
>>> [you can get longer, more detailed traces by using
>>> /sys/kernel/debug/tracing/trace instead of dmesg]
>>>
>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
>>> kvm_msr: msr_read c080 = 0x500
>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
>>> kvm_msr: msr_write c080 = 0xd01
>>>
>>> So Windows is setting EFER.SCE and EFER.NX while in long mode -
>>> perfectly reasonable.  Can you rerun with the attached debug patch?
>>>
>>>  
>> Log attached.
>>
> 
> So the last bits are:
> 
> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4
> efer d01
> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits
> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload
> 
> We're not reloading efer (correctly, as guest efer == host efer), yet
> vmx_save_host_state() fails while loading efer.  I've looked at
> move_msr_up() (which is used by setup_msrs() to partition the msr space
> into reloaded and non-reloaded msrs), and it seems correct.
> 
> Can you see any way where update_transition_efer() returns false, yet
> efer turns up in the first save_nmsrs entries of vmx->guest_msrs?
> 

Without understanding the code completely yet: When you push the slot
containing EFER around, do you also update msr_offset_efer?

Jan



signature.asc
Description: OpenPGP digital signature

[PATCH] viostor driver. some steps toward better performance on XP.

[Vadim Rozenfeld]

repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 844cc39863ca914cf47a1fe2e8cde4ea1079753b
Author: Vadim Rozenfeld
Date:   Thu Oct 29 09:34:19 2009 +0200

[PATCH] viostor driver. some steps toward better performance on XP.

Signed-off-by: Vadim Rozenfeld

diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index d363909..8b91e62 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -1131,6 +1131,9 @@ CompleteDPC(
 }
 #endif
 CompleteSRB(DeviceExtension, Srb);
+#ifndef USE_STORPORT
+--adaptExt->requests;
+#endif
 }

 #ifdef USE_STORPORT
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 456fa0e..c00600c 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -105,6 +105,8 @@ typedef struct _ADAPTER_EXTENSION {
 LIST_ENTRYcomplete_list;
 #ifdef USE_STORPORT
 STOR_DPC  completion_dpc;
+#else
+ULONG requests;
 #endif
 BOOLEAN   has_sn;
 ULONG msix_vectors;
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index ed6abf7..21d27cd 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -94,9 +94,11 @@ RhelDoReadWrite(PVOID DeviceExtension,
   &srbExt->vbr.sg[0],
   srbExt->out, srbExt->in,
   &srbExt->vbr) == 0) {
-//FIXME
 InsertTailList(&adaptExt->list_head,&srbExt->vbr.list_entry);
 adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
+if(++adaptExt->requests<  adaptExt->queue_depth) {
+   ScsiPortNotification(NextLuRequest, DeviceExtension, Srb->PathId, 
Srb->TargetId, Srb->Lun);
+}
 return TRUE;
 }
 return FALSE;

diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index d363909..8b91e62 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -1131,6 +1131,9 @@ CompleteDPC(
 }
 #endif
 CompleteSRB(DeviceExtension, Srb);
+#ifndef USE_STORPORT
+--adaptExt->requests;
+#endif
 }
 
 #ifdef USE_STORPORT
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index 456fa0e..c00600c 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -105,6 +105,8 @@ typedef struct _ADAPTER_EXTENSION {
 LIST_ENTRYcomplete_list;
 #ifdef USE_STORPORT
 STOR_DPC  completion_dpc;
+#else
+ULONG requests;
 #endif
 BOOLEAN   has_sn;
 ULONG msix_vectors;
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index ed6abf7..21d27cd 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -94,9 +94,11 @@ RhelDoReadWrite(PVOID DeviceExtension,
   &srbExt->vbr.sg[0],
   srbExt->out, srbExt->in,
   &srbExt->vbr) == 0) {
-//FIXME
 InsertTailList(&adaptExt->list_head, &srbExt->vbr.list_entry);
 adaptExt->pci_vq_info.vq->vq_ops->kick(adaptExt->pci_vq_info.vq);
+if(++adaptExt->requests < adaptExt->queue_depth) {
+   ScsiPortNotification(NextLuRequest, DeviceExtension, Srb->PathId, 
Srb->TargetId, Srb->Lun);
+}
 return TRUE;
 }
 return FALSE;

Re: BUG with Win7 and user-return-notifier

[Avi Kivity]

On 10/28/2009 10:40 PM, Jan Kiszka wrote:



[you can get longer, more detailed traces by using
/sys/kernel/debug/tracing/trace instead of dmesg]

Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996395us :
kvm_msr: msr_read c080 = 0x500
Oct 28 14:29:56 mchn012c kernel: qemu-sys-72000...1. 676996403us :
kvm_msr: msr_write c080 = 0xd01

So Windows is setting EFER.SCE and EFER.NX while in long mode -
perfectly reasonable.  Can you rerun with the attached debug patch?

 

Log attached.
   


So the last bits are:

Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset 4 
efer d01

Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all bits
Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no reload

We're not reloading efer (correctly, as guest efer == host efer), yet 
vmx_save_host_state() fails while loading efer.  I've looked at 
move_msr_up() (which is used by setup_msrs() to partition the msr space 
into reloaded and non-reloaded msrs), and it seems correct.


Can you see any way where update_transition_efer() returns false, yet 
efer turns up in the first save_nmsrs entries of vmx->guest_msrs?


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

Re: kvm-kmod broken with user-return-notifiers

[Jan Kiszka]

Zachary Amsden wrote:
> With current upstream changes, VMX operation now relies on have the
> user-notifiers infrastructure.  This makes kvm-kmod use on older kernels
> untenable.
> 
> I looked a bit at fixing the underlying problem by simulating the
> user-return callback when we context switch, but it is uglier than I
> would like.
> 
> Is anyone currently working on a fix?  This is blocking my development
> work, so if there is no action it looks like I will have to fix it myself.

You are welcome to test kvm-kmod next and also give feedback on the
approach I applied.

Jan

PS: Just like Avi and Marcelo are posting their work-in-progress to the
next branches of kvm.git and qemu-kvm.git, I will do the same with
kvm-kmod. I'm just still struggling with the sometimes terrible update
latency of korg's public git.



signature.asc
Description: OpenPGP digital signature

Re: vhost-net patches

[Shirley Ma]

Hello Michael,

I am able to get 63xxMb/s throughput with 10% less cpu utilization when
I apply deferring skb patch on top of your most recent vhost patch. The
userspace TCP_STREAM BW used to be 3xxxMb/s from upper stream git tree. 

After applying your recent vhost patch, it goes up to 53xxMb/s. Now it
can reach 63xxMb/s, pretty good news. (this test with transmission
descriptors = 1K)

netperf output with recent vhost patch:

[r...@localhost ~]# netperf -H 192.168.122.1 -c -C -l60
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.122.1
(192.168.122.1) port 0 AF_INET
Recv   SendSend  Utilization   Service
Demand
Socket Socket  Message  Elapsed  Send Recv Send
Recv
Size   SizeSize Time Throughput  localremote   local
remote
bytes  bytes   bytessecs.10^6bits/s  % S  % S  us/KB
us/KB

 87380  16384  1638460.03  5325.82   99.5883.331.532
2.564

netperf output with vhost + deferring skb allocation patch

[r...@localhost linux-2.6.32-rc5]# netperf -H 192.168.122.1 -c -C -l60
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.122.1
(192.168.122.1) port 0 AF_INET
Recv   SendSend  Utilization   Service
Demand
Socket Socket  Message  Elapsed  Send Recv Send
Recv
Size   SizeSize Time Throughput  localremote   local
remote
bytes  bytes   bytessecs.10^6bits/s  % S  % S  us/KB
us/KB

 87380  16384  1638460.02  6332.38   99.3376.161.285
1.970

Thanks
Shirley


--
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