Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET

[Avi Kivity <avi@redhat.com>]

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