From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Tue, 19 Jul 2011 21:49:28 -0500 Message-ID: <4E264238.2000803@codemonkey.ws> References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com> <1309927078-5983-5-git-send-email-levinsasha928@gmail.com> <20110706114203.GA18368@redhat.com> <1309964506.15123.13.camel@sasha> <20110706155135.GA21638@redhat.com> <1310276083.2393.6.camel@sasha> <20110710080559.GC1630@redhat.com> <1310469824.2393.22.camel@sasha> <4E1C2F59.90600@redhat.com> <4E1D442E.6090308@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , Sasha Levin , "Michael S. Tsirkin" , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti To: Avi Kivity Return-path: Received: from mail-gx0-f174.google.com ([209.85.161.174]:34478 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752456Ab1GTCtb (ORCPT ); Tue, 19 Jul 2011 22:49:31 -0400 Received: by gxk21 with SMTP id 21so2067162gxk.19 for ; Tue, 19 Jul 2011 19:49:30 -0700 (PDT) In-Reply-To: <4E1D442E.6090308@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/13/2011 02:07 AM, Avi Kivity wrote: > On 07/13/2011 09:45 AM, Pekka Enberg wrote: >> > >> > OK, what's the simplest thing we can do here to keep Avi happy and get >> > the functionality of Sasha's original patch that helps us avoid guest >> > exits for serial console? I agree with Avi that we don't want >> > fragmented ABI but it seems to me there's no clear idea how to fix >> > KVM_IOEVENTFD_FLAG_SOCKET corner cases, right? >> >> And btw, I didn't follow the discussion closely, but introducing a new >> type of exit for a feature that's designed to _avoid exits_ doesn't >> seem like a smart thing to do. Is it even possible to support sockets >> sanely for this? > > First of all, this feature doesn't avoid exits. I don't think it's possible to do correct UART emulation and avoid an exit. And yeah, looking at your serial emulation, you're not properly updating the LSR register. The fact that this works with Linux is just luck. You will encounter guests that poll LSR.THRE in order to write more data to the THR and you will no longer be able to treat THR as having no side effects. Worse yet, if the Linux driver ever changes in the future in a way that's fully compliant to the UART spec, it'll break your emulation. If you're not going to emulate a UART properly, why not just use a paravirtual serial device that you can keep simple? Regards, Anthony Liguori