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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99C8AC433DF for ; Thu, 2 Jul 2020 08:29:49 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7680F20720 for ; Thu, 2 Jul 2020 08:29:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7680F20720 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jquas-0003Xd-Gu; Thu, 02 Jul 2020 08:29:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jquar-0003XY-4g for xen-devel@lists.xenproject.org; Thu, 02 Jul 2020 08:29:17 +0000 X-Inumbo-ID: 1d808780-bc3e-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1d808780-bc3e-11ea-bca7-bc764e2007e4; Thu, 02 Jul 2020 08:29:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6EF7FADC1; Thu, 2 Jul 2020 08:29:15 +0000 (UTC) Subject: Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature To: Julien Grall References: <7302dbfcd07dfaad9e50bb772673e588fcc4de67.1593519420.git.michal.leszczynski@cert.pl> <85416128-a334-4640-7504-0865f715b3a2@xen.org> <48c59780-bedb-ff08-723c-be14a9b73e6b@citrix.com> <95154add-164a-5450-28e1-f24611e1642f@xen.org> From: Jan Beulich Message-ID: <8df16863-2207-6747-cf17-f88124927ddb@suse.com> Date: Thu, 2 Jul 2020 10:29:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Ian Jackson , George Dunlap , Jun Nakajima , xen-devel@lists.xenproject.org, luwei.kang@intel.com, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01.07.2020 20:09, Julien Grall wrote: > On 01/07/2020 19:06, Andrew Cooper wrote: >> On 01/07/2020 19:02, Julien Grall wrote: >>> On 01/07/2020 18:26, Andrew Cooper wrote: >>>> For the sake of what is literally just one byte in common code, I stand >>>> my original suggestion of this being a common interface.  It is not >>>> something which should be x86 specific. >>> >>> This argument can also be used against putting in common code. What I >>> am the most concern of is we are trying to guess how the interface >>> will look like for another architecture. Your suggested interface may >>> work, but this also may end up to be a complete mess. >>> >>> So I think we want to wait for a new architecture to use vmtrace >>> before moving to common code. This is not going to be a massive effort >>> to move that bit in common if needed. >> >> I suggest you read the series. > > Already went through the series and ... > >> >> The only thing in common code is the bit of the interface saying "I'd >> like buffers this big please". > > ... I stand by my point. There is no need to have this code in common > code until someone else need it. This code can be easily implemented in > arch_domain_create(). I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. For example, unless there is proof that for all architectures of interest currently or in the not too distant future an order value is fine (as opposed to a size one), then an order field would be fine to live in common code imo. Otherwise it would need to be a size one, with per-arch enforcement of further imposed restrictions (like needing to be a power of 2). Jan