[PATCH kernel 1/1] powerpc/Documentation/misc-devices/: Fix one compile error

[fgao]

From: Gao Feng 

When make allyesconfig, there is one compile error on my platform
"gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4".
The following is the output.

Documentation/misc-devices/mei/mei-amt-version.c: In function ‘main’:
Documentation/misc-devices/mei/mei-amt-version.c:103:5: warning: ‘acmd.fd’
is used uninitialized in this function [-Wuninitialized]
  if (cl->fd != -1)
 ^
Documentation/misc-devices/mei/mei-amt-version.c:443:21: note: ‘acmd.fd’
was declared here
  struct amt_host_if acmd;
 ^
This commit fixes this compile error.

Signed-off-by: Gao Feng 
---
 Documentation/misc-devices/mei/mei-amt-version.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/misc-devices/mei/mei-amt-version.c 
b/Documentation/misc-devices/mei/mei-amt-version.c
index 49e4f77..ca035cb 100644
--- a/Documentation/misc-devices/mei/mei-amt-version.c
+++ b/Documentation/misc-devices/mei/mei-amt-version.c
@@ -297,6 +297,7 @@ static bool amt_host_if_init(struct amt_host_if *acmd,
  unsigned long send_timeout, bool verbose)
 {
acmd->send_timeout = (send_timeout) ? send_timeout : 2;
+   acmd->mei_cl.fd = -1;
acmd->initialized = mei_init(>mei_cl, _IAMTHIF, 0, verbose);
return acmd->initialized;
 }
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/8] Documentation: arm: Marvell: Document IAP140

[Andreas Färber]

IAP140 is either based on or was renamed from PXA1908.

Signed-off-by: Andreas Färber 
---
 v2: new (Thomas)
 
 Documentation/arm/Marvell/README | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index b5bb7f5..e9d4873 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -243,7 +243,7 @@ PXA 2xx/3xx/93x/95x family
Linux kernel plat directory: arch/arm/plat-pxa
 
 MMP/MMP2/MMP3 family (communication processor)
--
+--
 
Flavors:
 PXA168, a.k.a Armada 168
@@ -295,6 +295,16 @@ MMP/MMP2/MMP3 family (communication processor)
Linux kernel mach directory: arch/arm/mach-mmp
Linux kernel plat directory: arch/arm/plat-pxa
 
+MMP ARMv8 family (application processor)
+
+
+  Flavors:
+IAP140
+  Product brief: 
http://www.marvell.com/application-processors/assets/Marvell-IAP140-Platform-Brief-20160601.pdf
+  Core: quad-core ARMv8 Cortex-A53
+
+  Homepage: http://www.marvell.com/application-processors/
+
 Berlin family (Multimedia Solutions)
 -
 
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] cpufreq: User/admin documentation update and consolidation

[Rafael J. Wysocki]

On Tuesday, February 21, 2017 10:30:10 AM Viresh Kumar wrote:
> On 20-02-17, 14:58, Rafael J. Wysocki wrote:
> > Yes, it is called for new and inactive policies.
> > 
> > For new policies it has to populate policy->cpus (because otherwise the core
> > doesn't know what CPUs should be there), which quite arguably doesn't have
> > to (or even doesn't need to) be done for inactive policies (because they 
> > already
> > have policy->real_cpus and policy->related_cpus populated).
>  
> > I would even argue that ->init() should not update policy->cpus for inactive
> > (but not new) policies.
> 
> I agree, but I am not aware of any platforms that we have today which
> does any similar checks in ->init(). And I wouldn't encourage drivers
> to have such special handling at all. Why make it complex?

Well, IMO we should not invoke the same callback in two different cases and
then do tricks in the core to make one of them work.  That's just too [edited]
ugly.

At least it doesn't help to understand the code flow.

> The way you have written it earlier suggests that the drivers should
> check if the policy is active or not (by looking at related_cpus mask)
> and set the cpus mask only for new policies. I was just worried that
> new driver authors will actually try to write special code in init()
> for that and if we really want that to be the case.

That would not be a bug IMO.  Some of them could just check related_cpus
and do nothing if it is set I suppose?

Anyway, this isn't a driver API document, so the description is not 
super-precise.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] switchtec: cleanup cdev init

[Jason Gunthorpe]

On Sun, Feb 19, 2017 at 09:22:35PM -0700, Logan Gunthorpe wrote:

> Really, in any situation where there's a cdev and a device in the same
> structure, the life cycles of the two become linked but their reference
> counts are not and that is the problem here.

Yes, the cdev must hold a kref on the containing struct otherwise
userspace can trigger a use after free. This cannot be fixed with an
approach inside the open/release function either as the cdev core code
itself relies on the memory to exist.

I've suggested something like this before:

https://lkml.org/lkml/2015/7/8/1066

So I hope this will make it in, it is a step in the right direction.

If it does, would you make another patch to go further? I think
cdev_init should take enough arguments to hold the enclosing kref, API
wise there should be no API to init a cdev without the caller
specifying the enclosing struct's kref. That is the only way we will
stamp this bug-class out.

Eg look at kernel/time/posix-clock.c, it is wrong in the same way as
well - the kref_put in posix_clock_release is not enough to make it
work, clk->cdev is referenced after posix_clock_release returns by the
cdev core so this has a use-after-free.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

[Borislav Petkov]

On Tue, Feb 21, 2017 at 12:42:45PM -0500, Rik van Riel wrote:
> Do we want that in kernel/ or in arch/x86/mm/ ?

If you'd ask me, I don't have a strong preference. It is a pile of
functionality which is part of the SME feature and as such, it is closer
to the CPU. So arch/x86/cpu/sme.c or so.

But then it is mm-related in a way as it is RAM encryption...

Meh, ask me something easier :-)

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

[Rik van Riel]

On Sat, 2017-02-18 at 19:12 +0100, Borislav Petkov wrote:
> On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote:
> > 
> >  create mode 100644 Documentation/x86/amd-memory-encryption.txt
> >  create mode 100644 arch/x86/include/asm/mem_encrypt.h
> >  create mode 100644 arch/x86/kernel/mem_encrypt_boot.S
> >  create mode 100644 arch/x86/kernel/mem_encrypt_init.c
> >  create mode 100644 arch/x86/mm/mem_encrypt.c
> I don't see anything standing in the way of merging those last two
> and
> having a single:
> 
> arch/x86/kernel/mem_encrypt.c

Do we want that in kernel/ or in arch/x86/mm/ ?

-- 
All rights reversed


signature.asc
Description: This is a digitally signed message part

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

[Tom Lendacky]

On 2/20/2017 9:21 AM, Borislav Petkov wrote:

On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote:

Adding general kernel support for memory encryption includes:
- Modify and create some page table macros to include the Secure Memory
  Encryption (SME) memory encryption mask


Let's not write it like some technical document: "Secure Memory
Encryption (SME) mask" is perfectly fine.


Ok.




- Modify and create some macros for calculating physical and virtual
  memory addresses
- Provide an SME initialization routine to update the protection map with
  the memory encryption mask so that it is used by default
- #undef CONFIG_AMD_MEM_ENCRYPT in the compressed boot path


These bulletpoints talk about the "what" this patch does but they should
talk about the "why".

For example, it doesn't say why we're using _KERNPG_TABLE_NOENC when
building the initial pagetable and that would be an interesting piece of
information.


I'll work on re-wording this to give a better understanding of the
patch changes.




Signed-off-by: Tom Lendacky 
---
 arch/x86/boot/compressed/pagetable.c |7 +
 arch/x86/include/asm/fixmap.h|7 +
 arch/x86/include/asm/mem_encrypt.h   |   14 +++
 arch/x86/include/asm/page.h  |4 ++-
 arch/x86/include/asm/pgtable.h   |   26 ++--
 arch/x86/include/asm/pgtable_types.h |   45 ++
 arch/x86/include/asm/processor.h |3 ++
 arch/x86/kernel/espfix_64.c  |2 +-
 arch/x86/kernel/head64.c |   12 -
 arch/x86/kernel/head_64.S|   18 +++---
 arch/x86/mm/kasan_init_64.c  |4 ++-
 arch/x86/mm/mem_encrypt.c|   20 +++
 arch/x86/mm/pageattr.c   |3 ++
 include/asm-generic/pgtable.h|8 ++
 14 files changed, 133 insertions(+), 40 deletions(-)

diff --git a/arch/x86/boot/compressed/pagetable.c 
b/arch/x86/boot/compressed/pagetable.c
index 56589d0..411c443 100644
--- a/arch/x86/boot/compressed/pagetable.c
+++ b/arch/x86/boot/compressed/pagetable.c
@@ -15,6 +15,13 @@
 #define __pa(x)  ((unsigned long)(x))
 #define __va(x)  ((void *)((unsigned long)(x)))

+/*
+ * The pgtable.h and mm/ident_map.c includes make use of the SME related
+ * information which is not used in the compressed image support. Un-define
+ * the SME support to avoid any compile and link errors.
+ */
+#undef CONFIG_AMD_MEM_ENCRYPT
+
 #include "misc.h"

 /* These actually do the work of building the kernel identity maps. */
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 8554f96..83e91f0 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -153,6 +153,13 @@ static inline void __set_fixmap(enum fixed_addresses idx,
 }
 #endif

+/*
+ * Fixmap settings used with memory encryption
+ *   - FIXMAP_PAGE_NOCACHE is used for MMIO so make sure the memory
+ * encryption mask is not part of the page attributes


Make that a regular sentence.


Ok.




+ */
+#define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_IO_NOCACHE
+
 #include 

 #define __late_set_fixmap(idx, phys, flags) __set_fixmap(idx, phys, flags)
diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index ccc53b0..547989d 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -15,6 +15,8 @@

 #ifndef __ASSEMBLY__

+#include 
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT

 extern unsigned long sme_me_mask;
@@ -24,6 +26,11 @@ static inline bool sme_active(void)
return (sme_me_mask) ? true : false;
 }

+void __init sme_early_init(void);
+
+#define __sme_pa(x)(__pa((x)) | sme_me_mask)
+#define __sme_pa_nodebug(x)(__pa_nodebug((x)) | sme_me_mask)


Right, I know we did talk about those but in looking more into the
future, you'd have to go educate people to use the __sme_pa* variants.
Otherwise, we'd have to go and fix up code on AMD SME machines because
someone used __pa_* variants where someone should have been using the
__sma_pa_* variants.

IOW, should we simply put sme_me_mask in the actual __pa* macro
definitions?

Or are we saying that the __sme_pa* versions you have above are
the special ones and we need them only in a handful of places like
load_cr3(), for example...? And the __pa_* ones should return the
physical address without the SME mask because callers don't need it?


It's the latter.  It's really only used for working with values that
will either be written to or read from cr3.  I'll add some comments
around the macros as well as expand on it in the commit message.




+
 #else  /* !CONFIG_AMD_MEM_ENCRYPT */

 #ifndef sme_me_mask
@@ -35,6 +42,13 @@ static inline bool sme_active(void)
 }
 #endif

+static inline void __init sme_early_init(void)
+{
+}
+
+#define __sme_pa   __pa
+#define __sme_pa_nodebug   __pa_nodebug
+
 #endif /* CONFIG_AMD_MEM_ENCRYPT */

 #endif /* __ASSEMBLY__ */
diff --git 

Re: [PATCH] docs: hwmon: Fix typo "Microship" should be "Microchip"

[Guenter Roeck]

On Tue, Feb 21, 2017 at 10:30:47PM +1300, Chris Packham wrote:
> Signed-off-by: Chris Packham 

Applied to -next.

Thanks,
Guenter

> ---
>  Documentation/hwmon/tc654 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
> index 91a2843f5f98..47636a8077b4 100644
> --- a/Documentation/hwmon/tc654
> +++ b/Documentation/hwmon/tc654
> @@ -2,7 +2,7 @@ Kernel driver tc654
>  ===
>  
>  Supported chips:
> -  * Microship TC654 and TC655
> +  * Microchip TC654 and TC655
>  Prefix: 'tc654'
>  Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
>  
> -- 
> 2.11.0.24.ge6920cf
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 06/28] x86: Add support to enable SME during early boot processing

[Borislav Petkov]

On Tue, Feb 21, 2017 at 08:55:30AM -0600, Tom Lendacky wrote:
> Actually, %rbp will have the encryption bit set in it at the time of the
> check so if SME is active we won't take the jump to .Lskip_fixup.

Ha, I didn't think of that! Do you see now what I mean with being
explicit in the asm boot code? :-)

Please note that in the comment above sme_encrypt_kernel().

Thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

[Tom Lendacky]

On 2/18/2017 12:12 PM, Borislav Petkov wrote:

On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote:

 create mode 100644 Documentation/x86/amd-memory-encryption.txt
 create mode 100644 arch/x86/include/asm/mem_encrypt.h
 create mode 100644 arch/x86/kernel/mem_encrypt_boot.S
 create mode 100644 arch/x86/kernel/mem_encrypt_init.c
 create mode 100644 arch/x86/mm/mem_encrypt.c


I don't see anything standing in the way of merging those last two and
having a single:

arch/x86/kernel/mem_encrypt.c

with all functionality in there with ifdeffery around it so
that sme_encrypt_kernel() et all are still visible in the
!CONFIG_AMD_MEM_ENCRYPT case.


Sounds good. I'll combine those two files.

Thanks,
Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

[Borislav Petkov]

On Thu, Feb 16, 2017 at 09:45:09AM -0600, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be mapped decrypted.  Add support to apply the proper
> attributes to the EFI page tables and to the early_memremap and memremap
> APIs to identify the type of data being accessed so that the proper
> encryption attribute can be applied.

So this doesn't even begin to explain *why* we need this. The emphasis
being on *why*.

Lemme guess? kexec? And because of efi_reuse_config?

If so, then that whole ad-hoc caching in parse_setup_data() needs to go.
Especially if efi_reuse_config() already sees those addresses so while
we're there, we could save them somewhere or whatnot. But not doing the
whole thing again in parse_setup_data().

> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/io.h  |3 +
>  arch/x86/include/asm/setup.h   |8 +++
>  arch/x86/kernel/setup.c|   33 
>  arch/x86/mm/ioremap.c  |  111 
> 
>  arch/x86/platform/efi/efi_64.c |   16 --
>  kernel/memremap.c  |   11 
>  mm/early_ioremap.c |   18 +-
>  7 files changed, 192 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 7afb0e2..833f7cc 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -381,4 +381,7 @@ extern int __must_check arch_phys_wc_add(unsigned long 
> base,
>  #define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc
>  #endif
>  
> +extern bool arch_memremap_do_ram_remap(resource_size_t offset, size_t size);
> +#define arch_memremap_do_ram_remap arch_memremap_do_ram_remap
> +
>  #endif /* _ASM_X86_IO_H */
> diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
> index ac1d5da..8d9 100644
> --- a/arch/x86/include/asm/setup.h
> +++ b/arch/x86/include/asm/setup.h
> @@ -63,6 +63,14 @@ static inline void x86_ce4100_early_setup(void) { }
>  #include 
>  #include 
>  
> +struct setup_data_attrs {
> + u64 paddr;
> + unsigned long size;
> +};
> +
> +extern struct setup_data_attrs setup_data_list[];
> +extern unsigned int setup_data_list_count;
> +
>  /*
>   * This is set up by the setup-routine at boot-time
>   */
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index bd5b9a7..d2234bf 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -148,6 +148,9 @@ int default_check_phys_apicid_present(int phys_apicid)
>  
>  struct boot_params boot_params;
>  
> +struct setup_data_attrs setup_data_list[32];
> +unsigned int setup_data_list_count;
> +
>  /*
>   * Machine setup..
>   */
> @@ -419,6 +422,32 @@ static void __init reserve_initrd(void)
>  }
>  #endif /* CONFIG_BLK_DEV_INITRD */
>  
> +static void __init update_setup_data_list(u64 pa_data, unsigned long size)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < setup_data_list_count; i++) {
> + if (setup_data_list[i].paddr != pa_data)
> + continue;
> +
> + setup_data_list[i].size = size;
> + break;
> + }
> +}
> +
> +static void __init add_to_setup_data_list(u64 pa_data, unsigned long size)
> +{
> + if (!sme_active())
> + return;
> +
> + if (!WARN(setup_data_list_count == ARRAY_SIZE(setup_data_list),
> +   "exceeded maximum setup data list slots")) {
> + setup_data_list[setup_data_list_count].paddr = pa_data;
> + setup_data_list[setup_data_list_count].size = size;
> + setup_data_list_count++;
> + }
> +}
> +
>  static void __init parse_setup_data(void)
>  {
>   struct setup_data *data;
> @@ -428,12 +457,16 @@ static void __init parse_setup_data(void)
>   while (pa_data) {
>   u32 data_len, data_type;
>  
> + add_to_setup_data_list(pa_data, sizeof(*data));
> +
>   data = early_memremap(pa_data, sizeof(*data));
>   data_len = data->len + sizeof(struct setup_data);
>   data_type = data->type;
>   pa_next = data->next;
>   early_memunmap(data, sizeof(*data));
>  
> + update_setup_data_list(pa_data, data_len);
> +
>   switch (data_type) {
>   case SETUP_E820_EXT:
>   e820__memory_setup_extended(pa_data, data_len);
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 2385e70..b0ff6bc 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -21,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "physaddr.h"
>  
> @@ -419,6 +421,115 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
>   iounmap((void __iomem *)((unsigned long)addr & PAGE_MASK));
>  }
>  
> +/*
> + * Examine the physical address 

Re: [RFC PATCH v4 06/28] x86: Add support to enable SME during early boot processing

[Tom Lendacky]

On 2/20/2017 6:51 AM, Borislav Petkov wrote:

On Thu, Feb 16, 2017 at 09:43:19AM -0600, Tom Lendacky wrote:

This patch adds support to the early boot code to use Secure Memory
Encryption (SME).  Support is added to update the early pagetables with
the memory encryption mask and to encrypt the kernel in place.

The routines to set the encryption mask and perform the encryption are
stub routines for now with full function to be added in a later patch.


s/full function/functionality/


Ok.




A new file, arch/x86/kernel/mem_encrypt_init.c, is introduced to avoid
adding #ifdefs within arch/x86/kernel/head_64.S and allow
arch/x86/mm/mem_encrypt.c to be removed from the build if SME is not
configured. The mem_encrypt_init.c file will contain the necessary #ifdefs
to allow head_64.S to successfully build and call the SME routines.


That paragraph is superfluous.


I'll remove this, especially since the files will be combined now.




Signed-off-by: Tom Lendacky 
---
 arch/x86/kernel/Makefile   |2 +
 arch/x86/kernel/head_64.S  |   46 -
 arch/x86/kernel/mem_encrypt_init.c |   50 
 3 files changed, 96 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/kernel/mem_encrypt_init.c

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index bdcdb3b..33af80a 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -140,4 +140,6 @@ ifeq ($(CONFIG_X86_64),y)

obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
+
+   obj-y   += mem_encrypt_init.o
 endif
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index b467b14..4f8201b 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -91,6 +91,23 @@ startup_64:
jnz bad_address

/*
+* Enable Secure Memory Encryption (SME), if supported and enabled.
+* The real_mode_data address is in %rsi and that register can be
+* clobbered by the called function so be sure to save it.
+* Save the returned mask in %r12 for later use.
+*/
+   push%rsi
+   callsme_enable
+   pop %rsi
+   movq%rax, %r12
+
+   /*
+* Add the memory encryption mask to %rbp to include it in the page
+* table fixups.
+*/
+   addq%r12, %rbp
+
+   /*
 * Fixup the physical addresses in the page table
 */
addq%rbp, early_level4_pgt + (L4_START_KERNEL*8)(%rip)
@@ -113,6 +130,7 @@ startup_64:
shrq$PGDIR_SHIFT, %rax

leaq(PAGE_SIZE + _KERNPG_TABLE)(%rbx), %rdx
+   addq%r12, %rdx
movq%rdx, 0(%rbx,%rax,8)
movq%rdx, 8(%rbx,%rax,8)

@@ -129,6 +147,7 @@ startup_64:
movq%rdi, %rax
shrq$PMD_SHIFT, %rdi
addq$(__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL), %rax
+   addq%r12, %rax
leaq(_end - 1)(%rip), %rcx
shrq$PMD_SHIFT, %rcx
subq%rdi, %rcx
@@ -162,11 +181,25 @@ startup_64:
cmp %r8, %rdi
jne 1b

-   /* Fixup phys_base */
+   /*
+* Fixup phys_base - remove the memory encryption mask from %rbp
+* to obtain the true physical address.
+*/
+   subq%r12, %rbp
addq%rbp, phys_base(%rip)

+   /*
+* Encrypt the kernel if SME is active.
+* The real_mode_data address is in %rsi and that register can be
+* clobbered by the called function so be sure to save it.
+*/
+   push%rsi
+   callsme_encrypt_kernel
+   pop %rsi
+
 .Lskip_fixup:


So if we land on this label because we can skip the fixup due to %rbp
being 0, we will skip sme_encrypt_kernel() too.

I think you need to move the .Lskip_fixup label above the
sme_encrypt_kernel call.


Actually, %rbp will have the encryption bit set in it at the time of the
check so if SME is active we won't take the jump to .Lskip_fixup.




movq$(early_level4_pgt - __START_KERNEL_map), %rax
+   addq%r12, %rax
jmp 1f
 ENTRY(secondary_startup_64)
/*
@@ -186,7 +219,16 @@ ENTRY(secondary_startup_64)
/* Sanitize CPU configuration */
call verify_cpu

-   movq$(init_level4_pgt - __START_KERNEL_map), %rax
+   /*
+* Get the SME encryption mask.
+* The real_mode_data address is in %rsi and that register can be
+* clobbered by the called function so be sure to save it.


You can say here that sme_get_me_mask puts the mask in %rax, that's why
we do ADD below and not MOV. I know, it is very explicit but this is
boot asm and I'd prefer for it to be absolutely clear.


Ok, I can be explicit on this.




+*/
+   push%rsi
+   callsme_get_me_mask
+   pop %rsi
+
+   addq$(init_level4_pgt - __START_KERNEL_map), 

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

[Matt Fleming]

On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote:
> Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a
> hardcoded 0.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/platform/efi/efi.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index a15cf81..6407103 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -1037,7 +1037,7 @@ u32 efi_mem_type(unsigned long phys_addr)
>   efi_memory_desc_t *md;
>  
>   if (!efi_enabled(EFI_MEMMAP))
> - return 0;
> + return EFI_RESERVED_TYPE;
>  
>   for_each_efi_memory_desc(md) {
>   if ((md->phys_addr <= phys_addr) &&
> @@ -1045,7 +1045,7 @@ u32 efi_mem_type(unsigned long phys_addr)
> (md->num_pages << EFI_PAGE_SHIFT
>   return md->type;
>   }
> - return 0;
> + return EFI_RESERVED_TYPE;
>  }

I see what you're getting at here, but arguably the return value in
these cases never should have been zero to begin with (your change
just makes that more obvious).

Returning EFI_RESERVED_TYPE implies an EFI memmap entry exists for
this address, which is misleading because it doesn't in the hunks
you've modified above.

Instead, could you look at returning a negative error value in the
usual way we do in the Linux kernel, and update the function prototype
to match? I don't think any callers actually require the return type
to be u32.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] docs: hwmon: Fix typo "Microship" should be "Microchip"

[Chris Packham]

Signed-off-by: Chris Packham 
---
 Documentation/hwmon/tc654 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
index 91a2843f5f98..47636a8077b4 100644
--- a/Documentation/hwmon/tc654
+++ b/Documentation/hwmon/tc654
@@ -2,7 +2,7 @@ Kernel driver tc654
 ===
 
 Supported chips:
-  * Microship TC654 and TC655
+  * Microchip TC654 and TC655
 Prefix: 'tc654'
 Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
 
-- 
2.11.0.24.ge6920cf

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html