Re: [PATCH v2 28/30] KVM: x86 emulator: restart string instruction without going back to a guest.

[Gleb Natapov <gleb@redhat.com>]

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.