From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Thu, 14 Jul 2011 16:05:41 +0300 Message-ID: <4E1EE9A5.8040306@redhat.com> References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com> <1310469824.2393.22.camel@sasha> <4E1C2F59.90600@redhat.com> <4E1D442E.6090308@redhat.com> <4E1D9623.70801@redhat.com> <4E1D9E75.1070901@redhat.com> <4E1E9A3B.7090200@kernel.org> <4E1EA455.4010608@redhat.com> <4E1EA8A2.9020304@redhat.com> <4E1EBB7A.3030809@redhat.com> <4E1ED913.6070003@redhat.com> <1310646737.21171.23.camel@lappy> <4E1EE519.1020608@redhat.com> <1310648409.21171.34.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , "Michael S. Tsirkin" , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21355 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754564Ab1GNNF5 (ORCPT ); Thu, 14 Jul 2011 09:05:57 -0400 In-Reply-To: <1310648409.21171.34.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 07/14/2011 04:00 PM, Sasha Levin wrote: > > > > Why? virtio is mature. It's not some early boot thing which fails and > > kills the guest. Even if you get an oops, usually the guest is still alive. > > virtio is mature, /tools/kvm isn't :) > > > > > It's not just virtio which can fail running on virtio-console, it's also > > > the threadpool, the eventfd mechanism and even the PCI management > > > module. You can't really debug it if you can't depend on your debugging > > > mechanism to properly work. > > > > Wait, those are guest things, not host things. > > Yes, as you said in the previous mail, both KVM and virtio are very > stable. /tools/kvm was the one who was being debugged most of the time. I still don't follow. The guest oopses? dmesg | less. An issue with tools/kvm? gdb -p `pgrep kvm`. > > > So far, serial is the simplest, most effective, and never-failing method > > > we had for working on guests, I don't see how we can work without it at > > > the moment. > > > > I really can't remember the last time I used the serial console for the > > guest. In the early early days, sure, but now? > > > > I don't know, if it works fine why not use it when you need simple > serial connection? > > It's also useful for kernel hackers who break early boot things :) I'm not advocating removing it! I'm just questioning the need for optimization. > > That's not what scaling means (not to say that it wouldn't be nice to > > fix coalesced mmio). > > > > btw, why are you so eager to run 1024 vcpu guests? usually, if you have > > a need for such large systems, you're really performance sensitive. > > It's not a good case for virtualization. > > > > > > I may have went too far with 1024, I have only tested it on 254 vcpus so > far - I'll change that in my patch. > > It's also not just a KVM issue. Take for example the RCU issue which we > were able to detect with /tools/kvm just by trying more than 30 vcpus > and noticing that RCU was broken with a recent kernel. > > Testing the kernel on guests with large amount of vcpus or virtual > memory might prove beneficial not only for KVM itself. Non-performance testing of really large guests is a valid use case, I agree. -- error compiling committee.c: too many arguments to function