From: Halil Pasic <pasic@linux.ibm.com> To: Thiago Jung Bauermann <bauerman@linux.ibm.com> Cc: linux-s390@vger.kernel.org, Mike Anderson <andmike@linux.ibm.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Robin Murphy <robin.murphy@arm.com>, x86@kernel.org, Ram Pai <linuxram@us.ibm.com>, linux-kernel@vger.kernel.org, Alexey Dobriyan <adobriyan@gmail.com>, iommu@lists.linux-foundation.org, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, linux-fsdevel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>, linuxppc-dev@lists.ozlabs.org, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH 3/3] fs/core/vmcore: Move sev_active() reference to x86 arch code Date: Fri, 12 Jul 2019 15:09:12 +0200 Message-ID: <20190712150912.3097215e.pasic@linux.ibm.com> (raw) In-Reply-To: <20190712053631.9814-4-bauerman@linux.ibm.com> On Fri, 12 Jul 2019 02:36:31 -0300 Thiago Jung Bauermann <bauerman@linux.ibm.com> wrote: > Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't > appear in generic kernel code because it forces non-x86 architectures to > define the sev_active() function, which doesn't make a lot of sense. sev_active() might be just bad (too specific) name for a general concept. s390 code defines it drives the right behavior in kernel/dma/direct.c (which uses it). > > To solve this problem, add an x86 elfcorehdr_read() function to override > the generic weak implementation. To do that, it's necessary to make > read_from_oldmem() public so that it can be used outside of vmcore.c. > > Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> > --- > arch/x86/kernel/crash_dump_64.c | 5 +++++ > fs/proc/vmcore.c | 8 ++++---- > include/linux/crash_dump.h | 14 ++++++++++++++ > include/linux/mem_encrypt.h | 1 - > 4 files changed, 23 insertions(+), 5 deletions(-) Does not seem to apply to today's or yesterdays master. > > diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c > index 22369dd5de3b..045e82e8945b 100644 > --- a/arch/x86/kernel/crash_dump_64.c > +++ b/arch/x86/kernel/crash_dump_64.c > @@ -70,3 +70,8 @@ ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize, > { > return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, true); > } > + > +ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos) > +{ > + return read_from_oldmem(buf, count, ppos, 0, sev_active()); > +} > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index 57957c91c6df..ca1f20bedd8c 100644 > --- a/fs/proc/vmcore.c > +++ b/fs/proc/vmcore.c > @@ -100,9 +100,9 @@ static int pfn_is_ram(unsigned long pfn) > } > > /* Reads a page from the oldmem device from given offset. */ > -static ssize_t read_from_oldmem(char *buf, size_t count, > - u64 *ppos, int userbuf, > - bool encrypted) > +ssize_t read_from_oldmem(char *buf, size_t count, > + u64 *ppos, int userbuf, > + bool encrypted) > { > unsigned long pfn, offset; > size_t nr_bytes; > @@ -166,7 +166,7 @@ void __weak elfcorehdr_free(unsigned long long addr) > */ > ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos) > { > - return read_from_oldmem(buf, count, ppos, 0, sev_active()); > + return read_from_oldmem(buf, count, ppos, 0, false); > } > > /* > diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h > index f774c5eb9e3c..4664fc1871de 100644 > --- a/include/linux/crash_dump.h > +++ b/include/linux/crash_dump.h > @@ -115,4 +115,18 @@ static inline int vmcore_add_device_dump(struct vmcoredd_data *data) > return -EOPNOTSUPP; > } > #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ > + > +#ifdef CONFIG_PROC_VMCORE > +ssize_t read_from_oldmem(char *buf, size_t count, > + u64 *ppos, int userbuf, > + bool encrypted); > +#else > +static inline ssize_t read_from_oldmem(char *buf, size_t count, > + u64 *ppos, int userbuf, > + bool encrypted) > +{ > + return -EOPNOTSUPP; > +} > +#endif /* CONFIG_PROC_VMCORE */ > + > #endif /* LINUX_CRASHDUMP_H */ > diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h > index f2e399fb626b..a3747fcae466 100644 > --- a/include/linux/mem_encrypt.h > +++ b/include/linux/mem_encrypt.h > @@ -21,7 +21,6 @@ > > #else /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */ > > -static inline bool sev_active(void) { return false; } This is the implementation for the guys that don't have ARCH_HAS_MEM_ENCRYPT. Means sev_active() may not be used in such code after this patch. What about static inline bool force_dma_unencrypted(void) { return sev_active(); } in kernel/dma/direct.c? Regards, Halil > static inline bool mem_encrypt_active(void) { return false; } > > #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */ _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-12 5:36 [PATCH 0/3] Remove x86-specific code from generic headers Thiago Jung Bauermann 2019-07-12 5:36 ` [PATCH 1/3] x86/Kconfig: Move ARCH_HAS_MEM_ENCRYPT to arch/Kconfig Thiago Jung Bauermann 2019-07-12 16:04 ` Thomas Gleixner 2019-07-12 23:35 ` Thiago Jung Bauermann 2019-07-12 5:36 ` [PATCH 2/3] DMA mapping: Move SME handling to x86-specific files Thiago Jung Bauermann 2019-07-12 7:13 ` Christoph Hellwig 2019-07-12 23:42 ` Thiago Jung Bauermann 2019-07-12 16:09 ` Thomas Gleixner 2019-07-18 19:47 ` Thiago Jung Bauermann 2019-07-19 9:05 ` kbuild test robot 2019-07-20 0:22 ` Thiago Jung Bauermann 2019-07-12 5:36 ` [PATCH 3/3] fs/core/vmcore: Move sev_active() reference to x86 arch code Thiago Jung Bauermann 2019-07-12 13:09 ` Halil Pasic [this message] 2019-07-12 14:08 ` Christoph Hellwig 2019-07-12 14:51 ` Halil Pasic 2019-07-12 15:11 ` Christoph Hellwig 2019-07-12 15:42 ` Halil Pasic 2019-07-13 8:08 ` Christoph Hellwig 2019-07-12 21:55 ` Thiago Jung Bauermann 2019-07-15 14:03 ` Halil Pasic 2019-07-15 14:30 ` Christoph Hellwig 2019-07-15 15:44 ` Lendacky, Thomas 2019-07-15 20:14 ` Thiago Jung Bauermann 2019-07-13 4:45 [PATCH 0/3] Remove x86-specific code from generic headers Thiago Jung Bauermann 2019-07-13 4:45 ` [PATCH 3/3] fs/core/vmcore: Move sev_active() reference to x86 arch code Thiago Jung Bauermann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190712150912.3097215e.pasic@linux.ibm.com \ --to=pasic@linux.ibm.com \ --cc=adobriyan@gmail.com \ --cc=andmike@linux.ibm.com \ --cc=bauerman@linux.ibm.com \ --cc=bp@alien8.de \ --cc=hch@lst.de \ --cc=hpa@zytor.com \ --cc=iommu@lists.linux-foundation.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=linuxram@us.ibm.com \ --cc=mingo@redhat.com \ --cc=robin.murphy@arm.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
IOMMU Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-iommu/0 linux-iommu/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-iommu linux-iommu/ https://lore.kernel.org/linux-iommu \ iommu@lists.linux-foundation.org public-inbox-index linux-iommu Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.linux-foundation.lists.iommu AGPL code for this site: git clone https://public-inbox.org/public-inbox.git