Hi all,
gcc has a warning option
-Wmissing-prototypes
which fires when a global function is missing a prototype declaration.
This warning is important as it catches cases when that global
function's prototype has been changed but its callers haven't been
updated. And they should be.
Currently
On Thu, Nov 15, 2018 at 02:19:23PM +0800, Dave Young wrote:
> It would be good to copy some background info from cover letter to the
> patch description so that we can get better understanding why this is
> needed now.
>
> BTW, Lianbo is working on a documentation of the vmcoreinfo exported
> fiel
On Thu, Nov 15, 2018 at 12:20:40PM +0100, David Hildenbrand wrote:
> Sorry to say, but that is the current practice without which
> makedumpfile would not be able to work at all. (exclude user pages,
> exclude page cache, exclude buddy pages). Let's not reinvent the wheel
> here. This is how dumpin
On Thu, Nov 15, 2018 at 01:11:02PM +0100, Michal Hocko wrote:
> I am not familiar with kexec to judge this particular patch but we
> cannot simply define any range for these pages (same as for hwpoison
> ones) because they can be almost anywhere in the available memory range.
> Then there can be co
On Thu, Nov 15, 2018 at 01:01:17PM +0100, David Hildenbrand wrote:
> Just saying that "I'm not the first to do it, don't hit me with a stick" :)
:-)
> Indeed. And we still have without makedumpfile. I think you are aware of
> this, but I'll explain it just for consistency: PG_hwpoison
No, I appr
On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote:
> The first three patches are the changes under x86/acrn, which adds the
> required APIs for the driver and reports the X2APIC caps.
> The remaining patches add the ACRN driver module, which accepts the ioctl
> from user-space and then co
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote:
> Not sure whether it can be sent in two patch sets?
> The first is to add the required APIs for ACRN driver.
> The second is to add the ACRN driver
One patchset adding the APIs and its user(s).
And make sure to refresh on
https://www.
On Mon, Aug 19, 2019 at 10:39:58AM +0300, Dan Carpenter wrote:
> On Mon, Aug 19, 2019 at 01:32:54PM +0800, Zhao, Yakui wrote:
> > In fact as this driver is mainly used for embedded IOT usage, it doesn't
> > handle the complex cleanup when such error is encountered. Instead the clean
> > up is handl
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Update the CPU features to include identifying and reporting on the
> Secure Encrypted Virtualization (SEV) feature. SME is identified by
> CPUID 0x801f, but requires BIOS support to enable it (set bit 23
On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> > This RFC series provides support for AMD's new Secure Encrypted
> > Virtualization
> > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4
> >
On Fri, Mar 03, 2017 at 03:01:23PM -0600, Brijesh Singh wrote:
> +merely enables SME (sets bit 23 of the MSR_K8_SYSCFG), then Linux can
> activate
> +memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y)
> or
> +by supplying mem_encrypt=on on the kernel command line. However, i
On Mon, Mar 06, 2017 at 01:11:03PM -0500, Brijesh Singh wrote:
> Sending it through stg mail to avoid line wrapping. Please let me know if
> something
> is still messed up. I have tried applying it and it seems to apply okay.
Yep, thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix
On Thu, Mar 02, 2017 at 10:12:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Define a new KVM CPU feature for Secure Encrypted Virtualization (SEV).
> The kernel will check for the presence of this feature to determine if
> it is running with SEV active.
>
> Define the SEV enable bit
On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as
> EFI related data, setup data) is encrypted and needs to be accessed as
> such when mapped. Update the architecture override in early_m
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Provide support for Secure Encyrpted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
>
> Signed-off-by: Tom Lendacky
B
On Thu, Mar 02, 2017 at 10:13:21AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> EFI data is encrypted when the kernel is run under SEV. Update the
> page table references to be sure the EFI memory areas are accessed
> encrypted.
>
> Signed-off-by: Tom Lendacky
> Signed-off-by: Brijesh S
On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> In order for memory pages to be properly mapped when SEV is active, we
> need to use the PAGE_KERNEL protection attribute as the base protection.
> This will insure that memory mapping of, e.g. ACPI tables, re
On Thu, Mar 02, 2017 at 10:13:53AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> In order to map BOOT data with the proper encryption bit, the
Btw, what does that all-caps spelling "BOOT" denote? Something I'm
missing?
> early_ioremap() function calls are changed to early_memremap() call
On Thu, Mar 02, 2017 at 10:14:25AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> DMA access to memory mapped as encrypted while SEV is active can not be
> encrypted during device write or decrypted during device read. In order
> for DMA to properly work when SEV is active, the swiotlb boun
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Provide support for Secure Encyrpted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
>
> Signed-off-by: Tom Lendacky
>
On Thu, Mar 02, 2017 at 10:14:48AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Early in the boot process, add checks to determine if the kernel is
> running with Secure Encrypted Virtualization (SEV) active by issuing
> a CPUID instruction.
>
> During early compressed kernel booting, if
On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
> This is not how you check if running under a hypervisor; you should
> check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx. This in turn
> tells you if leaf 0x4000 is valid.
Ah, good point, I already do that in the microcode lo
On Thu, Mar 02, 2017 at 10:15:01AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Modify the SVM cpuid update function to indicate if Secure Encrypted
> Virtualization (SEV) is active in the guest by setting the SEV KVM CPU
> features bit. SEV is active if Secure Memory Encryption is enable
On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
> If kernel_maps_pages_in_pgd is called early in boot process to change the
kernel_map_pages_in_pgd()
> memory attributes then it fails to allocate memory when spliting large
> pages. The patch extends the cpa_data to provide the supp
On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote:
> We could update this patch to use the below logic:
>
> * CPUID(0) - Check for AuthenticAMD
> * CPID(1) - Check if under hypervisor
> * CPUID(0x8000) - Check for highest supported leaf
> * CPUID(0x801F).EAX - Check for SME
On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote:
> Because there are differences between how SME and SEV behave
> (instruction fetches are always decrypted under SEV, DMA to an
> encrypted location is not supported under SEV, etc.) we need to
> determine which mode we are in so that th
On Thu, Mar 16, 2017 at 11:11:26AM -0500, Tom Lendacky wrote:
> Not quite. The guest still needs to understand about the encryption mask
> so that it can protect memory by setting the encryption mask in the
> pagetable entries. It can also decide when to share memory with the
> hypervisor by not s
On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote:
> I can take a look at fixing those warning. In my initial attempt was to create
> a new function to clear encryption bit but it ended up looking very similar to
> __change_page_attr_set_clr() hence decided to extend the exiting functio
On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote:
> The kvmclock memory is initially zero so there is no need for the
> hypervisor to allocate anything; the point of these patches is just to
> access the data in a natural way from Linux source code.
I realize that.
> I also don't rea
On Fri, Mar 17, 2017 at 11:47:16AM +0100, Paolo Bonzini wrote:
> Theoretically or practically?
In the sense, it needs to be tried first to see how ugly it can get.
> It only looks at the E820 map, doesn't it? Why does it have to do
> anything with percpu memory areas?
That's irrelevant. What we
On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote:
> If it is possible to do it in a fairly hypervisor-independent manner,
> I'm all for it. That is, only by looking at AMD-specified CPUID leaves
> and at kernel ELF sections.
Not even that.
What that needs to be able to do is:
On Fri, Mar 17, 2017 at 03:45:26PM +0100, Paolo Bonzini wrote:
> Yes, and I'd like that to be done with a new data section rather than a
> special KVM hook.
Can you give more details about how pls? Or is there already an example for that
somewhere in the kvm code?
> I have no idea. SEV-ES seems
On Thu, Mar 02, 2017 at 10:15:28AM -0500, Brijesh Singh wrote:
> Some KVM-specific custom MSRs shares the guest physical address with
> hypervisor. When SEV is active, the shared physical address must be mapped
> with encryption attribute cleared so that both hypervsior and guest can
> access the d
On Thu, Mar 02, 2017 at 10:15:36AM -0500, Brijesh Singh wrote:
> Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU
> variable at compile time and share its physical address with hypervisor.
> It presents a challege when SEV is active in guest OS. When SEV is active,
> guest
ich memory address was translated into EXITINFO2.
>
> Signed-off-by: Tom Lendacky
> Reviewed-by: Borislav Petkov
I think I already asked you to remove Revewed-by tags when you have to
change an already reviewed patch in non-trivial manner. Why does this
one still have my Reviewed-by tag?
--
On Wed, Mar 29, 2017 at 05:21:13PM +0200, Paolo Bonzini wrote:
> The GHCB would have to be allocated much earlier, possibly even by
> firmware depending on how things will be designed.
How about a statically allocated page like we do with the early
pagetable pages in head_64.S?
> I think it's pre
Hi Brijesh,
On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote:
> I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains
> routines to do basic page splitting. I think it sufficient for our usage.
Good :)
> I should be able to drop the memblock patch from the se
On Thu, Apr 06, 2017 at 01:37:41PM -0500, Brijesh Singh wrote:
> I did thought about prot idea but ran into another corner case which may
> require
> us changing the signature of phys_pud_init and phys_pmd_init. The paddr_start
> and paddr_end args into kernel_physical_mapping_init() should be ali
On Fri, Apr 21, 2017 at 11:22:31PM +0200, Rafael J. Wysocki wrote:
> > #ifdef CONFIG_ACPI_APEI_PCIEAER
> > - else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> > - CPER_SEC_PCIE)) {
> > + else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {
On Thu, Apr 27, 2017 at 04:09:56PM +0300, Andy Shevchenko wrote:
> Lukas pointed to this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68725
Yap, the same thing.
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/kvm_host.h | 11 ++-
> arch/x86/kvm/mmu.c | 20 ++--
> arch/x86/kvm/svm.c |2 +-
> 3 files changed, 29 insertions(+), 4 deletions(-)
FWIW: Reviewed-by: Boris
t; arch/x86/include/asm/kvm_host.h |1 +
> arch/x86/kvm/svm.c |5 +++--
> arch/x86/kvm/x86.c | 43
> +++
> 3 files changed, 47 insertions(+), 2 deletions(-)
FWIW: Reviewed-by: Borislav Petkov
--
Regards/Gruss,
7 -
> 4 files changed, 24 insertions(+), 1 deletion(-)
FWIW, LGTM. (Gotta love replying in acronyms :-))
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
___
t; 2 files changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
___
devel mailing
On Mon, Aug 22, 2016 at 07:25:25PM -0400, Brijesh Singh wrote:
> From: Tom Lendacky
>
> EFI data is encrypted when the kernel is run under SEV. Update the
> page table references to be sure the EFI memory areas are accessed
> encrypted.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/platform
On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote:
> The main difference between the SME and SEV encryption, from the point
> of view of the kernel, is that real-mode always writes unencrypted in
> SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode
> and learn abou
On Mon, Aug 22, 2016 at 07:24:19PM -0400, Brijesh Singh wrote:
> From: Tom Lendacky
Subject: [RFC PATCH v1 04/28] x86: Secure Encrypted Virtualization (SEV) support
Please start patch commit heading with a verb, i.e.:
"x86: Add AMD Secure Encrypted Virtualization (SEV) support"
--
Regards/Gru
On Thu, Sep 22, 2016 at 05:05:54PM +0200, Paolo Bonzini wrote:
> Which paragraph?
"Linux relies on BIOS to set this bit if BIOS has determined that the
reduction in the physical address space as a result of enabling memory
encryption..."
Basically, you can enable SME in the BIOS and you're all se
On Thu, Sep 22, 2016 at 07:08:50PM +0200, Paolo Bonzini wrote:
> That's not how I read it. I just figured that the BIOS has some magic
> things high in the physical address space and if you reduce the physical
> address space the BIOS (which is called from e.g. EFI runtime services)
> would have p
On Thu, Sep 22, 2016 at 08:23:36PM +0200, Paolo Bonzini wrote:
> Unless this is part of some spec, it's easier if things are the same in
> SME and SEV.
Yeah, I was pondering over how sprinkling sev_active checks might not be
so clean.
I'm wondering if we could make the EFI regions presented to th
On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
> That's not what I mean here. If the BIOS sets the SMEE bit in the
> SYS_CFG msr then, even if the encryption bit is never used, there is
> still a reduction in physical address space.
I thought that reduction is the reservation of bi
On Thu, Sep 22, 2016 at 02:49:22PM -0500, Tom Lendacky wrote:
> > I thought that reduction is the reservation of bits for the SME mask.
> >
> > What other reduction is there?
>
> There is a reduction in physical address space for the SME mask and the
> bits used to aid in identifying the ASID ass
On Fri, Sep 23, 2016 at 09:33:00PM +1200, Kai Huang wrote:
> How is this even possible? The spec clearly says under SEV only in long mode
> or PAE mode guest can control whether memory is encrypted via c-bit, and in
> other modes guest will be always in encrypted mode.
I was suggesting the hypervi
On Sat, Aug 19, 2017 at 01:52:12PM +0530, Bhumika Goyal wrote:
> Make these const as they are only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal
> ---
> drivers/edac/edac_mc_sysfs.c | 8
> drivers/edac/i7core_
Hey Andrew,
can we get this one applied already - I'm seeing this warning at least
since before my summer vacation started! :-P
Thanks.
On Mon, Sep 01, 2014 at 09:55:06AM -0700, Joe Perches wrote:
> There's a useless "+" use that needs to be removed as perl 5.20
> emits a "Useless use of greedin
On Thu, Oct 30, 2014 at 12:12:04PM +0100, Borislav Petkov wrote:
> Hey Andrew,
>
> can we get this one applied already - I'm seeing this warning at least
> since before my summer vacation started! :-P
Oh ok, so it did go in after 3.17 but when using checkpatch on a 3.17
tree, i
56 matches
Mail list logo
