[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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).

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.