linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Halil Pasic <pasic@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>,
	"Lendacky, Thomas" <thomas.lendacky@amd.com>,
	"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>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 3/3] fs/core/vmcore: Move sev_active() reference to x86 arch code
Date: Fri, 12 Jul 2019 18:55:47 -0300	[thread overview]
Message-ID: <87tvbqgboc.fsf@morokweng.localdomain> (raw)
In-Reply-To: <20190712150912.3097215e.pasic@linux.ibm.com>


[ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]

Hello Halil,

Thanks for the quick review.

Halil Pasic <pasic@linux.ibm.com> writes:

> 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).

I thought about that but couldn't put my finger on a general concept.
Is it "guest with memory inaccessible to the host"?

Since your proposed definiton for force_dma_unencrypted() is simply to
make it equivalent to sev_active(), I thought it was more
straightforward to make each arch define force_dma_unencrypted()
directly.

Also, does sev_active() drive the right behavior for s390 in
elfcorehdr_read() as well?

>> 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.

It assumes the presence of the two patches I mentioned in the cover
letter. Only one of them is in master.

I hadn't realized the s390 virtio patches were on their way to upstream.
I was keeping an eye on the email thread but didn't see they were picked
up in the s390 pull request. I'll add a new patch to this series making
the corresponding changes to s390's <asm/mem_encrypt.h> as well.

--
Thiago Jung Bauermann
IBM Linux Technology Center


  parent reply	other threads:[~2019-07-12 21:57 UTC|newest]

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
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 [this message]
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=87tvbqgboc.fsf@morokweng.localdomain \
    --to=bauerman@linux.ibm.com \
    --cc=adobriyan@gmail.com \
    --cc=andmike@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=m.szyprowski@samsung.com \
    --cc=mingo@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=robin.murphy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).