Re: [Xen-devel] [PATCH 08/13] x86/paravirt: Clean up paravirt_types.h

On Wed, Oct 04, 2017 at 10:58:29AM -0500, Josh Poimboeuf wrote: > Make paravirt_types.h more understandable: > > - Use more consistent and logical naming > - Simplify interfaces > - Put related macros together > - Improve whitespace > > Signed-off-by: Josh Poimboeuf > --- >

Re: [Xen-devel] [PATCH 07/13] x86/paravirt: Simplify ____PVOP_CALL()

On Wed, Oct 04, 2017 at 10:58:28AM -0500, Josh Poimboeuf wrote: > Remove the inline asm duplication in PVOP_CALL(). > > Also add 'IS_ENABLED(CONFIG_X86_32)' to the return variable logic, > making the code clearer and rendering the comment unnecessary. > > Signed-off-by: Josh Poimboeuf

Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of

Re: [Xen-devel] [PATCH 01/13] x86/paravirt: remove wbinvd() paravirt interface

iles changed, 1 insertion(+), 17 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()

On Fri, Oct 27, 2017 at 07:25:04PM +0200, Juergen Gross wrote: > >> This is assuming CPU 0 is the boot cpu. I think you want > >> boot_cpu_data.cpu_index here or whatever is used on xen to identify the > >> BSP reliably. > > > > It seems both PV and PVHVM call xen_init_lock_cpu(0) so 0 here is

Re: [Xen-devel] [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

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

Re: [Xen-devel] [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

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.

Re: [Xen-devel] [PATCH v7 36/36] x86/mm: Add support to make use of Secure Memory Encryption

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

Re: [Xen-devel] [PATCH v7 35/36] x86/boot: Add early cmdline parsing for options with arguments

is returned, with -1 indicating not found. > > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/include/asm/cmdline.h |2 + > arch/x86/lib/cmdline.c | 105 > > 2 files changed, 107 insertions(+) Rev

Re: [Xen-devel] [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

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

Re: [Xen-devel] [PATCH v7 33/36] x86/mm: Use proper encryption attributes with /dev/mem

> arch/x86/include/asm/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 <b...@suse.de> -- Regards/Gruss, Bori

Re: [Xen-devel] [PATCH v7 32/36] xen/x86: Remove SME feature in PV guests

static void __init xen_init_capabilities(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()) >

Re: [Xen-devel] [PATCH v7 31/36] x86/mm, kexec: Allow kexec to be used with SME

int arch_kexec_post_alloc_pages(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 <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices f

Re: [Xen-devel] [PATCH v7 27/36] iommu/amd: Allow the AMD IOMMU to work with memory encryption

md_iommu_proto.h | 10 ++ > drivers/iommu/amd_iommu_types.h |2 +- > 4 files changed, 55 insertions(+), 21 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> Btw, I'm assuming the virt_to_phys() difference on SME systems is only needed in a handful of places. Ot

Re: [Xen-devel] [PATCH v7 26/36] x86/CPU/AMD: Make the microcode level available earlier in the boot

t; > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/kernel/cpu/amd.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: [Xen-devel] [PATCH v7 25/36] swiotlb: Add warnings for use of bounce buffers with SME

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

Re: [Xen-devel] [PATCH v7 24/36] x86, swiotlb: Add memory encryption support

++ > lib/swiotlb.c | 54 > +++- > 9 files changed, 108 insertions(+), 17 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [Xen-devel] [PATCH v7 23/36] x86, realmode: Decrypt trampoline area if memory encryption is active

addresses > with the memory encryption mask. > > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > arch/x86/realmode/init.c |8 > 1 file changed, 8 insertions(+) Subject: x86/realmode: ... other than that: Reviewed-by: Borislav Petkov <b...@suse.de> --

Re: [Xen-devel] [PATCH v7 20/36] x86, mpparse: Use memremap to map the mpf and mpc data

t; arch/x86/kernel/mpparse.c | 98 > - > 1 file changed, 70 insertions(+), 28 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> Please put the conversion to pr_fmt() on the TODO list for later. Thanks. -- Regards/Gruss, Boris. Good mailing practic

Re: [Xen-devel] [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

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

[Xen-devel] [PATCH] x86/MCE, xen/mcelog: Make /dev/mcelog registration messages more precise

[ Massage a bit. ] Signed-off-by: Borislav Petkov <b...@suse.de> --- arch/x86/kernel/cpu/mcheck/dev-mcelog.c | 8 +++- drivers/xen/mcelog.c| 2 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/mcheck/dev-mcelog.c b/arch/x86/kernel/cpu/mc

Re: [Xen-devel] [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear

om> > --- > arch/x86/include/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 cha

Re: [Xen-devel] [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly

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

Re: [Xen-devel] [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

++- > arch/x86/include/asm/processor.h |5 + > 2 files changed, 7 insertions(+), 1 deletion(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. _

Re: [Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

__init sme_encrypt_kernel(void) > +{ > +} Just the minor: void __init sme_encrypt_kernel(void) { } in case you have to respin. Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

sfs.c |5 +++-- > drivers/firmware/pcdp.c |4 ++-- > drivers/sfi/sfi_core.c | 22 +++--- > 9 files changed, 55 insertions(+), 66 deletions(-) Reviewed-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Bori

Re: [Xen-devel] [PATCH v3] xen/mce: don't issue error message for failed /dev/mcelog registration

On Wed, Jun 14, 2017 at 10:40:59AM +0200, Juergen Gross wrote: > When running under Xen as dom0 /dev/mcelog is being registered by Xen > instead of the normal mcelog driver. Avoid an error message being > issued by the mcelog driver in this case. Instead issue an informative > message that Xen has

Re: [Xen-devel] [PATCH] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()

On Tue, Jun 13, 2017 at 09:00:01AM -0700, Andy Lutomirski wrote: > 1. Make sure that every read_cr3() instance got converted. I didn't > want a mid-air collision with someone else's patch in which it would > appear to apply and compile but the result would randomly fail on PCID > systems. Right.

Re: [Xen-devel] [PATCH] xen/mce: don't issue error message for failed /dev/mcelog registration

On Tue, Jun 13, 2017 at 03:14:53PM +0200, Juergen Gross wrote: > I'd rather avoid the pr_err() in the -EBUSY case. What about: > > if (err) { > if (err == -EBUSY) > pr_info("Unable to init device /dev/mcelog, already > registered"); > else > pr_err("Unable

Re: [Xen-devel] [PATCH] xen/mce: don't issue error message for failed /dev/mcelog registration

On Tue, Jun 13, 2017 at 02:49:21PM +0200, Juergen Gross wrote: > When running under Xen as dom0 /dev/mcelog is being registered by Xen > instead of the normal mcelog driver. Avoid an error message being > issued by the mcelog driver in this case. Instead issue an informative > message that Xen has

Re: [Xen-devel] [PATCH] x86/mm: Split read_cr3() into read_cr3_pa() and __read_cr3()

On Mon, Jun 12, 2017 at 10:26:14AM -0700, Andy Lutomirski wrote: > The kernel has several code paths that read CR3. Most of them assume that > CR3 contains the PGD's physical address, whereas some of them awkwardly > use PHYSICAL_PAGE_MASK to mask off low bits. > > Add explicit mask macros for

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote: > I'm not feeling strong about it. So if you want to test for > X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine > with it. > > Will send V2 with that change. And remove the corresponding clear_cpu_bug(c,

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Wed, Apr 26, 2017 at 06:45:42AM +0200, Juergen Gross wrote: > The really clean solution would be to add this test to set_cpu_bug() No, the really clean solution is to set it once and not play toggle games. > This would work. OTOH I'd prefer to test whether the bit should be > forced to remain

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 09:17:13PM +0100, Andrew Cooper wrote: > The problem (for all ring-deprivileged virtuailsation; not just Xen PV), > is that I know what that that bug flag is for. I'm asking whether the xen guest boot sets a flag early - like XENPV, for example - which can differentiate

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: > And what happens when there is a scheduling event right here? > __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong > path. So the whole thing we're doing right now is wrong: set bit and then clear bit. We should

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote: > When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set > on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test > cpu_caps_cleared to not have disabled this bit. > > This bug/feature bit is kind of

Re: [Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

On Wed, Feb 15, 2017 at 04:49:21PM +0100, Borislav Petkov wrote: > On Wed, Feb 15, 2017 at 07:40:51AM -0800, Thomas Garnier wrote: > > Why do you think they rely on it being static? The VSYSCALL address is > > not changed for example. > > I don't know, that's why I'm as

Re: [Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

On Wed, Feb 15, 2017 at 07:40:51AM -0800, Thomas Garnier wrote: > Why do you think they rely on it being static? The VSYSCALL address is > not changed for example. I don't know, that's why I'm asking first. Userspace is known to pick different aspects of the kernel and deciding to use them for

Re: [Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

On Tue, Feb 14, 2017 at 11:42:56AM -0800, Thomas Garnier wrote: > This patch aligns MODULES_END to the beginning of the Fixmap section. > It optimizes the space available for both sections. The address is > pre-computed based on the number of pages required by the Fixmap > section. > > It will

Re: [Xen-devel] [PATCH v7 02/14] xtensa: skip adding literal when SORT() is used

On Sun, Jan 15, 2017 at 01:10:45PM -0800, Luis R. Rodriguez wrote: > When SORT(foo.*) is used the current sed replacements add > SORT(foo.literal foo.*), this breaks linking. Avoid adding > literals for SORT globs, if needed, these need to be added > manually. Please rewrite this commit message

Re: [Xen-devel] [PATCH v6 01/14] generic-sections: add section core helpers

On Mon, Jan 09, 2017 at 06:58:19AM -0800, Luis R. Rodriguez wrote: > Linux makes extensive use of custom ELF header sections, > documentation for these are well scatterred. Unify this is > documentation in a central place and provide helpers to > build custom Linux

Re: [Xen-devel] [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

nd as such it's part of the UAPI. I don't think you can > > remove it unless you can guarantee there are no userspace users. > I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks > me > to un-export it. > > I will follow the maintainer decision. I'm no

Re: [Xen-devel] [PATCH v2 4/7] x86: put msr-index.h in uapi

On Fri, Jan 06, 2017 at 10:43:56AM +0100, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. It should rather not be exported - please remove it from arch/x86/include/uapi/asm/Kbuild instead. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid

Re: [Xen-devel] [PATCH] x86/microcode: Use native_cpuid() in load_ucode_amd_bsp()

On Fri, Dec 16, 2016 at 11:39:52AM -0500, Boris Ostrovsky wrote: > When CONFIG_PARAVIRT is selected, cpuid() becomes a call. Since > for 32-bit kernels load_ucode_amd_bsp() is executed before paging > is enabled the call cannot be completed (as kernel virtual addresses > are not reachable yet). >

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, Dec 16, 2016 at 09:40:59AM -0500, Boris Ostrovsky wrote: > It works Thanks. Added your Tested-by. > but I think both of the bugs we talked about yesterday still > need to be fixed, they are not related to Xen. For the one issue with the eq_id, I have the below cleanup for all the args

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, Dec 16, 2016 at 01:19:03PM +0100, Borislav Petkov wrote: > > Okay. Results: > > > > Xen HVM domain is working. > > Xen dom0 is working. > > Bare metal is working, microcode has been loaded. > > > > So you can add my: > > > >

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, Dec 16, 2016 at 01:15:56PM +0100, Juergen Gross wrote: > On 16/12/16 11:45, Borislav Petkov wrote: > > On Fri, Dec 16, 2016 at 11:00:29AM +0100, Juergen Gross wrote: > >> Should work. I'm happy to test any patch. :-) > > > > I'm happy that you're happy to

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, Dec 16, 2016 at 11:00:29AM +0100, Juergen Gross wrote: > Should work. I'm happy to test any patch. :-) I'm happy that you're happy to! :-) Let's try this below. Thanks! --- diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, Dec 16, 2016 at 10:20:42AM +0100, Juergen Gross wrote: > Without testing, but I doubt it is working. As pv guests aren't coming > through check_loader_disabled_bsp() at all I can't see why your patch > would work for dom0. Do they go through check_loader_disabled_ap() ? > Additionally I

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, Dec 16, 2016 at 08:28:46AM +0100, Juergen Gross wrote: > Not trying to load ucode in _any_ guest is an optimization only. Does the hunk below work too? I don't want to do hypervisor-specific solutions. --- diff --git a/arch/x86/kernel/cpu/microcode/core.c

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 10:56:25PM -0500, Boris Ostrovsky wrote: > You can use xen_cpuid_base(), for example. It will prevent microcode loading Actually I want to do this at the end. CPUID(1).ECX[31] is reserved by both vendors for hypervisor use. > True. But I don't think it's clear that the

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote: > With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a > call via a pointer, you can see it, for example, if you disassemble > load_ucode_amd_bsp(). And we don't have paging on yet when we call > load_ucode_amd_bsp

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote: > We are calling find_proper_container(..., _id) and determine result > based on eq_id not being zero. If find_proper_container() doesn't find > anything it will not modify eq_id and so you get back whatever you > passed in. The

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote: > This fixes my PV boot problem. I am still failing to boot HVM, will > need to look at this some more. No, no more stabbing in the dark and no more brown paper bags. Please check whether CPUID(4) works that early in any xen guest

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote: > It will probably fix it but I don't think we want this: it's a > build-time solution. Most kernels have XEN on even though they are > booted bare-metal. Lemme tell you want I want: a way to detect I'm running on xen. Does CPUID(4)

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote: > There is an error on AMD as well. We end up being called at > load_microcode_amd() with size=0 and crash soon after. Does that fix it? diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index dd47e60aabf5..e238119b5dff 100644 ---

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 04:59:49PM +, Andrew Cooper wrote: > Xen has the same logic as Linux does to look for an uncompressed > microcode blob in the initrd and apply it early in boot. > > If dom0 goes looking, it should see the same microcode version as it has > in its initrd. So it sounds

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: > with today's kernel the system isn't coming up when booted as Xen dom0: Remind me again pls, is dom0 even supposed to load microcode? Isn't the hypervisor supposed to apply microcode? > Looking into the state of cpu 1 I find the

Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

On Mon, Dec 05, 2016 at 01:32:43PM -0800, Andy Lutomirski wrote: > Aside from being excessively slow, CPUID is problematic: Linux runs > on a handful of CPUs that don't have CPUID. Use IRET-to-self > instead. IRET-to-self works everywhere, so it makes testing easy. > > For reference, On my

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > Alright, how's this new description: > > diff --git a/init/Kconfig b/init/Kconfig > index cac3f096050d..73e4890c24c4 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -53,6 +53,34 @@ config CROSS_COMPILE > need to

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote: > Even so, you don't link the compiled extra code so the only penalty > here is when compiling, nothing more. And if you are compiling typically > the cost here is just a few seconds. Yeah, so let's make it clear that this is

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote: > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote: > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote: > > > OK I've added CONFIG_BUILD_AVOID_BITROT. > > > > What

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote: > OK I've added CONFIG_BUILD_AVOID_BITROT. What does that do? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- ___ Xen-devel mailing list

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Mon, Aug 08, 2016 at 05:05:39PM +0200, Luis R. Rodriguez wrote: > > So how can I disable those table-* things from even getting built? Avoid > > using table-y? But then everything declared table-y will be built > > unconditionally. I don't think I like that. :-\ > > I suppose we could make

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Jul 22, 2016 at 02:24:41PM -0700, Luis R. Rodriguez wrote: > A linker table is a data structure that is stitched together from items > in multiple object files. Linux has historically implicitly used linker > tables for ages, however they were all built in an adhoc manner which > requires

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote: > With considerable pain we just got rid of paravirt_enabled() in the > x86 tree, and Xen is now reintroducing it in the EFI code. I think Matt is working towards removing EFI_PARAVIRT but he'll comment himself when he wakes up... :)

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On Mon, Apr 25, 2016 at 11:48:19AM -0400, Boris Ostrovsky wrote: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/boot.txt#n1096 > > is what I was referring to. Right, so reportedly those two weren't meant to be entry points initially but stuff is using

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On Mon, Apr 25, 2016 at 10:42:15AM -0400, Boris Ostrovsky wrote: > Hmm... I thought that everything specified in boot.txt was ABI. But those are not there. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On Mon, Apr 25, 2016 at 09:54:37AM -0400, Boris Ostrovsky wrote: > Yes, those. I don't think the ones in arch/x86/kernel/head_{32,64}.S are ABI. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On Mon, Apr 25, 2016 at 09:21:27AM -0400, Boris Ostrovsky wrote: > I was following Documentation/x86/boot.txt (plus comments in code preceding > those two routines) which I considered to be the API. > > We are supposed to come to startup_32 with paging off and %esi pointing to > boot_params. For

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On Mon, Feb 01, 2016 at 10:38:48AM -0500, Boris Ostrovsky wrote: > Start HVMlite guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall > page, initialize boot_params, enable early page tables. > > Since this stub is executed before kernel entry point we cannot use > variables in .bss which

Re: [Xen-devel] [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

On Fri, Apr 22, 2016 at 11:03:53AM -0700, H. Peter Anvin wrote: > Please don't use the cpu_has_* macros anymore, they are going away soon. > > In this case it should be static_cpu_has(X86_FEATURE_PSE). Ingo fixed this up while merging: b2eafe890d4a ("Merge branch 'x86/urgent' into x86/asm, to

Re: [Xen-devel] [PATCH v4 00/14] x86: remove paravirt_enabled

On Fri, Apr 08, 2016 at 03:14:43AM +0200, Luis R. Rodriguez wrote: > On Wed, Apr 06, 2016 at 05:06:20PM -0700, Luis R. Rodriguez wrote: > > Now that Andy's ASM paravirt_enabled() use is merged > > Sorry I should have provided more context, I meant that now > that Andy's ASM paravirt_enabled()

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Mon, Apr 04, 2016 at 02:31:46PM -0700, Andy Lutomirski wrote: > Could you do it by moving just the earlyprintk stuff a la > fpu__init_parse_early_param()? Yeah, something like that. I'll play with this more tomorrow. Btw, no need to make any of this part of your patchset - I'd like early

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Mon, Apr 04, 2016 at 06:00:42PM +0200, Peter Zijlstra wrote: > On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote: > > > Adding locking would be easy enough, wouldn't it? > > See patch in this thread.. > > > But do any platforms really boot a second CPU before switching to real

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

andlers work early. > > * SECOND PART: MSRs * > > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. ... FWIW: Reviewed-by: Borislav Petk

Re: [Xen-devel] [PATCH] x86/extable: Add a comment about early exception handlers

nteed to > + * result in a hard-to-debug panic. > + * > + * Keep in mind that not all vectors actually get here. Early > + * fage faults, for example, are special. > + */ > if (fixup_exception(regs, trapnr)) > return; > > --

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sun, Apr 03, 2016 at 06:55:00AM -0700, Andy Lutomirski wrote: > > No, please don't fail at early boot. > > > > Early boot is just about the *worst* situation to try to debug odd > > failures, exactly since things like printk may not be reliable, and > > things won't get logged etc. > > > > So

Re: [Xen-devel] [PATCH v5 5/9] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

On Sun, Apr 03, 2016 at 06:23:36AM -0700, Andy Lutomirski wrote: > You already caught that one. It's fixed in "x86/paravirt: Add > paravirt_{read,write}_msr". > > Congrats on being deterministic :) LOL. TBH, I had a strange deja-vu while typing... :-) -- Regards/Gruss, Boris. ECO tip

Re: [Xen-devel] [PATCH v5 5/9] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

On Sat, Apr 02, 2016 at 07:01:36AM -0700, Andy Lutomirski wrote: > These hooks match the _safe variants, so name them accordingly. > This will make room for unsafe PV hooks. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/include/asm/paravirt.h | 33

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sat, Apr 02, 2016 at 10:52:48PM +0200, Borislav Petkov wrote: > On Sat, Apr 02, 2016 at 01:16:07PM -0700, Andy Lutomirski wrote: > > I have no idea why it was explicitly unsupported, but I'm guessing it > > was just to avoid duplicating the code. Early "ext" uaccess f

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sat, Apr 02, 2016 at 01:16:07PM -0700, Andy Lutomirski wrote: > I have no idea why it was explicitly unsupported, but I'm guessing it > was just to avoid duplicating the code. Early "ext" uaccess failures > are certainly not going to work, but I don't think this is a problem > -- there's no

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote: > Given that I this isn't really a regression with my patches (it > probably never worked much better on 32-bit and the regs never would > have shown at all on 64-bit), You're right. That thing calls printk *and* early_printk, WTF:

Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early

On Sat, Apr 02, 2016 at 07:01:35AM -0700, Andy Lutomirski wrote: > Now that early_fixup_exception has pt_regs, we can just call > fixup_exception from it. This will make fancy exception handlers > work early. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/mm/extable.c |

Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On Sat, Apr 02, 2016 at 07:01:34AM -0700, Andy Lutomirski wrote: > This removes a bunch of assembly and adds some C code instead. It > changes the actual printouts on both 32-bit and 64-bit kernels, but > they still seem okay. > > Signed-off-by: Andy Lutomirski > --- >

Re: [Xen-devel] [PATCH v2 2/6] x86/mm/pat: Add pat_disable() interface

On Tue, Mar 22, 2016 at 03:40:45PM -0600, Toshi Kani wrote: > Will change to "Prevent the OS from initializing the PAT MSR". > > I wanted to clarify that "disable" does not mean to disable PAT MSR. How do you "disable PAT MSR" ? I think you're overdocumenting this. pat_disable() is as clear as

Re: [Xen-devel] [PATCH v2 3/6] x86/mtrr: Fix Xorg crashes in Qemu sessions

On Tue, Mar 22, 2016 at 03:53:30PM -0600, Toshi Kani wrote: > Yes. I had to remove this number since checkpatch complained that I needed > to quote the whole patch tile again.  I will ignore this checkpatch error > and add this commit number here. Actually, checkpatch is right. We do quote the

Re: [Xen-devel] [PATCH v2 1/6] x86/mm/pat: Change PAT to support non-default PAT MSR

On Tue, Mar 22, 2016 at 12:35:19PM -0600, Toshi Kani wrote: > Right.  Will change to "Add support of non-default PAT MSR setting at > handoff". Please remove this "handoff" notion from the text. Every hw register is being handed off to the OS once the kernel takes over so there's no need to make

Re: [Xen-devel] [PATCH v2 6/6] x86/pat: Document PAT initializations

On Wed, Mar 16, 2016 at 06:46:59PM -0600, Toshi Kani wrote: > Update PAT documentation to describe how PAT is initialized under > various configurations. > > Signed-off-by: Toshi Kani <toshi.k...@hpe.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Luis R. Rodriguez &

Re: [Xen-devel] [PATCH v2 5/6] x86/xen, pat: Remove PAT table init code from Xen

by other modules. > > Signed-off-by: Toshi Kani <toshi.k...@hpe.com> > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Cc: Borislav Petkov <b...@suse.de> > Cc: Luis R. Rodriguez <mcg...@suse.com> > Cc: Juergen Gross <jgr...@suse.com> > Cc: Ingo M

Re: [Xen-devel] [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled

Subject: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled s/ MSR// On Wed, Mar 16, 2016 at 06:46:57PM -0600, Toshi Kani wrote: > get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled > by its MSR. s/by its MSR// > This causes pat_init() to be called on BSP

Re: [Xen-devel] [PATCH v2 3/6] x86/mtrr: Fix Xorg crashes in Qemu sessions

ll that text from "This patch ..." on - we can see that in the diff. The commit message needs to contain "why" not "what". > > [1]: https://lkml.org/lkml/2016/3/3/828 > [2]: https://lkml.org/lkml/2016/3/4/775 I believe I already mentioned that links shoul

Re: [Xen-devel] [PATCH v2 2/6] x86/mm/pat: Add pat_disable() interface

d when PAT initialization may not be performed. This paragraph reads funky and I can't really parse what it is trying to say. > This also assures that pat_disable() called from pat_bsp_init() > to set PAT table properly when CPU does not support PAT. > > Signed-off-by: Toshi Kani <toshi.k.

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Tue, Mar 15, 2016 at 11:11:23AM -0600, Toshi Kani wrote: > While cpu_has_pat is the same as boot_cpu_has(X86_FEATURE_PAT), cpu_has_XXX > should not be used.  So, this code needs to be changed to use > boot_cpu_has(X86_FEATURE_PAT) directly. > > Is this right? Yes. -- Regards/Gruss,

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Tue, Mar 15, 2016 at 09:43:15AM -0600, Toshi Kani wrote: > > Please use on init paths boot_cpu_has(X86_FEATURE_PAT) and on fast paths > > static_cpu_has(X86_FEATURE_PAT). No more of that cpu_has_XXX ugliness. > > 'cpu_has_pat' is defined as 'boot_cpu_has(X86_FEATURE_PAT)'.  Do you mean > it

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Mon, Mar 14, 2016 at 09:11:16PM -0600, Toshi Kani wrote: > - pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) | > - PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC); > + if (cpu_has_pat) { Please use on init paths boot_cpu_has(X86_FEATURE_PAT) and on fast

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN_ONCE and, for RDMSR, a return value of zero. If > panic_on_oops is set, then failed unsafe MSR accesses will still > oops and panic. > > To

Re: [Xen-devel] [PATCH v4 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

nsigned int *ebx, > unsigned int *ecx, unsigned int *edx); > > - /* MSR, PMC and TSR operations. > -err = 0/-EFAULT. wrmsr returns 0/-EFAULT. */ > - u64 (*read_msr)(unsigned int msr, int *err); > - int (*write_msr)(unsigned int msr, unsig

Re: [Xen-devel] [PATCH v2 2/2] x86/asm-offsets: Remove PARAVIRT_enabled

RT_enabled, pv_info, paravirt_enabled); > OFFSET(PARAVIRT_PATCH_pv_cpu_ops, paravirt_patch_template, pv_cpu_ops); > OFFSET(PARAVIRT_PATCH_pv_irq_ops, paravirt_patch_template, pv_irq_ops); > OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable); > -- Reviewed-by: Borislav Petkov

Re: [Xen-devel] [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled

virt_enabled user, which is > good because paravirt_enabled is ill-defined and is going away. > > Signed-off-by: Andy Lutomirski <l...@kernel.org> > --- > arch/x86/entry/entry_32.S | 15 ++- > arch/x86/include/asm/cpufeatures.h | 8 > arch/x86/k

  1   2   >