On Tue, Jan 22, 2019 at 11:32:41AM +0800, Chao Fan wrote:
> But I notice the only function call entry is in kaslr.c which needs
> RANDOMIZE_BASE, so do I need change it as:
> vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/acpi.o
Well, the very first patch in this thread doesn't have anything to d
On Mon, Jan 21, 2019 at 04:43:52PM +0800, Chao Fan wrote:
> Since I didn't see where Xen to fill the value, if
> boot_params->acpi_rsdp_addr is filled before my code, I just need to
> read it. If when I try to read it but not found, then parse RSDP and
> fill the RSDP address to boot_params->acpi_r
On Mon, Jan 21, 2019 at 09:18:30AM +0800, Chao Fan wrote:
> So I have changed as this method and put in my mail thread, you may not
> notice, so I put here for my function if I need to fill the
> boot_parameters:
>
> static inline acpi_physical_address get_boot_params_rsdp(void)
> {
> retu
On Fri, Jan 18, 2019 at 07:13:09PM +0800, Kairui Song wrote:
> Currently we have acpi_os_get_root_pointer as the universal function
> to get RSDP address. But the function itself and some functions it
> depends on are in .init section and make it not easy to retrieve the
> RSDP value once kernel is
On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
> How about we refill the boot_params.acpi_rsdp_addr if it is not valid
> in early code, so it could be used as a reliable RSDP address source?
> That should make things easier.
>
> But if early code should parse it and store it should b
On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> I didn't see a way to reuse things in that patch series, situation is
> different, in that patch it needs to get RSDP in very early boot stage
> so it did everything from scratch, in this patch kexec_file_load need
> to get RSDP too, bu
On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> When efi=noruntime or efi=oldmap is used, EFI services won't be available
> in the second kernel, therefore the second kernel will not be able to get
> the ACPI RSDP address from firmware by calling EFI services and won't
> boot. Previo
On Mon, Jan 14, 2019 at 03:49:14PM -0500, Dave Anderson wrote:
> Yeah, I've been watching the thread, and the document looks fine to me.
> It's just that when I saw the discussion of this one being removed that
> I felt the need to respond... ;-)
Good. :-)
Ok, I've amended the init_uts_ns.name.r
On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> No. It needs *both* the vmlinux file and the vmcore file in order to read
> kernel
> virtual memory, so just having a kernel virtual address is insufficient.
>
> So it's a chicken-and-egg situation. This particular --osrelease opt
On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> pulls out the OSRELEASE string from it, so that a user can determine what
> vmlinux file should be used with that vmcore for normal crash analysis.
And th
On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> There's no reading of the dumpfile's memory involved, and that being the case,
> the vmlinux file is not utilized. That's the whole point of the crash
> option, i.e.,
> taking a vmcore file, and trying to determine what kernel shoul
On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> Preferably it would be left as-is. The crash utility has a "crash
> --osrelease vmcore"
> option that only looks at the dumpfile header, and just dump the string.
> With respect
> to compressed kdumps, crash could alternatively lo
On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> As for makedumpfile, it will be not impossible to remove the
> init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> Because historically OSRELEASE has been a kind of a mandatory entry
> in vmcoreinfo from the beginning o
On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
> I noticed that the checkpatch was coded in Perl. But i am not familiar with
> the Perl program language, that would be beyond my ability to do this, i have
> to learn the Perl program language step by step. :-)
You could give it a try - it
On Mon, Jan 14, 2019 at 09:52:14AM +0800, lijiang wrote:
> I would like to remove this variable and post again.
No, you should remove the vmcoreinfo export too:
kernel/crash_core.c:398:VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
after making sure userspace is not using it and *then*
On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people who do not know the vmcoreinfo.
>
> Suggested-by:
On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
> +init_uts_ns.name.release
> +
> +
> +The version of the Linux kernel. Used to find the corresponding source
> +code from which the kernel has been built.
> +
...
> +
> +init_uts_ns
> +---
> +
> +This i
On Tue, Dec 18, 2018 at 03:31:32PM +0800, lijiang wrote:
> The printk_log is used to output human readable text, it will encapsulate
> header
> information for log_buf, such as timestamp, syslog level, etc.
Me asking those questions is supposed to hint that the explanations need
improvement. But
On Sun, Dec 16, 2018 at 09:16:17PM +0800, Lianbo Jiang wrote:
> For AMD machine with SME feature, makedumpfile tools need to know
> whether the crash kernel was encrypted or not. If SME is enabled
> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
> contains the memory encryption
On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
> +clear_idx
> +=
> +The index that the next printk record to read after the last 'clear'
> +command. It indicates the first record after the last SYSLOG_ACTION
> +_CLEAR, like issued by 'dmesg -c'.
What is that used for by the
On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
This...
> +node_online_map
> +===
> +It is a macro definition, actually it is an array node_states[N_ONLINE],
> +and it represents the set of online node in a system, one bit position
> +per node number.
> +
> +This is used
On Sun, Dec 16, 2018 at 09:16:15PM +0800, Lianbo Jiang wrote:
> This patchset did two things:
> a. add a new document for vmcoreinfo
>
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people
On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
> +
> +Common variables
> +
> +
> +init_uts_ns.name.release
> +
> +The number of OS release. Based on this version number, people can find
> +the source code for the corresponding v
On Wed, Dec 05, 2018 at 08:29:14PM +, Kazuhito Hagio wrote:
> Please note that this VMCOREINFO is generated from the information in
> the vmlinux only, not from the running kernel and /proc/kcore. So if
> we add a command to dump it from running kernel, it's not suitable.
Sure, I used a vmlinu
On Fri, Nov 30, 2018 at 03:04:44PM +0800, lijiang wrote:
> I have noticed the changes on x86, but for IA64, i'm not sure whether it
> should do the same
> thing, so keep it as before.
>
> If IA64 people would like to give any comment, that will be appreciated.
I think you should not touch ia64 a
On Tue, Dec 04, 2018 at 05:35:09PM +0800, lijiang wrote:
> There are more people to review and improve this document together, that would
> be fine.
That's basically kernel development :)
> Generating VMCOREINFO is easy in the first kernel, for example:
> # makedumpfile -g VMCOREINFO -x vmlinux
d it also normalizes the
> exported variable as a standard ABI between kernel and use-space.
Yeah, I'm not sure about it being an ABI. Apparently, it is considered
too tightly coupled to the kernel for it to be an ABI.
Regardless, thanks for doing that.
> Suggested-by: Borislav Petkov
> Sign
On Mon, Nov 26, 2018 at 09:44:46AM -0800, Dave Hansen wrote:
> On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> > These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
> > for the iomem resources search interfaces, and in order to make it still
> > work after the new descriptor is added
On Tue, Nov 20, 2018 at 02:43:57PM -0600, Bjorn Helgaas wrote:
> MMCONFIG (aka ECAM) space is described in the ACPI MCFG table. The
> generic code to read that is in drivers/acpi/pci_mcfg.c (ignore all
> the quirks at the top) and the generic code to use it is
> drivers/pci/ecam.c.
/me saves that
+ Kees.
On Fri, Nov 16, 2018 at 03:17:49AM +0530, Bhupesh Sharma wrote:
> x86_64 kernel uses 'page_offset_base' variable to point to the
> start of direct mapping of all physical memory. This variable
> is also updated for KASLR boot cases, so this can be exported
> via vmcoreinfo as a standard AB
On Tue, Nov 20, 2018 at 11:37:26AM +0800, lijiang wrote:
> BTW: Boris has mentioned the solution which adds the new descriptor
> 'IORES_DESC_RESERVED'.
>
> Which solution do you prefer? Add the new I/O resource descriptor
> 'IORES_DESC_RESERVED'(patch v7)
> or exactly comparing a string(patch v6
On Mon, Nov 19, 2018 at 05:55:15PM +0800, Dave Young wrote:
> Another thing is it is not worth to get the exact info, the 1st kernel
> reserved part is just fine to be reserved as well in 2nd kernel, no
> side effects. Actually there might be some obscure use cases we
> do not find which rely tho
On Fri, Nov 16, 2018 at 11:25:55AM +0800, lijiang wrote:
> For the pci mmconfig issue, it should be good enough that the e820 reserved
> region
> [mem 0x7800-0x8fff] is only passed to the second
> kernel, but
> the pci mmconfig region is not the same in another machine.
Y
+ Bjorn.
On Thu, Nov 15, 2018 at 01:44:07PM +0800, lijiang wrote:
> At present, the upstream kernel does not pass the e820 reserved ranges to the
> second kernel, which might cause two problems:
>
> The first one is the MMCONFIG issue, the PCI MMCONFIG(extended mode) requires
> the reserved regio
On Wed, Nov 14, 2018 at 03:29:25PM +0800, Lianbo Jiang wrote:
> When load the kernel image and initramfs by kexec_file_load syscall, it can
> not add exact e820 reserved type to kdump kernel e820 table.
>
> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds matched
> desc to e820
On Wed, Oct 31, 2018 at 10:47:48AM +0800, Dave Young wrote:
> 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?
Wholeheartedly agreed. Especially if people start using vmcoreinfo for
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.
> Documentation/kdump/vmcoreinfo.txt
Yes.
--
Regards/Gruss,
Boris.
Good mailing practices for 400:
On Mon, Oct 29, 2018 at 09:41:26PM +0800, lijiang wrote:
> > VMCOREINFO_NUMBER(phys_base);
> > VMCOREINFO_SYMBOL(init_top_pgt);
> > vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n",
> > pgtable_l5_enabled());
> >
> > + VMCOREINFO_NUMBER(
On Mon, Oct 29, 2018 at 05:29:16PM +0800, lijiang wrote:
> Ok, i will change it to a local variable and export it.
Why do you have to export it at all?!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
__
On Sat, Oct 27, 2018 at 10:41:56PM +0800, lijiang wrote:
> Actually, the value of 'sme_me_mask' is 0x8000 when SME is
> enabled, otherwise it is 0. That is to say, if the bit 47 is set, the
> bit number is also 0x8000 (1 << 47UL);
Yes, and you can simply copy the mask into your var
On Sat, Oct 27, 2018 at 05:39:17PM +0800, Baoquan He wrote:
> Not very sure about this, we have arch_crash_save_vmcoreinfo() in
> arch/x86/kernel/machine_kexec_64.c to export arch-specific stuffs
> outside. Is there any special reason about a mask in one architecture
> when expose it out?
Yes, we
On Sat, Oct 27, 2018 at 04:13:43PM +0800, Baoquan He wrote:
> Yes, agree. So sme_me_mask itself or the encryption bit number, both is
> fine.
You need the encryption bit position and it better be properly formatted
and extracted into a vmcoreinfo-specific variable because we don't
expose arch-spec
On Fri, Oct 26, 2018 at 06:24:40PM +0200, Petr Tesarik wrote:
> But we need the MSR value from the panic kernel environment, not while
> the production kernel is still running, right?
Actually, we need only the encryption bit number (and it should be 0
otherwise to denote SME wasn't enabled).
I g
On Fri, Oct 26, 2018 at 08:32:11PM +0800, lijiang wrote:
> If SME is enabled in the first kernel, the crash kernel's page
> table(pgd/pud/pmd/pte)
> contains the memory encryption mask, so i have to remove the sme mask to
> obtain the
> true physical address when dump vmcore.
Sorry, I have no cl
On Mon, Oct 15, 2018 at 12:51:38PM +0800, Dave Young wrote:
> > Since the fix of checking the end is in another patch, probably merge
> > these two patches so that they are in one patch to avoid break bisect.
>
> Not sure if above comment was missed, Boris, would you mind to fold the
> patch 1 an
On Tue, Oct 09, 2018 at 12:30:33PM -0500, Bjorn Helgaas wrote:
> Sorry, I don't know what happened here because I didn't see these
> comments until today. I suspect what happened was that my Gmail
> filter auto-filed them in my linux-kernel folder, which I don't read.
> On my @google.com account,
On Fri, Oct 05, 2018 at 01:52:26PM +0800, lijiang wrote:
> b. add the parameter "mem_encrypt=on" for kernel command-line to
> grub.cfg, if
> this machine has SME feature. And also add crashkernel=xx, which will
> reserve
> memory for kdump.
Ok, I'm doing the simpler crashker
On Thu, Oct 04, 2018 at 05:33:14PM +0800, lijiang wrote:
> I have tested the patch again based on upstream 4.19.0-rc6, it works very
> well.
How have you tested this?
Please describe the steps in detail.
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
On Wed, Oct 03, 2018 at 11:57:59AM +0800, lijiang wrote:
> I noticed that your test was based on [patch v8 RESEND 4/4],
How did you notice that?
Let's see, the patch in question is this one:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/commit/?h=rc6%2b0-sme-kdump&id=4a0f2adf6cf374ed
On Sun, Sep 30, 2018 at 11:10:29AM +0800, Lianbo Jiang wrote:
> When SME is enabled on AMD machine, it also needs to support kdump. Because
Ok, I've cleaned them up heavily and pushed them here:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch
rc6+0-sme-kdump
However, testing o
On Sun, Sep 30, 2018 at 04:37:41PM +0800, lijiang wrote:
> In kdump kernel, the old memory needs to be dumped into vmcore file.
> If SME is enabled in the first kernel, the old memory has to be
> remapped with the memory encryption mask, which will be automatically
> decrypted when read from DRAM.
On Fri, Sep 28, 2018 at 06:09:04PM +0800, lijiang wrote:
> But there are another cases, we might load or unload the crash kernel image
> and
> initrafms, maybe again and again for test or debug, we don't reboot at once.
> For
I don't think this qualifies even as a use case - this is what you do
On Sat, Sep 29, 2018 at 02:24:52PM +0800, lijiang wrote:
> At first, i added an input parameter for read_from_oldmem() because of
> encryption(SME). But
> for avoiding to also add the same parameter for copy_oldmem_page(), so i
> added a new function
> copy_oldmem_page_encrypted(). Maybe you had
u64 end, void *arg,
> int (*func)(struct resource *, void *))
> {
> - struct resource res;
> -
> - res.start = start;
> - res.end = end;
> - res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + unsigned long flags = IOR
don't see in practice.
This is how one should write commit messages! Thanks for that - it was a
joy - for a change - to read it :-)
>
> Fixes: 58c1b5b07907 ("[PATCH] memory hotadd fixes: find_next_system_ram catch
> range fix")
> Signed-off-by: Bjorn Helgaas
> --
640K */
> +#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
>
> /*
> * CPU does not save ss and sp on stack if execution is already
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard
On Thu, Sep 27, 2018 at 09:03:51AM -0500, Bjorn Helgaas wrote:
> Since I think the current interface (using *res as both input and
> output parameters that have very different meanings) is confusing,
FTR, I too, think that this whole machinery in resource.c with passing
in a function and a struct
On Thu, Sep 27, 2018 at 03:19:54PM +0800, Lianbo Jiang wrote:
> In kdump kernel, we need to dump the old memory into vmcore file,if SME
> is enabled in the first kernel, we have to remap the old memory with the
> memory encryption mask, which will be automatically decrypted when we
> read from DRAM
On Fri, Sep 28, 2018 at 11:52:21AM +0800, lijiang wrote:
> There are two functions that are usually called in pairs, they are:
> arch_kexec_post_alloc_pages() and arch_kexec_pre_free_pages().
>
> One marks the pages as decrypted, another one marks the pages as encrypted.
>
> But for the crash con
On Thu, Sep 27, 2018 at 03:19:52PM +0800, Lianbo Jiang wrote:
> When SME is enabled in the first kernel, we will allocate unencrypted pages
> for kdump in order to be able to boot the kdump kernel like kexec.
This is not what the commit does - it marks the control pages as
decrypted when SME. Why
On Thu, Sep 27, 2018 at 10:53:47PM +0800, lijiang wrote:
> If no need to break this line, it will cause a warning of exceeding 80
> characters per line.
That's fine - we don't take the 80 cols rule blindly but apply common
sense. In this particular case the lines can stick out because they're
sim
On Thu, Sep 27, 2018 at 03:19:51PM +0800, Lianbo Jiang wrote:
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 6de64840dd22..f8795f9581c7 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -192,6 +192,9 @@ extern void __iomem *ioremap_cache(r
On Wed, Sep 26, 2018 at 01:01:00PM +, Lendacky, Thomas wrote:
> No concern from me. The original version of the patch did not cache the
> value, that was added based on the patch series feedback. So, if there
> is no concern about executing some extra CPUID/RDMSR instructions, then
> it would
On Tue, Sep 25, 2018 at 02:33:48PM +, Lendacky, Thomas wrote:
> On 09/25/2018 06:10 AM, Kairui Song wrote:
> > Commit 1958b5fc4010 ("x86/boot: Add early boot support when running
> > with SEV active") is causing kexec becomes sometimes unstable, kexec
> > reboot won't start a second kernel bypa
On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:
...
> In fact, we should get the resource A and B when we walk through the
> whole tree, but it only gets the resource A, the resource B is missed.
>
> Signed-off-by: Dave Young
> Signed-off-by: Lianbo Jiang
Before looking at this:
On Thu, Aug 16, 2018 at 01:35:28PM +0800, lijiang wrote:
> I personally prefer solution A, which is presented in posted patches.
> What do you think, Boris? And other reviewers?
Ok, thanks for taking the time and effort in explaning this in detail.
Solution B really turns out to be too complex af
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,
On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote:
> About this issue, i want to use an example to describe it.
> /* drivers/iommu/amd_iommu_init.c */
> static u8 __iomem * __init iommu_map_mmio_space(u64 address, u64 end)
Those addresses come from the IVHD header which is an ACPI table. So
On Mon, Jul 09, 2018 at 02:28:11PM +0800, lijiang wrote:
> Last week, I had tried many ways to do this work, but it looks
> like that the ways of deducing address is not suitable to another
> scenarios, such as mapping some devices mmio space, which are
> unencrypted, and the device mmio space is o
On Tue, Jul 03, 2018 at 06:58:14PM +0800, lijiang wrote:
> For kdump, the elf header finally use the crash kernel reserved memory, it is
> not an old memory.
Lamme repeat my suggestion:
So beef up the logic in __ioremap_caller() to figure out based on the
address whether to access the memory enc
On Tue, Jul 03, 2018 at 10:17:19AM +0800, lijiang wrote:
> for example, the elfcorehdr. In fact, the elfcorehdr and notes
You mean this?
ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
{
- return read_from_oldmem(buf, count, ppos, 0);
+ return read_from_oldm
On Mon, Jul 02, 2018 at 03:26:35PM +0800, Lianbo Jiang wrote:
> @@ -131,7 +132,8 @@ static void __ioremap_check_mem(resource_size_t addr,
> unsigned long size,
> * caller shouldn't need to know that small detail.
> */
> static void __iomem *__ioremap_caller(resource_size_t phys_addr,
> -
On Sat, Dec 16, 2017 at 09:01:42AM +0800, Baoquan He wrote:
> 2) If firmware is broken, you can't enable gart in firmware, will
> firmware engineer fix this since it's a firmware bug?
Slow down and get a reality check first please!
A firmware engineer will fix a 10yr old BIOS?!? Yeah right. And I
On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote:
> > If I make the scattered feature support conditional on CONFIG_X86_64
> > (based on comment below) then cpu_has() will always be false unless
> > CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
> > #ifdef.
>
> If you
On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
> Normally the __p4d() macro would be used and that would be ok whether
> CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
> paravirt ops path I have to use native_make_p4d().
So __p4d is in !CONFIG_PARAVIRT path.
On Fri, Jun 16, 2017 at 01:56:39PM -0500, Tom Lendacky wrote:
> Add support to check if SME has been enabled and if memory encryption
> should be activated (checking of command line option based on the
> configuration of the default state). If memory encryption is to be
> activated, then the encry
turned, with -1 indicating not found.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cmdline.h |2 +
> arch/x86/lib/cmdline.c | 105
>
> 2 files changed, 107 insertions(+)
Reviewed-by: Borislav Petkov
--
On Fri, Jun 16, 2017 at 01:56:19PM -0500, Tom Lendacky wrote:
> Add the support to encrypt the kernel in-place. This is done by creating
> new page mappings for the kernel - a decrypted write-protected mapping
> and an encrypted mapping. The kernel is encrypted by copying it through
> a temporary b
io.h |3 +++
> arch/x86/mm/ioremap.c | 18 +-
> arch/x86/mm/pat.c |3 +++
> 3 files changed, 15 insertions(+), 9 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_
ities(void)
> setup_clear_cpu_cap(X86_FEATURE_MTRR);
> setup_clear_cpu_cap(X86_FEATURE_ACC);
> setup_clear_cpu_cap(X86_FEATURE_X2APIC);
> + setup_clear_cpu_cap(X86_FEATURE_SME);
>
> if (!xen_initial_domain())
> setup_clear_cpu_cap(X86_FEAT
void *vaddr, unsigned int pages,
gfp_t gfp) { return 0; }
static inline void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages) {
}
Other than that:
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
+++
> drivers/iommu/amd_iommu_types.h |2 +-
> 4 files changed, 55 insertions(+), 21 deletions(-)
Reviewed-by: Borislav Petkov
Btw, I'm assuming the virt_to_phys() difference on SME systems is only
needed in a handful of places. Otherwise, I'd suggest changing the
virt_to_p
t;
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/kernel/cpu/amd.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-po
On Wed, Jun 21, 2017 at 05:37:22PM +0200, Joerg Roedel wrote:
> > Do you mean this is like the last exception case in that document above:
> >
> > "
> > - Pointers to data structures in coherent memory which might be modified
> > by I/O devices can, sometimes, legitimately be volatile. A ri
On Fri, Jun 16, 2017 at 01:54:36PM -0500, Tom Lendacky wrote:
> Add warnings to let the user know when bounce buffers are being used for
> DMA when SME is active. Since the bounce buffers are not in encrypted
> memory, these notifications are to allow the user to determine some
> appropriate actio
gt; with the memory encryption mask.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/realmode/init.c |8
> 1 file changed, 8 insertions(+)
Subject: x86/realmode: ...
other than that:
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices
> lib/swiotlb.c | 54
> +++-
> 9 files changed, 108 insertions(+), 17 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
---
> 1 file changed, 70 insertions(+), 28 deletions(-)
Reviewed-by: Borislav Petkov
Please put the conversion to pr_fmt() on the TODO list for later.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_
On Wed, Jun 21, 2017 at 09:18:59AM +0200, Thomas Gleixner wrote:
> That looks wrong. It's not decrypted it's rather unencrypted, right?
Yeah, it previous versions of the patchset, "decrypted" and
"unencrypted" were both present so we settled on "decrypted" for the
nomenclature.
--
Regards/Gruss,
clude/asm/io.h |5 +
> arch/x86/mm/ioremap.c | 179
> +
> include/linux/io.h|2 +
> kernel/memremap.c | 20 -
> mm/early_ioremap.c| 18 -
> 5 files changed, 217 insertions(+), 7 deletio
On Fri, Jun 16, 2017 at 01:52:32PM -0500, Tom Lendacky wrote:
> The boot data and command line data are present in memory in a decrypted
> state and are copied early in the boot process. The early page fault
> support will map these areas as encrypted, so before attempting to copy
> them, add decr
ssor.h |5 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
kexec mailing list
kexec@lists.i
def CONFIG_AMD_MEM_ENCRYPT
>
> /*
> * Since SME related variables are set early in the boot process they must
> @@ -19,3 +22,24 @@
> */
> unsigned long sme_me_mask __section(.data) = 0;
> EXPORT_SYMBOL_GPL(sme_me_mask);
> +
> +void __init sme_encrypt_kernel(void)
>
ware/pcdp.c |4 ++--
> drivers/sfi/sfi_core.c | 22 +++---
> 9 files changed, 55 insertions(+), 66 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Thu, Jun 15, 2017 at 11:33:41AM -0500, Tom Lendacky wrote:
> Changing the signature back reverts to the original way, so this can be
> looked at separate from this patchset then.
Right, the patch which added the volatile thing was this one:
4bf5beef578e ("iommu/amd: Don't put completion-wait
On Thu, Jun 15, 2017 at 09:59:45AM -0500, Tom Lendacky wrote:
> Actually the detection routine, amd_iommu_detect(), is part of the
> IOMMU_INIT_FINISH macro support which is called early through mm_init()
> from start_kernel() and that routine is called before init_amd().
Ah, we do that there too:
On Wed, Jun 07, 2017 at 02:18:27PM -0500, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
>
> Support is needed to allocate pages for kexec without encryption. This
> is needed in order to be able to reboot in the kernel in the same manner
>
|2 +-
> arch/x86/kvm/svm.c | 35 ++-
> arch/x86/kvm/vmx.c |3 ++-
> arch/x86/kvm/x86.c |3 ++-
> 6 files changed, 32 insertions(+), 25 deletions(-)
Patches 27-29:
Reviewed-by: Borislav Petkov
--
Regards/Grus
On Wed, Jun 14, 2017 at 03:40:28PM -0500, Tom Lendacky wrote:
> I was trying to keep all the logic for it here in the SME related files
> rather than put it in the iommu code itself. But it is easy enough to
> move if you think it's worth it.
Yes please - the less needlessly global symbols, the be
On Wed, Jun 14, 2017 at 02:49:02PM -0500, Tom Lendacky wrote:
> I guess I don't need the sme_active() check since the second part of the
> if statement can only ever be true if SME is active (since mask is
> unsigned).
... and you can define sme_me_mask as an u64 directly (it is that already,
prac
301 - 400 of 632 matches
Mail list logo
