[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMzpN2gq0TZbgy-3PUixwvL+6ECX5bOdE0XZsLtGFXA+-Embeg@mail.gmail.com>
Date: Tue, 11 Jul 2017 00:58:23 -0400
From: Brian Gerst <brgerst@...il.com>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: linux-arch <linux-arch@...r.kernel.org>, linux-efi@...r.kernel.org,
kvm@...r.kernel.org, linux-doc@...r.kernel.org,
"the arch/x86 maintainers" <x86@...nel.org>,
kexec@...ts.infradead.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
kasan-dev@...glegroups.com, xen-devel@...ts.xen.org,
Linux-MM <linux-mm@...ck.org>, iommu@...ts.linux-foundation.org,
Brijesh Singh <brijesh.singh@....com>,
Toshimitsu Kani <toshi.kani@....com>,
Radim Krčmář <rkrcmar@...hat.com>,
Matt Fleming <matt@...eblueprint.co.uk>,
Alexander Potapenko <glider@...gle.com>,
"H. Peter Anvin" <hpa@...or.com>,
Larry Woodman <lwoodman@...hat.com>,
Jonathan Corbet <corbet@....net>,
Joerg Roedel <joro@...tes.org>,
"Michael S. Tsirkin" <mst@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Dave Young <dyoung@...hat.com>, Rik van Riel <riel@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Juergen Gross <jgross@...e.com>,
Thomas Gleixner <tglx@...utronix.de>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky <thomas.lendacky@....com> wrote:
> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>
>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky <thomas.lendacky@....com>
>> wrote:
>>>
>>> Currently there is a check if the address being mapped is in the ISA
>>> range (is_ISA_range()), and if it is, then phys_to_virt() is used to
>>> perform the mapping. When SME is active, the default is to add pagetable
>>> mappings with the encryption bit set unless specifically overridden. The
>>> resulting pagetable mapping from phys_to_virt() will result in a mapping
>>> that has the encryption bit set. With SME, the use of ioremap() is
>>> intended to generate pagetable mappings that do not have the encryption
>>> bit set through the use of the PAGE_KERNEL_IO protection value.
>>>
>>> Rather than special case the SME scenario, remove the ISA range check and
>>> usage of phys_to_virt() and have ISA range mappings continue through the
>>> remaining ioremap() path.
>>>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
>>> ---
>>> arch/x86/mm/ioremap.c | 7 +------
>>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>>> index 4c1b5fd..bfc3e2d 100644
>>> --- a/arch/x86/mm/ioremap.c
>>> +++ b/arch/x86/mm/ioremap.c
>>> @@ -13,6 +13,7 @@
>>> #include <linux/slab.h>
>>> #include <linux/vmalloc.h>
>>> #include <linux/mmiotrace.h>
>>> +#include <linux/mem_encrypt.h>
>>>
>>> #include <asm/set_memory.h>
>>> #include <asm/e820/api.h>
>>> @@ -106,12 +107,6 @@ static void __iomem
>>> *__ioremap_caller(resource_size_t phys_addr,
>>> }
>>>
>>> /*
>>> - * Don't remap the low PCI/ISA area, it's always mapped..
>>> - */
>>> - if (is_ISA_range(phys_addr, last_addr))
>>> - return (__force void __iomem *)phys_to_virt(phys_addr);
>>> -
>>> - /*
>>> * Don't allow anybody to remap normal RAM that we're using..
>>> */
>>> pfn = phys_addr >> PAGE_SHIFT;
>>>
>>
>> Removing this also affects 32-bit, which is more likely to access
>> legacy devices in this range. Put in a check for SME instead
>
>
> I originally had a check for SME here in a previous version of the
> patch. Thomas Gleixner recommended removing the check so that the code
> path was always exercised regardless of the state of SME in order to
> better detect issues:
>
> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>
> Thanks,
> Tom
Looking a bit closer, this shortcut doesn't set the caching
attributes. So it's probably best to get rid of it anyways. Also
note, there is a corresponding check in iounmap().
--
Brian Gerst
Powered by blists - more mailing lists