From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCH 22/24] KVM: x86 emulator: restart string instruction without going back to a guest. Date: Thu, 11 Mar 2010 18:58:14 +0900 Message-ID: <4B98BEB6.3030407@oss.ntt.co.jp> References: <1268143762-4000-1-git-send-email-gleb@redhat.com> <1268143762-4000-23-git-send-email-gleb@redhat.com> <4B966035.2050904@redhat.com> <20100309181157.GF9066@redhat.com> <4B97043C.2000603@oss.ntt.co.jp> <20100310090633.GS16909@redhat.com> <4B976282.7020108@oss.ntt.co.jp> <20100310091508.GT16909@redhat.com> <4B976F9F.7090804@oss.ntt.co.jp> <20100310134811.GU16909@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:40259 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755648Ab0CKJzl (ORCPT ); Thu, 11 Mar 2010 04:55:41 -0500 In-Reply-To: <20100310134811.GU16909@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov wrote: > On Wed, Mar 10, 2010 at 07:08:31PM +0900, Takuya Yoshikawa wrote: >> Gleb Natapov wrote: >>>>> Entering guest from time to time will not change semantics of the >>>>> processor (if code is not modified under processor's feet at least). >>>>> Currently we reenter guest mode after each iteration of string >>>>> instruction for all instruction but ins/outs. >>>>> >>>> E.g., is there no chance that during the repetitions, in the middle of the >>>> repetitions, page faults occur? If it can, without entering the guest, can >>>> we handle it? >>>> -- I lack some basic assumptions? >>>> >>> If page fault occurs we inject it to the guest. >>> >> Oh, I maight fail to tell what I worried about. >> Opposite, I mean, I worried about NOT reentering the guest case. >> > Are you thinking about something specific here? If we inject exceptions Yes. > when they occur and we inject interrupt when they arrive what problem do > you see? I guess this is how real CPU actually works. I doubt it > re-reads string instruction on each iteration. No problem if we detect and inject page faults like that. I just didn't so certain that when we encounter a page fault in the middle of the repetitions(about rep specific case), if we can inject it, suspend the repetition and enter the guest immediately like SDM Vol.2B says: "A repeating string operation can be suspended by an exception or interrupt. When this happens, the state of the registers is preserved to allow the string operation to be resumed upon a return from the exception or interrupt handler. ... This mechanism allows long string operations to proceed without affecting the interrupt response time of the system." Ah, I might misunderstand that if we reenter the guest every time for rep, page fault detection, not injection, can be done by the other ways easily, by EXIT reason or something. Both ways may need the same thing, sorry. Another concern I wrote was just about the dependencies between your "time to time" criteria and SDM's "without affecting the interrupt response time". This is just the problem of how we can determine the criteria appropriately. >> I know that current implementation with reentrance is OK. > Current implementation does not reenter guest on each iteration for pio > string, so currently we have both variants. I'm sorry, I was confused as if the current implementation already included some of your patches. > >> To inject a page fault without reentering the guest, we need to add >> some more hacks to the emulator IIUC. >> > No, we just need to enter guest if exception happens. I see that this in > handled incorrectly in my current patch series. I was just not certain if the following condition(from SDM Vol.2B) is satisfied "The source and destination registers point to the next string elements to be operated on, the EIP register points to the string instruction, and the ECX register has the value it held following the last successful iteration of the instruction." in the emulator's fault handling. I should have read your patch more closely. Thanks, Takuya