From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752002AbdJFOdE (ORCPT ); Fri, 6 Oct 2017 10:33:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60386 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbdJFOdD (ORCPT ); Fri, 6 Oct 2017 10:33:03 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 12F44883B4 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Fri, 6 Oct 2017 09:32:59 -0500 From: Josh Poimboeuf To: Boris Ostrovsky Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Juergen Gross , Andy Lutomirski , Linus Torvalds , Sasha Levin , live-patching@vger.kernel.org, Jiri Slaby , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith , Chris Wright , Alok Kataria , Rusty Russell , virtualization@lists.linux-foundation.org, xen-devel@lists.xenproject.org, Thomas Gleixner , Borislav Petkov Subject: Re: [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure Message-ID: <20171006143259.rs3zh7k5tmsgesqy@treble> References: <39743c79546ede3073586403d0836a4f93519b0a.1507128293.git.jpoimboe@redhat.com> <3b9fd404-6912-3b58-db29-36202631b438@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3b9fd404-6912-3b58-db29-36202631b438@oracle.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 06 Oct 2017 14:33:03 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: > > > #ifdef CONFIG_PARAVIRT > > +/* > > + * Paravirt alternatives are applied much earlier than normal alternatives. > > + * They are only applied when running on a hypervisor. They replace some > > + * native instructions with calls to pv ops. > > + */ > > +void __init apply_pv_alternatives(void) > > +{ > > + setup_force_cpu_cap(X86_FEATURE_PV_OPS); > > Not for Xen HVM guests. >>From what I can tell, HVM guests still use pv_time_ops and pv_mmu_ops.exit_mmap, right? > > + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end); > > +} > > > This is a problem (at least for Xen PV guests): > apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death. Ah, right. > It might be possible not to turn off/on the interrupts in this > particular case since the guest probably won't be able to handle an > interrupt at this point anyway. Yeah, that should work. For Xen and for the other hypervisors, this is called well before irq init, so interrupts can't be handled yet anyway. > > + > > void __init_or_module apply_paravirt(struct paravirt_patch_site *start, > > struct paravirt_patch_site *end) > > { > > diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c > > index 4fa90006ac68..17243fe0f5ce 100644 > > --- a/arch/x86/kernel/cpu/hypervisor.c > > +++ b/arch/x86/kernel/cpu/hypervisor.c > > @@ -71,6 +71,8 @@ void __init init_hypervisor_platform(void) > > if (!x86_hyper) > > return; > > > > + apply_pv_alternatives(); > > Not for Xen PV guests who have already done this. I think it would be harmless, but yeah, it's probably best to only write it once. Thanks for the review! -- Josh