From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933443AbdJQUul (ORCPT <rfc822;w@1wt.eu>);
        Tue, 17 Oct 2017 16:50:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:46136 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754052AbdJQUuk (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 17 Oct 2017 16:50:40 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 150825F755
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com
Date: Tue, 17 Oct 2017 15:50:37 -0500
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
        Juergen Gross <jgross@suse.com>, Rusty Russell <rusty@rustcorp.com.au>,
        Mike Galbraith <efault@gmx.de>, xen-devel@lists.xenproject.org,
        Peter Zijlstra <peterz@infradead.org>, Jiri Slaby <jslaby@suse.cz>,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        Sasha Levin <alexander.levin@verizon.com>,
        Chris Wright <chrisw@sous-sol.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Borislav Petkov <bp@alien8.de>, live-patching@vger.kernel.org,
        Alok Kataria <akataria@vmware.com>,
        virtualization@lists.linux-foundation.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>
Subject: Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt
 alternatives infrastructure
Message-ID: <20171017205037.rnqto2i2hul4q2s4@treble>
References: <5a49e43a-8d6b-512a-ec5a-641be7bae41d@oracle.com>
 <ed30216f-4b9e-2bc3-b1d2-36135b29d746@citrix.com>
 <a6c3be0b-35f4-8d23-4ea2-ead94a3fc69e@oracle.com>
 <b9fdc3ec-87cd-da0e-47b7-67cdae8ffb97@oracle.com>
 <20171017052413.nzbqniurzw7eim4b@treble>
 <de621b0b-f767-222a-e1de-aabd0e9a0bf9@oracle.com>
 <20171017143613.6i7auk3mqcqayx3o@treble>
 <2e7890fb-3634-0f3b-003f-fc1772504b9a@oracle.com>
 <20171017201743.tnw6wulu4gjvkqli@treble>
 <44a2cbeb-7424-0a2a-7f9c-b669e049bded@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <44a2cbeb-7424-0a2a-7f9c-b669e049bded@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.39]); Tue, 17 Oct 2017 20:50:40 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Oct 17, 2017 at 04:36:00PM -0400, Boris Ostrovsky wrote:
> On 10/17/2017 04:17 PM, Josh Poimboeuf wrote:
> > 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?
> >
> 
> Don't you need to know the size of the instruction without save and
> restore part?
> 
> + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15)
> 
> Otherwise you'd need another field for the actual instruction length.

If we know where the CALL instruction starts, and can verify that it
starts with "ff 15", then we know the instruction length: 6 bytes.
Right?

-- 
Josh