Re: [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo
Date: Wed Oct 31 2018 - 03:43:34 EST
å 2018å10æ31æ 10:47, Dave Young åé:
> Add Kazu, the makedumpfile maintainer in cc.
> On 10/31/18 at 10:26am, lijiang wrote:
>> å 2018å10æ30æ 17:23, Baoquan He åé:
>>> Hi Boris, DaveY and Lianbo,
>>> On 10/30/18 at 10:15am, Borislav Petkov wrote:
>>>> On Tue, Oct 30, 2018 at 01:09:00PM +0800, Dave Young wrote:
>>>>> It is not the content, I think it is a good catch from Boris, it would
>>>>> be good to document the exported things in somewhere eg.
>>> For the vmcoreinfo variables document, I personally think it might be
>>> not necessary. The reason is that all the old varialbles are exported
>>> with the name of themselves. We know what they are or what they
>>> represent since they are all kernel symbols or macro. Only this me_mask,
>>> it's a local variable and store the value of sme_me_mask for now, may
>>> store more info later like Petr mentioned, and also will store the memory
>>> encryption information of TME (which is intel's transparent memory encryption).
>>> We can add code comment around to tell these.
>> Thank you, everyone.
>> I personally agree with Baoquan's opinion. What do you think about? Boris and other reviewer?
>> If the vmcoreinfo document is necessary, would you like to help me to provide an outline?
>> I can try my best to write the document.
> It is true like what Baoquan said, these information are mainly used by
> makedumpfile tool for creating a filtered vmcore. But these vmcoreinfo
> hide in a lot of different code paths:
> kernel/crash_core.c, printk code, arch code etc.
> It is a mist only a few kdump people know them, documenting them will help
> people to understand and review. It will also be clearer instead of
> digging into code?
> The document can briefly explain what is vmcoreinfo, why we need it, and
> some background info. Then list the exported values with some
> classifying by core kernel, arch related, string or number etc. For
> most of them like Baoquan said no need more explanation, but add
> explanations for something if needed like this sme mask.
> But I think this can be done separately instead of blocking this patch.
For this patch, i think that it had been reached an agreement. So i will
update my patch log and post v2 if there is no objection.
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 4c8acdfdc5a7..ca9bdf46b8e7 100644
@@ -352,10 +352,23 @@ void machine_kexec(struct kimage *image)
+ u64 sme_mask = sme_me_mask;
+ * Currently, the local variable 'sme_mask' stores the value of
+ * sme_me_mask(bit 47), and also write the value of sme_mask to
+ * the vmcoreinfo.
+ * If need, the bit(sme_mask) might be redefined in the future.
+ * For example:
+ * [ misc ][ enc bit ][ other misc SME info ]
+ * 0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000
+ * 63 59 55 51 47 43 39 35 31 27 ... 3
> Maybe Kazu knows more about it, so I would like to ask Kazu about his opinion
> and if he want to do it.
> Ok, thank you, Dave Young.
About the vmcoreinfo document issue, once make a decision, i will try my best to
do this based on your outline.
>> Anyway, we should make a choice.
>>> Personal opinion.