From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C78EA2095DB92 for ; Mon, 31 Jul 2017 11:18:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B71EFC0828CC; Mon, 31 Jul 2017 18:20:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B71EFC0828CC Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-71.phx2.redhat.com [10.3.117.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9410B6198C; Mon, 31 Jul 2017 18:20:33 +0000 (UTC) To: Brijesh Singh , Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Tom Lendacky , Jordan Justen , Jason Wang , "Michael S . Tsirkin" , Gerd Hoffmann References: <1500502151-13508-1-git-send-email-brijesh.singh@amd.com> <841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com> <4e2fc623-3656-eea7-09a8-b5c6d2f694e1@amd.com> <4071596d-32c9-e6d9-8c93-0d43d28e9b5a@redhat.com> <217545ac-962d-089f-9c9a-d2bbfca6427e@amd.com> <84c3c5db-623e-181b-c472-7fd7ae1c1670@amd.com> From: Laszlo Ersek Message-ID: <6330474b-281c-a06e-09cd-88ad31c6fca5@redhat.com> Date: Mon, 31 Jul 2017 20:20:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 31 Jul 2017 18:20:39 +0000 (UTC) Subject: Re: [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 18:18:32 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/29/17 03:37, Brijesh Singh wrote: > On 7/28/17 7:52 PM, Brijesh Singh wrote: > [snip] >> AMD APM document a procedure which must be used to perform in-place >> encryption/decryption. We must follow those steps to ensure that data is >> flush into memory using the correct C-bit. Not doing so may result in >> unpredictable results. >> >> http://support.amd.com/TechDocs/24593.pdf (Section 7.10.8) > I am wondering if UEFI provides APIs to get two linear mapping of the > same physical address. The steps says we create two mapping of same > physical address with different C-bits. I will look into UEFI docs to > see if something like this exist otherwise we have to consider two > memcpy. Since its just for CommandBuffers (which usually are smaller > hence we may be okay from performance point of view. Right, the separate static bounce buffer (4KB in size) and the two matching CopyMem()s look easier to understand and safer. Hopefully there won't be a performance issue in practice. > Also its just a > boot time thing, does not get used when guest OS is takes over. I will > investigate and see what works best without adding extra complexity in > the code :) Thanks! (Sorry about the late reply.) Laszlo