linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Dave Young <dyoung@redhat.com>, lijiang <lijiang@redhat.com>
Cc: bhe@redhat.com, linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, hpa@zytor.com, ebiederm@xmission.com,
	joro@8bytes.org, thomas.lendacky@amd.com,
	kexec@lists.infradead.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled
Date: Fri, 20 Jul 2018 09:32:45 +0200	[thread overview]
Message-ID: <20180720073245.GA26926@nazgul.tnic> (raw)
In-Reply-To: <20180720052304.GA9146@dhcp-128-65.nay.redhat.com>

On Fri, Jul 20, 2018 at 01:23:04PM +0800, Dave Young wrote:
> > Here, it doesn't need to dump MMIO space of the previous kernel, when the
> > kdump kernel boot, the MMIO address will be remapped in decryption manners,
> > but the MMIO address don't belong to the range of the crash reserved memory,
> > for the kdump kernel, the MMIO space(address) and IOMMU device table(address)
> > are outside address, whereas, the IOMMU device table is encrypted in the first
> > kernel, the kdump kernel will need to copy the content of IOMMU device table
> > from the first kernel when the kdump kernel boot, so the IOMMU device table will
> > be remapped in encryption manners.

-ENOFCKINGPARSE

I believe you're the only one who understands that humongous sentence.
How about using a fullstop from time to time. And WTF is "encryption
manners"?

> > So some of them require to be remapped in encryption manners, and some(address)
> > require to be remapped in decryption manners.

> There could be some misunderstanding here.

Hell yeah there's a misunderstanding!

Can you folks first relax, sit down and explain the whole problem in
*plain* English using *simple* sentences. *Not* like the unparseable
mess above. Use simple, declaratory sentences and don't even try to
sound fancy:

"The first kernel boots. It's memory is encrypted... Now, the second
kernel boots. It must do A because of B. In order to do A, it needs to
do C. Because D..."

And so on. Explain what the problem is first. Then explain the proposed
solution. Explain *why* it needs to be done this way.

When you've written your explanation, try to read it as someone who
doesn't know kdump and *think* hard whether your explanation makes
sense. If it doesn't, fix it and read it again. Rinse and repeat. Until
it is clear to unenlightened readers too.

It is about time this hurried throwing of half-baked patches at
maintainers and seeing what sticks, stops!

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  reply	other threads:[~2018-07-20  7:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02  7:26 [PATCH 0/5 V5] Support kdump for AMD secure memory encryption(SME) Lianbo Jiang
2018-07-02  7:26 ` [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled Lianbo Jiang
2018-07-02 10:14   ` Borislav Petkov
2018-07-03  2:17     ` lijiang
2018-07-03  9:39       ` Borislav Petkov
2018-07-03 11:25         ` lijiang
2018-07-03 10:58       ` lijiang
2018-07-03 11:14         ` Borislav Petkov
2018-07-03 11:44           ` lijiang
2018-07-09  6:28             ` lijiang
2018-07-09  9:29               ` Borislav Petkov
2018-07-09 13:55                 ` lijiang
2018-07-13 17:08                   ` Borislav Petkov
2018-07-20  5:06                     ` lijiang
2018-07-20  5:23                       ` Dave Young
2018-07-20  7:32                         ` Borislav Petkov [this message]
2018-07-20  9:55                           ` lijiang
2018-07-20 10:08                             ` Boris Petkov
2018-08-16  5:35                               ` lijiang
2018-08-23 15:21                                 ` Borislav Petkov
2018-07-02  7:26 ` [PATCH 2/5 V5] Allocate pages for kdump without encryption when SME is enabled Lianbo Jiang
2018-07-02  7:26 ` [PATCH 3/5 V5] Remap the device table of IOMMU in encrypted manner for kdump Lianbo Jiang
2018-07-02  7:26 ` [PATCH 4/5 V5] Adjust some permanent mappings in unencrypted ways for kdump when SME is enabled Lianbo Jiang
2018-07-02  7:26 ` [PATCH 5/5 V5] Help to dump the old memory encrypted into vmcore file Lianbo Jiang

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=20180720073245.GA26926@nazgul.tnic \
    --to=bp@alien8.de \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kexec@lists.infradead.org \
    --cc=lijiang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    /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).