From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764121AbdJQURs (ORCPT ); Tue, 17 Oct 2017 16:17:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34314 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753410AbdJQURq (ORCPT ); Tue, 17 Oct 2017 16:17:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 436DC820FA 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: Tue, 17 Oct 2017 15:17:43 -0500 From: Josh Poimboeuf To: Boris Ostrovsky Cc: Andrew Cooper , Juergen Gross , Rusty Russell , Mike Galbraith , xen-devel@lists.xenproject.org, Peter Zijlstra , Jiri Slaby , x86@kernel.org, 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 11/13] x86/paravirt: Add paravirt alternatives infrastructure Message-ID: <20171017201743.tnw6wulu4gjvkqli@treble> References: <3b9fd404-6912-3b58-db29-36202631b438@oracle.com> <20171006143259.rs3zh7k5tmsgesqy@treble> <5a49e43a-8d6b-512a-ec5a-641be7bae41d@oracle.com> <20171017052413.nzbqniurzw7eim4b@treble> <20171017143613.6i7auk3mqcqayx3o@treble> <2e7890fb-3634-0f3b-003f-fc1772504b9a@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2e7890fb-3634-0f3b-003f-fc1772504b9a@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]); Tue, 17 Oct 2017 20:17:46 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > > > Maybe we can add a new field to the alternatives entry struct which > > specifies the offset to the CALL instruction, so apply_alternatives() > > can find it. > > We'd also have to assume that the restore part of an alternative entry > is the same size as the save part. Which is true now. Why? -- Josh