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=-7.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 442A1C433DB for ; Thu, 14 Jan 2021 15:30:53 +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 E77A42311F for ; Thu, 14 Jan 2021 15:30:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E77A42311F Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.67182.119673 (Exim 4.92) (envelope-from ) id 1l04aB-0001wf-5e; Thu, 14 Jan 2021 15:30:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 67182.119673; Thu, 14 Jan 2021 15:30:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l04aB-0001wV-1m; Thu, 14 Jan 2021 15:30:43 +0000 Received: by outflank-mailman (input) for mailman id 67182; Thu, 14 Jan 2021 15:30:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l04a9-0001wA-MM for xen-devel@lists.xenproject.org; Thu, 14 Jan 2021 15:30:41 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9b7253e1-561c-48cc-b76d-18b4d47ef2fe; Thu, 14 Jan 2021 15:30:40 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BC58FAEBB; Thu, 14 Jan 2021 15:30:39 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9b7253e1-561c-48cc-b76d-18b4d47ef2fe X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1610638239; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v8Aat2KhZGVzT89vwbz4h58pWI6a2e3d1PUhq1Gw6e4=; b=hglrONKNCjg1WrHi3yFW1jeKzkB+ODflaT2KK9nOkh2ZORyNF5Ag7ZQvzvyMkvsmMkHQ7E TGPUnkA6pJBSccas78TfBSZBi0Oo5deLlNFXlu1Qv4VVWgUKAZj0bXk8ZwS42/7Dx0lM+H egjra8qtvH/DhiOV/DqHY6XKI1TtVmE= Subject: Re: [PATCH] common: don't require use of DOMID_SELF To: Julien Grall Cc: Andrew Cooper , George Dunlap , Ian Jackson , Stefano Stabellini , Wei Liu , "xen-devel@lists.xenproject.org" References: <72c9f0ec-81e3-63f9-2513-46e463642219@suse.com> <6b80d9bd-58a1-0854-2ff9-7153ddecae26@xen.org> From: Jan Beulich Message-ID: Date: Thu, 14 Jan 2021 16:30:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <6b80d9bd-58a1-0854-2ff9-7153ddecae26@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 14.01.2021 15:43, Julien Grall wrote: > On 14/01/2021 14:02, Jan Beulich wrote: >> It's not overly difficult for a domain to figure out its ID, so >> requiring the use of DOMID_SELF in a very limited set of places isn't >> really helpful towards keeping the ID opaque to the guest. > > So I agree that a domid can be figured out really easily today and in > principle it would be fine to relax it. > > However, most of the guest OSes will care about running on older Xen > versions. Therefore they are not going to be able to use this relaxation. > > So I am not entirely convinced the relaxation is actually worth it for > existing hypercalls. I'm aware of the concern (Andrew has voiced it both here and in earlier contexts), but personally I think undue restrictions should not be retained just because they used to be enforced. We've gone this same route in a few other occasions not overly long ago, and iirc there are two patches going in a similar direction (different area of course) that I have still pending and which neither got ack-ed nor firmly rejected. > Anyway, if we decide to relax it, then I think we should update the > public headers because an OS using this relaxation will not work on > older Xen. A developper will not be able to know that without looking at > the implementation. Well, DOMID_SELF exists because that's the preferred form to use. I can certainly add commentary, but it would feel a little odd to do so. To be honest I'm also not sure how helpful this is going to be, considering that consumers often have their own clones of our headers. Jan