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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id DA1A2C61DA4 for ; Thu, 16 Mar 2023 00:26:44 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.510272.787626 (Exim 4.92) (envelope-from ) id 1pcbS0-0001qF-FX; Thu, 16 Mar 2023 00:26:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 510272.787626; Thu, 16 Mar 2023 00:26:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pcbS0-0001q8-Cu; Thu, 16 Mar 2023 00:26:36 +0000 Received: by outflank-mailman (input) for mailman id 510272; Thu, 16 Mar 2023 00:26:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pcbRz-0001q2-V4 for xen-devel@lists.xenproject.org; Thu, 16 Mar 2023 00:26:35 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 339d3172-c391-11ed-b464-930f4c7d94ae; Thu, 16 Mar 2023 01:26:33 +0100 (CET) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D234961ECD; Thu, 16 Mar 2023 00:26:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40167C433D2; Thu, 16 Mar 2023 00:26:29 +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: 339d3172-c391-11ed-b464-930f4c7d94ae DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678926391; bh=F3MVPAsyb9tcMQwtfiYeo9NnzGay0xIBRkQnoKDogEY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LqWYyZ/aNtPS0UvSxbeHqqtZz+RHpsH1QCg3HkhSr3ZYAPZfNzvRhniTx8ttCTktc AtbwijLdvrl26A7R8MEcgen83Hwvd+cxRkrSjrs1P8dSaeU/JI/OrVf3Yc86qYGRH2 kGgBR0cfvgGERzsx+IvnY8ywTSnFLlLaHuDeSUx2zfqq2wcrdmIZeqHnMCqfSoAH4l qaONEqA4x6pAyVx0M7ANiLOWtyHdA4e5O514lJibVleeNdQ0S7GAbTX+UMT1cNyqXM oBpSboAuKvUQt7KfrnWRkuNt9u7DltKwFBa+JyQlCBw413EHgJUFppnJbV1yC3kosk SssaZfPbvP2ZA== Date: Wed, 15 Mar 2023 17:26:27 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Jan Beulich , Huang Rui , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , Stewart Hildebrand , Xenia Ragiadakou , Honglei Huang , Julia Zhang , Chen Jiqian , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Anthony PERARD , xen-devel@lists.xenproject.org Subject: Re: [RFC XEN PATCH 4/6] x86/pvh: PVH dom0 also need PHYSDEVOP_setup_gsi call In-Reply-To: <521ccacd-a45a-f55a-72ed-de6b64bca050@citrix.com> Message-ID: References: <20230312075455.450187-1-ray.huang@amd.com> <20230312075455.450187-5-ray.huang@amd.com> <521ccacd-a45a-f55a-72ed-de6b64bca050@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 15 Mar 2023, Andrew Cooper wrote: > On 14/03/2023 4:30 pm, Jan Beulich wrote: > > On 12.03.2023 08:54, Huang Rui wrote: > >> From: Chen Jiqian > > An empty description won't do here. First of all you need to address the Why? > > As already hinted at in the reply to the earlier patch, it looks like you're > > breaking the intended IRQ model for PVH. > > I think this is rather unfair. > > Until you can point to the document which describes how IRQs are > intended to work in PVH, I'd say this series is pretty damn good attempt > to make something that functions, in the absence of any guidance. And to make things more confusing those calls are not needed for PVH itself, those calls are needed so that we can run QEMU to support regular HVM guests on PVH Dom0 (I'll let Ray confirm.) So technically, this is not breaking the PVH IRQ model.