From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0CB8BC19F21 for ; Thu, 4 Aug 2022 19:04:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238773AbiHDTEY (ORCPT ); Thu, 4 Aug 2022 15:04:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232290AbiHDTEV (ORCPT ); Thu, 4 Aug 2022 15:04:21 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52D5B6D56D for ; Thu, 4 Aug 2022 12:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659639860; x=1691175860; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Zeb314LA7OHiqwgRSF20NPO4aqmgQgIU8MCpZ86Aap4=; b=ebEnk0CnjVLeS6AvNn6u0YCpN4GtqebTv6I1ocZSlrnc2g+jLOVs0x9Y M7V1YPSCySseIaHkLpDWvEbdCHiJMDYfQ1kBtfqyP1oeKyLN5XeBhs193 OXDSDW61wiSqTR+jI87bKJ7V+ucayXftMDOjhAxgF8E/ZgGMyh6YgIjyI x3tFqcqoWB2mf0XXaC+//7LPwDpDC8gectBVK4nxAWWvvksONPGNliceR JXMLMjZs0B/PHc9cKwn8jBwfzL7ewQyzGlGaxBvO+0TDCywS1OTYLIzOR Z+pHHe7XJW1pE8ZZ431OYHcT3qKDSKC7Pdb/QNcUDa29/39h6J+w+rLDT w==; X-IronPort-AV: E=McAfee;i="6400,9594,10429"; a="270404358" X-IronPort-AV: E=Sophos;i="5.93,216,1654585200"; d="scan'208";a="270404358" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2022 12:03:57 -0700 X-IronPort-AV: E=Sophos;i="5.93,216,1654585200"; d="scan'208";a="631709547" Received: from lnavery-mobl1.amr.corp.intel.com (HELO [10.255.228.146]) ([10.255.228.146]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2022 12:03:56 -0700 Message-ID: <6c516a7c-ac97-e0b1-b056-06a17d1b7420@intel.com> Date: Thu, 4 Aug 2022 12:03:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] x86/acrn: Improve ACRN hypercalls Content-Language: en-US To: Uros Bizjak Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" References: <20220804180358.32944-1-ubizjak@gmail.com> <91ccae0b-6135-6163-f59b-4e99624090a5@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/4/22 11:56, Uros Bizjak wrote: > The %r8 is not preserved across function calls, so your statement > above is correct. But as long as there is no function call *between* > the variable definition and the assembly, the approach with the local > register variable works without any problems. It is even something GCC > itself has used in its library for years. I'm glad it's workout out for GCC. But, the kernel is not GCC. I specifically asked for the ACRN code to be the way that it is today and your argument is not making me reconsider it in the slightest. So, thanks for the patch, but I don't think we should apply it.