Re: current qemu-kvm doesn't work with vhost

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

On 2011-06-17 22:31, Georg Hopp wrote:
> Am 17.06.2011 09:29:41 schrieb(en) Jan Kiszka:
>> On 2011-06-17 09:10, Georg Hopp wrote:
>> > Jan Kiszka <jan.kiszka <at> web.de> writes:
>> >>
>> >> On 2011-06-10 05:08, Amos Kong wrote:
>> >>> host kernel: 2.6.39-rc2+
>> >>> qemu-kvm : 05f1737582ab6c075476bde931c5eafbc62a9349
>> >>>
>> >>> (gdb) r -monitor stdio -m 800 ~/RHEL-Server-6.0-64-virtio.qcow2
>> -snapshot
>> > -device
>> >> virtio-net-pci,netdev=he -netdev tap,vhost=on,id=he
>> >>>
>> >>
>> >> I already came across that symptom in a different context. Fixed by
>> the
>> >> patch below.
>> >>
>> >> However, the real issue is related to an upstream cleanup of the
>> >> virtio-pci build. That reveals some unneeded build dependencies in
>> >> qemu-kvm. Will post a fix.
>> >>
>> >> Jan
>> >
>> > FYI
>> >
>> > I encountered the same problem and applied the patch.
>> >
>> > Well this results in the following error while starting the guest:
>> >
>> >  qemu-system-x86_64: unable to start vhost net: 38:
>> >   falling back on userspace virtio
>> >
>> > and i have no network at all. I will disable vhost=on for now.
>>
>> Hmm, works fine for me. The vhost-net module is loaded (though I got a
>> different message when I forgot to load it)?
>>
>> Jan
>>
> 
> Generally it works for me until git revision b2146d8bd.

You mean including that commit, right?

> 
> I have compiled vhost-net directly in my kernel so a have definetly not
> forgotten to load it...
> As i use gentoo i made an ebuild that installes exactly this revision.
> If i find the time to do some debugging i will do so, but actually i am
> very busy with my job
> family and the use of kvm is just a sparetime thing. :D
> 
> If it would be of some help i can set a breakpoint just before the path
> and see what
> causes the message.

Let's start with double-checking that you are on ce5f0a588b, did a make
clean && make, and then actually used that result. I suspect an
inconsistent build as ce5f0a588b makes the difference between ENOSYS
(38) and working vhost support here.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]