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.
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.
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
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.
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
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
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")
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
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
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
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
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?
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
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
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
>
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
>
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
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
>
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
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,
.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
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
>
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
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
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.
>
>
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
> 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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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?
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
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?
--
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
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
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 +
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
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
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:
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
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
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
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.
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
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
101 - 158 of 158 matches
Mail list logo