From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET
Date: Thu, 14 Jul 2011 11:19:14 +0300
Message-ID: <20110714081913.GO2400@redhat.com>
References: <4E1C2F59.90600@redhat.com>
 <CAOJsxLHAo0hNcRRSdN2sZiDZc0+SLVui9VW6VCYukx7kEWKXaQ@mail.gmail.com>
 <CAOJsxLEfZcXaeNPMh=k8y9WqcH=qL-aGB1vJBb=xc_bis7Lcdw@mail.gmail.com>
 <4E1D442E.6090308@redhat.com>
 <CAOJsxLGWjd18MiU7j+RbiUFWXbeKF4-5aahQL5kXagNszrA=QQ@mail.gmail.com>
 <4E1D9623.70801@redhat.com>
 <CAOJsxLH3Qton9VfFMOdJgCdCMNDzzQf+x8aGwuDDnfeigTEF=Q@mail.gmail.com>
 <4E1D9E75.1070901@redhat.com>
 <4E1E9A3B.7090200@kernel.org>
 <4E1EA455.4010608@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Pekka Enberg <penberg@kernel.org>,
	Sasha Levin <levinsasha928@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>, kvm@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:62007 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753265Ab1GNIUD (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 14 Jul 2011 04:20:03 -0400
Content-Disposition: inline
In-Reply-To: <4E1EA455.4010608@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, Jul 14, 2011 at 11:09:57AM +0300, Avi Kivity wrote:
> On 07/14/2011 10:26 AM, Pekka Enberg wrote:
> >
> >On 7/13/11 4:32 PM, Avi Kivity wrote:
> >>Just how fast do you type?
> >>
> >>It's not enough to make something faster, it has to be slow to
> >>being with.  The interface is good, but use it where it helps.
> >
> >I don't know why you bring up serial console input here. Sasha's
> >original KVM_IOEVENTFD_FLAG_PIPE patch clearly stated:
> >
> >  A simple example for practical use is the serial port. we are not
> >  interested in an exit every time a char is written to the port, but
> >  we do need to know what was written so we could handle it on the
> >  guest.
> >
> >So it's talking about the serial console output, not input.
> >
> 
> I'm talking about the real world.  Is any of this something that
> needs optimization?
> 
> 1024 vcpus logging in via the serial console at 10Gbps.  Get real.
> 
It is nice to have the ability to trace a guest execution from a host
(added bonus if you can trace the guest and the host simultaneously and
have trace output in one nice file), but serial interface is not fit
for that. PV interface is needed. May be share ftrace buffer between
the host and the guest?

--
			Gleb.