From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35F26C43441 for ; Wed, 28 Nov 2018 03:51:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F0EC72082F for ; Wed, 28 Nov 2018 03:51:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0EC72082F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727248AbeK1Ovc (ORCPT ); Wed, 28 Nov 2018 09:51:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38992 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726847AbeK1Ovc (ORCPT ); Wed, 28 Nov 2018 09:51:32 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 644787F6A8; Wed, 28 Nov 2018 03:51:25 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-97.pek2.redhat.com [10.72.12.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26E14611A0; Wed, 28 Nov 2018 03:51:11 +0000 (UTC) Subject: Re: [PATCH 1/2 RESEND v7] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED' To: Dave Hansen , linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, x86@kernel.org, linux-ia64@vger.kernel.org, linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, akpm@linux-foundation.org, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, ard.biesheuvel@linaro.org, tony.luck@intel.com, fenghua.yu@intel.com, dyoung@redhat.com, bhe@redhat.com References: <20181124051223.19994-1-lijiang@redhat.com> <20181124051223.19994-2-lijiang@redhat.com> <460c5552-a48e-3523-275a-7f94d0f08f9b@redhat.com> <703ce20d-be09-9b8d-d457-5b002a50dff7@intel.com> From: lijiang Message-ID: Date: Wed, 28 Nov 2018 11:51:03 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <703ce20d-be09-9b8d-d457-5b002a50dff7@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 28 Nov 2018 03:51:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2018年11月27日 23:34, Dave Hansen 写道: > On 11/27/18 2:04 AM, lijiang wrote: >> What happens if we don't modify this functions >> __ioremap_check_desc_other()? -When SEV is active, it might map these >> reserved regions with the encryption mask. That is incorrect. > > This is missing another sentence or two to "connect the dots". > > SEV uses data that comes from the e820 table to tell whether or not the > memory should be encrypted? If we don't reflect these reserved areas in > the e820 table, the SEV code will set up encrypted mappings for device > memory, for instance? > For the convenience of description, here copy some code fragments and put them at the end. Please refer to these codes. When the SEV is active, the page being mapped will determine whether to use the memory encryption attribute for mapping based on the 'mem_flags.desc_other'. But the value of 'mem_flags.desc_other' is set according to the returned result of this function __ioremap_check_desc_other(). Originally, the 'E820_TYPE_RESERVED' type is converted to the descriptor 'IORES_DESC_NONE', therefore, for the e820 reserved type, the value of 'mem_flags.desc_other' is equal to 'false'. But now, the 'E820_TYPE_RESERVED' type is converted to the descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE', it has been changed and the value of 'mem_flags.desc_other' is equal to 'true'. This is wrong. So that would be nice to keep it the same as before, that is to say, this function has to be improved like this. static int __ioremap_check_desc_other(struct resource *res) { return ((res->desc != IORES_DESC_NONE) && (res->desc != IORES_DESC_RESERVED)); } Please look at the following function __ioremap_caller(), and also list the call trace path. Call trace path: __ioremap_caller()-> __ioremap_check_mem()-> walk_mem_res()-> __ioremap_res_check()-> __ioremap_check_desc_other() static void __iomem *__ioremap_caller(resource_size_t phys_addr, unsigned long size, enum page_cache_mode pcm, void *caller, bool encrypted) { unsigned long offset, vaddr; resource_size_t last_addr; const resource_size_t unaligned_phys_addr = phys_addr; const unsigned long unaligned_size = size; struct ioremap_mem_flags mem_flags; /* skip some codes...*/ __ioremap_check_mem(phys_addr, size, &mem_flags); /* skip some codes...*/ /* * If the page being mapped is in memory and SEV is active then * make sure the memory encryption attribute is enabled in the * resulting mapping. */ prot = PAGE_KERNEL_IO; if ((sev_active() && mem_flags.desc_other) || encrypted) prot = pgprot_encrypted(prot); /* skip some codes...*/ } Thanks. Lianbo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gRqsz-0004HZ-3X for kexec@lists.infradead.org; Wed, 28 Nov 2018 03:51:38 +0000 Subject: Re: [PATCH 1/2 RESEND v7] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED' References: <20181124051223.19994-1-lijiang@redhat.com> <20181124051223.19994-2-lijiang@redhat.com> <460c5552-a48e-3523-275a-7f94d0f08f9b@redhat.com> <703ce20d-be09-9b8d-d457-5b002a50dff7@intel.com> From: lijiang Message-ID: Date: Wed, 28 Nov 2018 11:51:03 +0800 MIME-Version: 1.0 In-Reply-To: <703ce20d-be09-9b8d-d457-5b002a50dff7@intel.com> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Dave Hansen , linux-kernel@vger.kernel.org Cc: fenghua.yu@intel.com, linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org, bhe@redhat.com, ard.biesheuvel@linaro.org, peterz@infradead.org, x86@kernel.org, kexec@lists.infradead.org, tony.luck@intel.com, dave.hansen@linux.intel.com, mingo@redhat.com, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, dyoung@redhat.com, akpm@linux-foundation.org 5ZyoIDIwMTjlubQxMeaciDI35pelIDIzOjM0LCBEYXZlIEhhbnNlbiDlhpnpgZM6Cj4gT24gMTEv MjcvMTggMjowNCBBTSwgbGlqaWFuZyB3cm90ZToKPj4gV2hhdCBoYXBwZW5zIGlmIHdlIGRvbid0 IG1vZGlmeSB0aGlzIGZ1bmN0aW9ucwo+PiBfX2lvcmVtYXBfY2hlY2tfZGVzY19vdGhlcigpPyAt V2hlbiBTRVYgaXMgYWN0aXZlLCBpdCBtaWdodCBtYXAgdGhlc2UKPj4gcmVzZXJ2ZWQgcmVnaW9u cyB3aXRoIHRoZSBlbmNyeXB0aW9uIG1hc2suIFRoYXQgaXMgaW5jb3JyZWN0LiAKPiAKPiBUaGlz IGlzIG1pc3NpbmcgYW5vdGhlciBzZW50ZW5jZSBvciB0d28gdG8gImNvbm5lY3QgdGhlIGRvdHMi Lgo+IAo+IFNFViB1c2VzIGRhdGEgdGhhdCBjb21lcyBmcm9tIHRoZSBlODIwIHRhYmxlIHRvIHRl bGwgd2hldGhlciBvciBub3QgdGhlCj4gbWVtb3J5IHNob3VsZCBiZSBlbmNyeXB0ZWQ/ICBJZiB3 ZSBkb24ndCByZWZsZWN0IHRoZXNlIHJlc2VydmVkIGFyZWFzIGluCj4gdGhlIGU4MjAgdGFibGUs IHRoZSBTRVYgY29kZSB3aWxsIHNldCB1cCBlbmNyeXB0ZWQgbWFwcGluZ3MgZm9yIGRldmljZQo+ IG1lbW9yeSwgZm9yIGluc3RhbmNlPwo+IAoKRm9yIHRoZSBjb252ZW5pZW5jZSBvZiBkZXNjcmlw dGlvbiwgaGVyZSBjb3B5IHNvbWUgY29kZSBmcmFnbWVudHMgYW5kIHB1dCB0aGVtIGF0IHRoZSBl bmQuClBsZWFzZSByZWZlciB0byB0aGVzZSBjb2Rlcy4KCldoZW4gdGhlIFNFViBpcyBhY3RpdmUs IHRoZSBwYWdlIGJlaW5nIG1hcHBlZCB3aWxsIGRldGVybWluZSB3aGV0aGVyIHRvIHVzZSB0aGUg bWVtb3J5CmVuY3J5cHRpb24gYXR0cmlidXRlIGZvciBtYXBwaW5nIGJhc2VkIG9uIHRoZSAnbWVt X2ZsYWdzLmRlc2Nfb3RoZXInLgoKQnV0IHRoZSB2YWx1ZSBvZiAnbWVtX2ZsYWdzLmRlc2Nfb3Ro ZXInIGlzIHNldCBhY2NvcmRpbmcgdG8gdGhlIHJldHVybmVkIHJlc3VsdCBvZiB0aGlzCmZ1bmN0 aW9uIF9faW9yZW1hcF9jaGVja19kZXNjX290aGVyKCkuCgpPcmlnaW5hbGx5LCB0aGUgJ0U4MjBf VFlQRV9SRVNFUlZFRCcgdHlwZSBpcyBjb252ZXJ0ZWQgdG8gdGhlIGRlc2NyaXB0b3IgJ0lPUkVT X0RFU0NfTk9ORScsCnRoZXJlZm9yZSwgZm9yIHRoZSBlODIwIHJlc2VydmVkIHR5cGUsIHRoZSB2 YWx1ZSBvZiAnbWVtX2ZsYWdzLmRlc2Nfb3RoZXInIGlzIGVxdWFsIHRvCidmYWxzZScuCgpCdXQg bm93LCB0aGUgJ0U4MjBfVFlQRV9SRVNFUlZFRCcgdHlwZSBpcyBjb252ZXJ0ZWQgdG8gdGhlIGRl c2NyaXB0b3IgJ0lPUkVTX0RFU0NfUkVTRVJWRUQnCmluc3RlYWQgb2YgJ0lPUkVTX0RFU0NfTk9O RScsIGl0IGhhcyBiZWVuIGNoYW5nZWQgYW5kIHRoZSB2YWx1ZSBvZiAnbWVtX2ZsYWdzLmRlc2Nf b3RoZXInCmlzIGVxdWFsIHRvICd0cnVlJy4gVGhpcyBpcyB3cm9uZy4KClNvIHRoYXQgd291bGQg YmUgbmljZSB0byBrZWVwIGl0IHRoZSBzYW1lIGFzIGJlZm9yZSwgdGhhdCBpcyB0byBzYXksIHRo aXMgZnVuY3Rpb24gaGFzIHRvCmJlIGltcHJvdmVkIGxpa2UgdGhpcy4Kc3RhdGljIGludCBfX2lv cmVtYXBfY2hlY2tfZGVzY19vdGhlcihzdHJ1Y3QgcmVzb3VyY2UgKnJlcykKewogICAgcmV0dXJu ICgocmVzLT5kZXNjICE9IElPUkVTX0RFU0NfTk9ORSkgJiYKICAgICAgICAgICAgKHJlcy0+ZGVz YyAhPSBJT1JFU19ERVNDX1JFU0VSVkVEKSk7Cn0KCgpQbGVhc2UgbG9vayBhdCB0aGUgZm9sbG93 aW5nIGZ1bmN0aW9uIF9faW9yZW1hcF9jYWxsZXIoKSwgYW5kIGFsc28gbGlzdCB0aGUgY2FsbCB0 cmFjZSBwYXRoLgoKQ2FsbCB0cmFjZSBwYXRoOgogICBfX2lvcmVtYXBfY2FsbGVyKCktPgpfX2lv cmVtYXBfY2hlY2tfbWVtKCktPgogICAgICAgd2Fsa19tZW1fcmVzKCktPgpfX2lvcmVtYXBfcmVz X2NoZWNrKCktPiAKX19pb3JlbWFwX2NoZWNrX2Rlc2Nfb3RoZXIoKQoKc3RhdGljIHZvaWQgX19p b21lbSAqX19pb3JlbWFwX2NhbGxlcihyZXNvdXJjZV9zaXplX3QgcGh5c19hZGRyLAogICAgICAg ICAgICAgICAgdW5zaWduZWQgbG9uZyBzaXplLCBlbnVtIHBhZ2VfY2FjaGVfbW9kZSBwY20sCiAg ICAgICAgICAgICAgICB2b2lkICpjYWxsZXIsIGJvb2wgZW5jcnlwdGVkKQp7CiAgICAgICAgdW5z aWduZWQgbG9uZyBvZmZzZXQsIHZhZGRyOwogICAgICAgIHJlc291cmNlX3NpemVfdCBsYXN0X2Fk ZHI7CiAgICAgICAgY29uc3QgcmVzb3VyY2Vfc2l6ZV90IHVuYWxpZ25lZF9waHlzX2FkZHIgPSBw aHlzX2FkZHI7CiAgICAgICAgY29uc3QgdW5zaWduZWQgbG9uZyB1bmFsaWduZWRfc2l6ZSA9IHNp emU7CiAgICAgICAgc3RydWN0IGlvcmVtYXBfbWVtX2ZsYWdzIG1lbV9mbGFnczsKCgkvKiBza2lw IHNvbWUgY29kZXMuLi4qLwoKICAgICAgICBfX2lvcmVtYXBfY2hlY2tfbWVtKHBoeXNfYWRkciwg c2l6ZSwgJm1lbV9mbGFncyk7CgoJLyogc2tpcCBzb21lIGNvZGVzLi4uKi8KCgkvKgogICAgICAg ICAqIElmIHRoZSBwYWdlIGJlaW5nIG1hcHBlZCBpcyBpbiBtZW1vcnkgYW5kIFNFViBpcyBhY3Rp dmUgdGhlbgogICAgICAgICAqIG1ha2Ugc3VyZSB0aGUgbWVtb3J5IGVuY3J5cHRpb24gYXR0cmli dXRlIGlzIGVuYWJsZWQgaW4gdGhlCiAgICAgICAgICogcmVzdWx0aW5nIG1hcHBpbmcuCiAgICAg ICAgICovCiAgICAgICAgcHJvdCA9IFBBR0VfS0VSTkVMX0lPOwogICAgICAgIGlmICgoc2V2X2Fj dGl2ZSgpICYmIG1lbV9mbGFncy5kZXNjX290aGVyKSB8fCBlbmNyeXB0ZWQpCiAgICAgICAgICAg ICAgICBwcm90ID0gcGdwcm90X2VuY3J5cHRlZChwcm90KTsKCgkvKiBza2lwIHNvbWUgY29kZXMu Li4qLwp9CgpUaGFua3MuCkxpYW5ibwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18Ka2V4ZWMgbWFpbGluZyBsaXN0CmtleGVjQGxpc3RzLmluZnJhZGVhZC5v cmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9rZXhlYwo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: lijiang Date: Wed, 28 Nov 2018 03:51:03 +0000 Subject: Re: [PATCH 1/2 RESEND v7] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED' Message-Id: List-Id: References: <20181124051223.19994-1-lijiang@redhat.com> <20181124051223.19994-2-lijiang@redhat.com> <460c5552-a48e-3523-275a-7f94d0f08f9b@redhat.com> <703ce20d-be09-9b8d-d457-5b002a50dff7@intel.com> In-Reply-To: <703ce20d-be09-9b8d-d457-5b002a50dff7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Dave Hansen , linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, x86@kernel.org, linux-ia64@vger.kernel.org, linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, akpm@linux-foundation.org, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, ard.biesheuvel@linaro.org, tony.luck@intel.com, fenghua.yu@intel.com, dyoung@redhat.com, bhe@redhat.com 在 2018年11月27日 23:34, Dave Hansen 写道: > On 11/27/18 2:04 AM, lijiang wrote: >> What happens if we don't modify this functions >> __ioremap_check_desc_other()? -When SEV is active, it might map these >> reserved regions with the encryption mask. That is incorrect. > > This is missing another sentence or two to "connect the dots". > > SEV uses data that comes from the e820 table to tell whether or not the > memory should be encrypted? If we don't reflect these reserved areas in > the e820 table, the SEV code will set up encrypted mappings for device > memory, for instance? > For the convenience of description, here copy some code fragments and put them at the end. Please refer to these codes. When the SEV is active, the page being mapped will determine whether to use the memory encryption attribute for mapping based on the 'mem_flags.desc_other'. But the value of 'mem_flags.desc_other' is set according to the returned result of this function __ioremap_check_desc_other(). Originally, the 'E820_TYPE_RESERVED' type is converted to the descriptor 'IORES_DESC_NONE', therefore, for the e820 reserved type, the value of 'mem_flags.desc_other' is equal to 'false'. But now, the 'E820_TYPE_RESERVED' type is converted to the descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE', it has been changed and the value of 'mem_flags.desc_other' is equal to 'true'. This is wrong. So that would be nice to keep it the same as before, that is to say, this function has to be improved like this. static int __ioremap_check_desc_other(struct resource *res) { return ((res->desc != IORES_DESC_NONE) && (res->desc != IORES_DESC_RESERVED)); } Please look at the following function __ioremap_caller(), and also list the call trace path. Call trace path: __ioremap_caller()-> __ioremap_check_mem()-> walk_mem_res()-> __ioremap_res_check()-> __ioremap_check_desc_other() static void __iomem *__ioremap_caller(resource_size_t phys_addr, unsigned long size, enum page_cache_mode pcm, void *caller, bool encrypted) { unsigned long offset, vaddr; resource_size_t last_addr; const resource_size_t unaligned_phys_addr = phys_addr; const unsigned long unaligned_size = size; struct ioremap_mem_flags mem_flags; /* skip some codes...*/ __ioremap_check_mem(phys_addr, size, &mem_flags); /* skip some codes...*/ /* * If the page being mapped is in memory and SEV is active then * make sure the memory encryption attribute is enabled in the * resulting mapping. */ prot = PAGE_KERNEL_IO; if ((sev_active() && mem_flags.desc_other) || encrypted) prot = pgprot_encrypted(prot); /* skip some codes...*/ } Thanks. Lianbo