Re: [Xen-devel] [PATCH] misc/xenmicrocode: Upload /lib/firmware/some blob to the hypervisor

On Tue, Jan 27, 2015 at 10:26:00PM +, Andrew Cooper wrote: I am not convinced of the safely of permitting microcode updates at runtime. We have seen in the past that having mismatched microcode on different halfs of an AMD cluster causes system crashes when non-root What kind of CPU mix

Re: [Xen-devel] [PATCH] misc/xenmicrocode: Upload /lib/firmware/some blob to the hypervisor

On Wed, Jan 28, 2015 at 12:10:43AM +, Andrew Cooper wrote: There was a thread on xen-devel but I cant currently find it in the archives. To the best of my memory, it was a 4 core APU system where the BIOS had updated the microcode on cpu 0 but left 1-3 at a lower patch level. Every

Re: [Xen-devel] [PATCH] misc/xenmicrocode: Upload /lib/firmware/some blob to the hypervisor

On Thu, Jan 29, 2015 at 04:21:05AM +0100, Luis R. Rodriguez wrote: How close? As close as we can get but not closer - see the thing about updating microcode on Intel hyperthreaded logical cores in the other mail. We probably can do it in parallel if needed. But it hasn't been needed until now.

Re: [Xen-devel] [RFC PATCH] x86/asm/irq: Don't use POPF but STI

On Tue, Apr 21, 2015 at 02:45:58PM +0200, Ingo Molnar wrote: From 6f01f6381e8293c360b7a89f516b8605e357d563 Mon Sep 17 00:00:00 2001 From: Ingo Molnar mi...@kernel.org Date: Tue, 21 Apr 2015 13:32:13 +0200 Subject: [PATCH] x86/asm/irq: Don't use POPF but STI So because the POPF instruction

Re: [Xen-devel] [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()

On Wed, Jun 24, 2015 at 06:22:13PM -0700, Luis R. Rodriguez wrote: Luis R. Rodriguez (9): pci: add pci_ioremap_wc_bar() video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar() video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar() video: fbdev: gxt4500:

Re: [Xen-devel] [PATCH v8 6/9] lib: devres: add pcim_iomap_wc() variants

On Wed, Jun 24, 2015 at 06:22:19PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com Now that we have pci_iomap_wc() add the respective devres helpers. These go unexported for now but note that should they later be exported this must go with EXPORT_SYMBOL_GPL(). Do I

Re: [Xen-devel] [PATCH v8 5/9] PCI: Add pci_iomap_wc() variants

On Wed, Jun 24, 2015 at 06:22:18PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com PCI BARs tell us whether prefetching is safe, but they don't say anything about write combining (WC). WC changes ordering rules and allows writes to be collapsed, so it's not safe in

Re: [Xen-devel] [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime

On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote: P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense whatsoever when NMIs run on an IST stack? Seriously, people? What happened with asking Intel for a sane IRET-NG? Should be relatively easy - take the current

Re: [Xen-devel] [PATCH v5 2/4] x86/ldt: Make modify_ldt synchronous

in multithreaded programs, but there shouldn't be any multithreaded programs that care about modify_ldt's performance in the first place. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski l...@kernel.org I've stared a lot at this one these days, I guess a Reviewed-by: Borislav Petkov b

Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option

Hey Boris, On Thu, Jul 30, 2015 at 01:18:20PM -0400, Boris Ostrovsky wrote: Only V5, no extra changes. Including running the ldt_gdt test? Yes, except that 32-on-64 doesn't work, but that's not Xen-specific. so which tests are you running exactly and where can I get them? Andy's repo?

Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option

On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote: As far as Xen guests are concerned, Tested-by: Boris Ostrovsky boris.ostrov...@oracle.com Does that mean, this patch 1/4 fixes the 32bit issue you guys are still debugging on the v4 thread? Or does that need more fixing? --

Re: [Xen-devel] [PATCH v3 1/3] x86/ldt: Make modify_ldt synchronous

On Wed, Jul 22, 2015 at 12:23:46PM -0700, Andy Lutomirski wrote: modify_ldt has questionable locking and does not synchronize threads. Improve it: redesign the locking and synchronize all threads' LDTs using an IPI on all modifications. This will dramatically slow down modify_ldt in

Re: [Xen-devel] [PATCH v3 1/3] x86/ldt: Make modify_ldt synchronous

On Wed, Jul 22, 2015 at 12:23:46PM -0700, Andy Lutomirski wrote: modify_ldt has questionable locking and does not synchronize threads. Improve it: redesign the locking and synchronize all threads' LDTs using an IPI on all modifications. This will dramatically slow down modify_ldt in

Re: [Xen-devel] [PATCH v3 1/3] x86/ldt: Make modify_ldt synchronous

On Fri, Jul 24, 2015 at 09:52:01PM -0700, Andy Lutomirski wrote: I see your wide terminal and raise you a complete rewrite of that function. Sigh, why did I assume the old code was the right way to do it? That's a mostly wrong assumption, as experience proves. Hah¸ we both missed it. This

Re: [Xen-devel] [PATCH v4 1/3] x86/ldt: Make modify_ldt synchronous

in multithreaded programs, but there shouldn't be any multithreaded programs that care about modify_ldt's performance in the first place. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski l...@kernel.org Reviewed-by: Borislav Petkov b...@suse.de -- Regards/Gruss, Boris. ECO tip #101

Re: [Xen-devel] [PATCH v4 2/3] x86/ldt: Make modify_ldt optional

On Fri, Jul 24, 2015 at 10:36:45PM -0700, Andy Lutomirski wrote: The modify_ldt syscall exposes a large attack surface and is unnecessary for modern userspace. Make it optional. Signed-off-by: Andy Lutomirski l...@kernel.org --- arch/x86/Kconfig | 17 +

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote: > ... > The reader surely doesn't remember that this isn't guaranteed to be a > swapgs instruction on native. Using: > > ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV > > would be safer (it would get rid of the SWAPGS_UNSAFE_STACK

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On Mon, Nov 16, 2015 at 12:50:19PM -0800, Andy Lutomirski wrote: > (In fact, I'm slowly working on removing KVM_GUEST's dependency on > PARAVIRT.) Good! The hope that we'll be able to remove paravirt one day is != 0 again. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote: > On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov <b...@alien8.de> wrote: > > On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote: > > > >> ... > >> The reader surely does

[Xen-devel] [RFC PATCH] x86/paravirt: Kill some unused patching functions

From: Borislav Petkov <b...@suse.de> paravirt_patch_ignore() is completely unused and paravirt_patch_nop() doesn't do a whole lot. Remove them both. Signed-off-by: Borislav Petkov <b...@suse.de> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Andy Lutomirski <l...@kernel.

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On Tue, Nov 17, 2015 at 11:16:11AM -0800, Andy Lutomirski wrote: > Works for me, too, although seeing "xen_pv_host" in the Linux cpu > features would be very strange indeed :) That feature would be, of course, *not* in /proc/cpuinfo. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails

Re: [Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Wed, Nov 18, 2015 at 12:21:56PM -0800, Andy Lutomirski wrote: > > diff --git a/arch/x86/include/asm/cpufeature.h > > b/arch/x86/include/asm/cpufeature.h > > index e4f8010..0e4fe5b 100644 > > --- a/arch/x86/include/asm/cpufeature.h > > +++ b/arch/x86/include/asm/cpufeature.h > > @@ -216,6

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 09:19:20AM +0200, Ingo Molnar wrote: > Most big distro kernels on bare metal have CONFIG_PARAVIRT=y (I checked > Ubuntu and > Fedora), so we are potentially exposing a lot of users to problems. + SUSE. > Crashing the bootup on an unknown MSR is bad. Many MSR reads and

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 04:32:53PM +0100, Andrew Cooper wrote: > There are plenty of non-architectural MSRs in use which don't have > feature bits. That's exactly what the "possible" adjective was supposed to represent. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 01:39:26PM +0200, Paolo Bonzini wrote: > That's not a big deal, that's what *_safe is for. The problem is that > there are definitely some cases where the *_safe version is not being used. I mean to do feature checks which assure you that those MSRs are there so you don't

Re: [Xen-devel] [PATCH] KVM: x86: trap AMD MSRs for the TSeg base and mask

n 0, meaning that processor protection of SMRAM is not > in effect. > > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > arch/x86/include/asm/msr-index.h | 1 + > arch/x86/kvm/x86.c | 2 ++ > 2 files changed, 3 insertions(+) Acked-by: Borislav P

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote: > In any event, Borislav, you must have typed rdmsr_safe for a reason :) Wasn't me: 6c62aa4a3c12 ("x86: make amd.c have 64bit support code") I think the error handling of rdmsrl_safe() was needed to do the pfn games which are done

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote: > Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until Why not? It is the tseg base address. I think this is kvm injecting a #GP as it is not ignoring this MSR. Presumably modprobing kvm with "ignore_msrs=1" or so

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

On Mon, Sep 21, 2015 at 11:16:30AM -0700, Andy Lutomirski wrote: > In the interest of sanity, I want to drop the "native_", too, since > there appear to be few or no good use cases for native_read_msr as > such. I'm tempted to add new functions read_msr and write_msr that > forward to rdmsrl_safe

Re: [Xen-devel] [PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Tue, Dec 15, 2015 at 10:21:37AM -0500, Boris Ostrovsky wrote: > I know this has been in the tip tree --- when do you think this will go > Linus tree? In the 4.4 timeframe? It is queued for 4.5 currently. > Xen 32-bit PV guests are broken without this. So this needs to go into 4.4 or even

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

> arch/x86/kernel/paravirt_patch_64.c | 3 --- > arch/x86/xen/enlighten.c | 7 +++ > arch/x86/xen/xen-asm_32.S | 14 -- > arch/x86/xen/xen-asm_64.S | 19 --- > arch/x86/xen/xen-ops.h| 3 --- > 14 files c

Re: [Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Wed, Nov 18, 2015 at 12:21:56PM -0800, Andy Lutomirski wrote: > Could we make this a little less subtle: > > ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp > .Lsyscasll_32_done", X86_FEATURE_XENPV > > Borislav, what do you think? I don't mind either. I would've said your version

Re: [Xen-devel] [PATCH 0/3] Fix and cleanup for 32-bit PV sysexit

On Wed, Nov 18, 2015 at 03:06:16PM -0500, Boris Ostrovsky wrote: > The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike > the > earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit > (and sysret32 in compat mode) pv ops, as suggested by Andy. (I

Re: [Xen-devel] Unifying x86_64 / Xen init paths and reading hardware_subarch early

On Fri, Jan 15, 2016 at 05:39:05PM -0800, Luis R. Rodriguez wrote: > On Fri, Jan 15, 2016 at 4:43 PM, Luis R. Rodriguez wrote: > >> for (i = 0; i < sizeof(boot_params); i += 4096) > >> early_make_pgtable((unsigned long)params + i); > > > > I'll give this a shot. > >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote: > int __init microcode_init(void) > { > [...] > if (paravirt_enabled() || dis_ucode_ldr) > return -EINVAL; > > This is also asking "are we the natively booted kernel?" This is > plausibly useful for

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: > I think we are OK for PV because this code will be executed after pvops are > set and so we will be calling xen_cpuid(). Not for the early loader - it is too early for pvops then. So you're saying something like that won't work?

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote: > Does the early loader have extable support? If so, this is fairly easy > to fix. If not, we have a problem. It doesn't and regardless, you want to have this CPUID querying as simple as possible. No special handling, no special

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote: > This range is reserved for hypervisors but the only hypervisor that uses it > is Xen PV (lguest doesn't run in 64-bit mode). Yeah, this is mentioned in arch/x86/include/asm/page_64_types.h: /* * Set __PAGE_OFFSET to the most

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote: > It does. Very much IIRC, the problem was not caused by an access to MSR but > rather some sort of address not being available somewhere. See below. > >- microcode application on Xen: we've had this before. The hypervisor >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 11:41:16AM -0500, Boris Ostrovsky wrote: > Keep in mind that Xen PV doesn't go through startup_32|64(). It starts at > xen_start_kernel (save for a small stub before that), which sets pvops. It > "joins" regular/baremetal code in >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 04:53:00PM +, Andrew Cooper wrote: > As an alternative check which should be doable this early on, peeking in > the head of hypercall_page should work. If Linux was booted as a PV > guest, the hypercall_page will have been constructed by the domain > builder, and won't

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Mon, Feb 08, 2016 at 03:45:21PM -0500, Boris Ostrovsky wrote: > So it looks like we can just simply revert a18a0f6850 because the very next > patch to microcode code (fbae4ba8c4a) makes the original problem (of using > __pa_nodebug, which we shouldn't use on PV) go away: we don't call >

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On Wed, Jan 27, 2016 at 02:50:36PM +, David Vrabel wrote: > Surely the interesting comparison here is how is (early) microcode > loading disabled in KVM guests? It isn't - kvm simply ignores the write to the microcode application MSRs MSR_AMD64_PATCH_LOADER and MSR_IA32_UCODE_REV,

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On Mon, Feb 22, 2016 at 07:07:56AM +0100, Luis R. Rodriguez wrote: > diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h > index 1ae89a2721d6..fe0d579b63e3 100644 > --- a/arch/x86/include/asm/x86_init.h > +++ b/arch/x86/include/asm/x86_init.h > @@ -84,11 +84,14 @@ struct

Re: [Xen-devel] [PATCH v3 00/17] Enhance iomem search interfaces and support EINJ to NVDIMM

On Mon, Jan 25, 2016 at 02:34:21PM -0700, Toshi Kani wrote: > I verified the patches and tested the kernel in the tree. All look > good. Thanks! -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 00/17] Enhance iomem search interfaces and support EINJ to NVDIMM

On Tue, Jan 05, 2016 at 11:54:28AM -0700, Toshi Kani wrote: > This patch-set enhances the iomem table and its search interfacs, and > then changes EINJ to support NVDIMM. > > - Patches 1-2 add a new System RAM type, IORESOURCE_SYSTEM_RAM, and >make the iomem search interfaces work with

[Xen-devel] [PATCH 08/17] xen, mm: Set IORESOURCE_SYSTEM_RAM to System RAM

.org Link: http://lkml.kernel.org/r/1452020081-26534-8-git-send-email-toshi.k...@hpe.com Signed-off-by: Borislav Petkov <b...@suse.de> --- drivers/xen/balloon.c | 2 +- mm/memory_hotplug.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/balloon.c b/d

Re: [Xen-devel] [PATCH v1 01/12] x86/smp: Make start_secondary() and initial_pg_pmd visible globally

On Mon, Jan 25, 2016 at 10:30:26AM -0500, Boris Ostrovsky wrote: > initial_pg_pmd (together with initial_page_table) are not really required > --- I just used them for temporary page tables in the hvmlite startup code > instead of allocating dedicated pages for that. Perhaps there is other >

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Wed, Feb 17, 2016 at 12:07:13PM -0800, Luis R. Rodriguez wrote: > OK so here's a wiki to keep track of progress of the difference uses: > > http://kernelnewbies.org/KernelProjects/remove-paravirt-enabled > > It seems we have a resolution one way or another for all except for > the use on

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote: > That's exactly the point: if something is mapped it's an error for a > non-PV kernel. How would something be mapped there? __PAGE_OFFSET is 0x8800. Or are you thinking about some insanely b0rked kernel code mapping

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On Wed, Feb 17, 2016 at 05:39:23PM -0500, Boris Ostrovsky wrote: > Hmm. I think you are right --- I was following wrong branch of the 'if' > statement. We are always going straight to note_page(). Yap. The is_hypervisor_range() - without the "!" - does note_page(). > Then yes, we should be able

Re: [Xen-devel] [PATCH] x86, microcode: Remove unnecessary paravirt_enabled check

On Fri, Feb 19, 2016 at 12:06:33PM +0200, Andy Shevchenko wrote: > Sorry for being too late, but this commit breaks 32-bit kernel on > Intel Medfield. Reverting the only commit from today's linux-next > helps. You mean this commit?! fbae4ba8c4a3 ("x86, microcode: Reload microcode on resume")

Re: [Xen-devel] [PATCH] x86, microcode: Remove unnecessary paravirt_enabled check

On Fri, Feb 19, 2016 at 12:33:46PM +0200, Andy Shevchenko wrote: > No, the commit 84aba677f009 as of today's linux-next on which I commented. You commented under the "> A subsequent commit, fbae4ba8c4a3" which confused me as to which commit is the culprit. > commit

Re: [Xen-devel] [PATCH] x86, microcode: Remove unnecessary paravirt_enabled check

On Fri, Feb 19, 2016 at 01:00:35PM +0200, Andy Shevchenko wrote: > That what I see last with earlycon enabled + `debug` in cmdline: That doesn't help. Can you dump RIP, etc registers as to where the machine freezes? Let me confirm this: booting with "dis_ucode_ldr" works? Also, please send

Re: [Xen-devel] [PATCH] x86, microcode: Remove unnecessary paravirt_enabled check

On Fri, Feb 19, 2016 at 01:21:10PM +0200, Andy Shevchenko wrote: > Heh, rebuilt on clean repository -> everything works. Looks like false > alarm and practical proof to do clean build first. Always, like *really* *always*, do $ make mrproper or even $ git clean -dqfx before testing kernels.

Re: [Xen-devel] [PATCH] x86, microcode: Remove unnecessary paravirt_enabled check

On Thu, Feb 11, 2016 at 10:13:18AM -0500, Boris Ostrovsky wrote: > Commit a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on > paravirt") added a paravirt test in microcode_init(), primarily to avoid > making mc_bp_resume()->load_ucode_ap()->check_loader_disabled_ap() calls > On

Re: [Xen-devel] [PATCH v2 0/2] x86/entry/32: Get rid of paravirt_enabled in ESPFIX

On Mon, Feb 29, 2016 at 03:50:18PM -0800, Andy Lutomirski wrote: > Borislav, if you're okay with this (ab)use of the cpufeatures stuff Because of X86_BUG_ESPFIX? Why abuse? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

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

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 0/2] x86/entry/32: Get rid of paravirt_enabled in ESPFIX

On Wed, Mar 02, 2016 at 04:47:38PM -0800, Andy Lutomirski wrote: > Because I'm mixing paravirt and cpufeatures a bit oddly. That's fine. All X86_BUG_* are synthetic and exactly for stuff like that. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

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 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 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 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 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 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 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 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] 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 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 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 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 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 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 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 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, 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] [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] [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] 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] [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] [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 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: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 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 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] [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

  1   2   >