Re: [Xen-devel] [PATCH 1/3] x86: also allow REP STOS emulation acceleration

[Tim Deegan <tim@xxxxxxx>]

At 17:05 +0000 on 08 Jan (1420733142), Jan Beulich wrote:
> >>> On 08.01.15 at 17:56, <tim@xxxxxxx> wrote:
> > At 16:29 +0000 on 08 Jan (1420730974), Jan Beulich wrote:
> >> >>> On 08.01.15 at 17:16, <tim@xxxxxxx> wrote:
> >> > At 15:50 +0000 on 08 Jan (1420728649), Jan Beulich wrote:
> >> >> While the REP MOVS acceleration appears to have helped qemu-traditional
> >> >> based guests, qemu-upstream (or really the respective video BIOSes)
> >> >> doesn't appear to benefit from that. Instead the acceleration added
> >> >> here provides a visible performance improvement during very early HVM
> >> >> guest boot.
> >> >> 
> >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> > 
> >> > If I read this right, it's allocating and memset()ing a buffer and
> >> > then copying that buffer to the guest?
> >> 
> >> In the non-MMIO case yes.
> >> 
> >> > Would it be better to map the guest frame and write directly?  Edge
> >> > cases where the STOS crosses a frame boundary could happen the old way.
> >> 
> >> This matches the REP MOVS handling, which also allocates a
> >> temporary buffer. I.e. if you wanted this for REP STOS, we should
> >> first make it so for REP MOVS.
> > 
> > Well, REP MOVS is trickier as it would have to handle page crossings
> > in both source and destination.
> 
> But I don't think would could blindly map for all sorts of p2mt we
> get back - we'd have to special case RAM, and deal with the
> other cases the current way anyway (even if for nothing else
> than getting a correct error indicator).

Fair enough - we might as well just have all that once in the hvm_copy
code.

Reviewed-by: Tim Deegan <tim@xxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel