From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751720AbdJFOgK (ORCPT ); Fri, 6 Oct 2017 10:36:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44296 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbdJFOgJ (ORCPT ); Fri, 6 Oct 2017 10:36:09 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 38570C047B86 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Fri, 6 Oct 2017 09:36:06 -0500 From: Josh Poimboeuf To: Vitaly Kuznetsov Cc: x86@kernel.org, Juergen Gross , Rusty Russell , xen-devel@lists.xenproject.org, Peter Zijlstra , Jiri Slaby , Boris Ostrovsky , Mike Galbraith , linux-kernel@vger.kernel.org, Sasha Levin , Chris Wright , Thomas Gleixner , Andy Lutomirski , "H. Peter Anvin" , Borislav Petkov , live-patching@vger.kernel.org, Alok Kataria , virtualization@lists.linux-foundation.org, Linus Torvalds , Ingo Molnar Subject: Re: [Xen-devel] [PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality Message-ID: <20171006143606.tbv4y2te6jvqoach@treble> References: <87bmlkiv9n.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87bmlkiv9n.fsf@vitty.brq.redhat.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.31]); Fri, 06 Oct 2017 14:36:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 06, 2017 at 09:35:16AM +0200, Vitaly Kuznetsov wrote: > Josh Poimboeuf writes: > > > - For the most common runtime cases (everything except Xen and vSMP), > > vmlinux disassembly now matches what the actual runtime code looks > > like. This improves debuggability and kernel developer sanity (a > > precious resource). > > > > ... > > > > - It's hopefully a first step in simplifying paravirt patching by > > getting rid of .parainstructions, pv ops, and apply_paravirt() > > completely. (I think Xen can be changed to set CPU feature bits to > > specify which ops it needs during early boot, then those ops can be > > patched in using early alternatives.) > > JFYI starting 4.14 Xen PV is not the only user of pv_mmu_ops, Hyper-V > uses it for TLB shootdown now. Yeah, I saw that. It should be fine because the pv_alternatives get patched before the Hyper-V code sets up pv_mmu_ops. -- Josh