From patchwork Thu Sep 5 14:07:52 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 11133205 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8AC83924 for ; Thu, 5 Sep 2019 14:09:23 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 96BED2145D for ; Thu, 5 Sep 2019 14:09:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96BED2145D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1i5sQN-0001CL-DS; Thu, 05 Sep 2019 14:07:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1i5sQM-0001CD-Fh for xen-devel@lists.xenproject.org; Thu, 05 Sep 2019 14:07:46 +0000 X-Inumbo-ID: 887afc18-cfe6-11e9-b299-bc764e2007e4 Received: from mx1.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 887afc18-cfe6-11e9-b299-bc764e2007e4; Thu, 05 Sep 2019 14:07:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A3073B65E; Thu, 5 Sep 2019 14:07:44 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Message-ID: <7f995809-c993-c7aa-1fed-c155912363c7@suse.com> Date: Thu, 5 Sep 2019 16:07:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Language: en-US Subject: [Xen-devel] [PATCH RFC] x86/HVM: use single (atomic) MOV for aligned emulated writes X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , =?utf-8?q?Rog?= =?utf-8?q?er_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Using memcpy() may result in multiple individual byte accesses (dependening how memcpy() is implemented and how the resulting insns, e.g. REP MOVSB, get carried out in hardware), which isn't what we want/need for carrying out guest insns as correctly as possible. Fall back to memcpy() only for misaligned accesses as well as ones not 2, 4, or 8 bytes in size. Suggested-by: Andrew Cooper Signed-off-by: Jan Beulich --- RFC: Besides wanting to hear if this is considered acceptable and sufficient (or whether it is thought that the linear_write() path also needs playing with), the question is whether we'd want to extend this to reads as well. linear_{read,write}() currently don't use hvmemul_map_linear_addr(), i.e. in both cases I'd need to also fiddle with __hvm_copy() (perhaps by making the construct below a helper function). --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1352,7 +1352,14 @@ static int hvmemul_write( if ( !mapping ) return linear_write(addr, bytes, p_data, pfec, hvmemul_ctxt); - memcpy(mapping, p_data, bytes); + /* For aligned accesses use single (and hence atomic) MOV insns. */ + switch ( bytes | ((unsigned long)mapping & (bytes - 1)) ) + { + case 2: write_u16_atomic(mapping, *(uint16_t *)p_data); break; + case 4: write_u32_atomic(mapping, *(uint32_t *)p_data); break; + case 8: write_u64_atomic(mapping, *(uint64_t *)p_data); break; + default: memcpy(mapping, p_data, bytes); break; + } hvmemul_unmap_linear_addr(mapping, addr, bytes, hvmemul_ctxt);