From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764293AbdJQU77 (ORCPT ); Tue, 17 Oct 2017 16:59:59 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25441 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756732AbdJQU75 (ORCPT ); Tue, 17 Oct 2017 16:59:57 -0400 Subject: Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure To: Josh Poimboeuf References: <5a49e43a-8d6b-512a-ec5a-641be7bae41d@oracle.com> <20171017052413.nzbqniurzw7eim4b@treble> <20171017143613.6i7auk3mqcqayx3o@treble> <2e7890fb-3634-0f3b-003f-fc1772504b9a@oracle.com> <20171017201743.tnw6wulu4gjvkqli@treble> <44a2cbeb-7424-0a2a-7f9c-b669e049bded@oracle.com> <20171017205037.rnqto2i2hul4q2s4@treble> 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 From: Boris Ostrovsky Message-ID: <5f62f099-c773-ae64-d685-f6db77406020@oracle.com> Date: Tue, 17 Oct 2017 16:59:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171017205037.rnqto2i2hul4q2s4@treble> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/17/2017 04:50 PM, Josh Poimboeuf wrote: > 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? > Oh, OK. Then you shouldn't need a->replacementlen test(s?) in apply_alternatives()? -boris