From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH v2 28/30] KVM: x86 emulator: restart string instruction without going back to a guest. Date: Mon, 15 Mar 2010 12:33:10 +0200 Message-ID: <20100315103310.GJ4294@redhat.com> References: <1268583675-3101-29-git-send-email-gleb@redhat.com> <4B9D1545.2020902@redhat.com> <20100314180625.GB5406@redhat.com> <4B9DE55A.5070003@redhat.com> <20100315094447.GG4294@redhat.com> <4B9E0450.4090403@redhat.com> <20100315100756.GH4294@redhat.com> <4B9E08BA.7090303@redhat.com> <20100315101956.GI4294@redhat.com> <4B9E0AEB.3020602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57011 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756367Ab0COKdM (ORCPT ); Mon, 15 Mar 2010 06:33:12 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2FAXCZl002272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Mar 2010 06:33:12 -0400 Content-Disposition: inline In-Reply-To: <4B9E0AEB.3020602@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Mar 15, 2010 at 12:24:43PM +0200, Avi Kivity wrote: > On 03/15/2010 12:19 PM, Gleb Natapov wrote: > >On Mon, Mar 15, 2010 at 12:15:22PM +0200, Avi Kivity wrote: > >>On 03/15/2010 12:07 PM, Gleb Natapov wrote: > >>>>Or we can make the buffer larger for everyone (outside this patchset > >>>>though). > >>>> > >>>I am not sure what do you mean here. INS read ahead and MMIO read cache are > >>>different beasts. Former is needed to speed-up string pio reads, later > >>>(not yet implemented) is needed to reread previous MMIO read results in > >>>case instruction emulation is restarted due to need to exit to userspace. > >>>MMIO read cache need to be invalidated on each iteration of string > >>>instruction. > >>Instructions with multiple reads or writes need an mmio read/write > >>buffer that can be replayed on re-execution. > >> > >>buffer != cache! A cache can be dropped (perhaps after flushing it > >>to a backing store), but a buffer in general cannot. > >> > >That is just naming. Call it "buffer" if you want. > > > >I still don't understand what do you mean by "Or we can make the buffer > >larger for everyone". Who is this "everyone"? Different instruction need > >different kind of buffers. > > Many instructions can issue multiple reads, ins is just one of them. > A generic mmio buffer can be used by everyone. > No, ins can issue only _one_ io read during one iteration (i.e between each pair of reads there is a commit point). But this is slow, so we do non-architectural hack: do many reads ahead of time into a buffer and use results from this buffer for emulation of subsequent iterations. Other instruction can do multiple reads between instruction fetching and commit of emulation result and need different kind of buffering (actually caching is more appropriate here since we "cache" results of reads from past attempts to emulation same instruction). -- Gleb.