All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, mtosatti@redhat.com
Subject: Re: [PATCHv4 3/5] KVM: emulator: move some address manipulation function out of emulator code.
Date: Thu, 19 Jul 2012 16:43:39 +0300	[thread overview]
Message-ID: <20120719134339.GD26120@redhat.com> (raw)
In-Reply-To: <50080CFA.4040607@redhat.com>

On Thu, Jul 19, 2012 at 04:34:50PM +0300, Avi Kivity wrote:
> On 07/19/2012 01:49 PM, Gleb Natapov wrote:
> >> All those exports suggest it's better to move the fast path into the
> >> emulator. 
> > 
> > We've already being through that. Putting the code into emulator gives
> > us nothing unless it also works on emulator context and working on
> > partially initialized emulator context is first dangerous and second
> > slower.
> 
> We can make it work on an x86_pio_ctxt.  What it gives us is common
> code. (x86_emulate_ctxt can include a x86_pio_ctxt when it does pio).
> 
My patches do similar thing, but instead of x86_pio_ctxt they use
x86_linearize_ctx. The code is common.

> > 
> >>  Suppose we change register access to use callbacks instead of
> >> bulk load/save, could we reuse the exising code?
> >> 
> > I do not see that problem. This helper function do basic arithmetics
> > on three values. The value itself will be fetched on demand by the emulator.
> 
> I meant to reduce the emulator initialization cost, so it isn't slow.
> 
> btw, I'm guessing that the main speedup comes not from avoiding the
> decode, but by doing page-at-a-time instead of word-at-a-time.
> 
And hacking emulator doing page at a time is not trivial an complicates
it for no good reason. BTW you were the one who suggested implementing
fast pio as a separate code path.

--
			Gleb.

  reply	other threads:[~2012-07-19 13:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19  7:40 [PATCHv4 0/5] improve speed of "rep ins" emulation Gleb Natapov
2012-07-19  7:40 ` [PATCHv4 1/5] Provide userspace IO exit completion callback Gleb Natapov
2012-07-19  7:40 ` [PATCHv4 2/5] KVM: emulator: make x86 emulation modes enum instead of defines Gleb Natapov
2012-07-19  7:40 ` [PATCHv4 3/5] KVM: emulator: move some address manipulation function out of emulator code Gleb Natapov
2012-07-19 10:42   ` Avi Kivity
2012-07-19 10:49     ` Gleb Natapov
2012-07-19 13:34       ` Avi Kivity
2012-07-19 13:43         ` Gleb Natapov [this message]
2012-07-19  7:40 ` [PATCHv4 4/5] KVM: emulator: make linearize() callable from outside of emulator Gleb Natapov
2012-07-19 10:32   ` Avi Kivity
2012-07-19 10:51     ` Gleb Natapov
2012-07-19 12:52       ` Avi Kivity
2012-07-19 12:54         ` Gleb Natapov
2012-07-19  7:40 ` [PATCHv4 5/5] KVM: Provide fast path for "rep ins" emulation if possible Gleb Natapov
2012-07-19 10:37   ` Avi Kivity
2012-07-19 11:09     ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120719134339.GD26120@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.