Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v4 1/2] xen-pciback: prepare for the split for stub and PV
To:     Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
        Oleksandr Andrushchenko <andr2000@gmail.com>
Cc:     "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
        "jgross@suse.com" <jgross@suse.com>,
        "julien@xen.org" <julien@xen.org>,
        "sstabellini@kernel.org" <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20210927065822.350973-1-andr2000@gmail.com>
 <e472468a-625e-6c4d-a9c2-85594e2ff908@suse.com>
 <accd0220-a9d7-145b-6632-9dee085ffc65@epam.com>
From:   Jan Beulich <jbeulich@suse.com>
Message-ID: <750b9449-c986-025d-9b68-dd0f6967b083@suse.com>
Date:   Mon, 27 Sep 2021 09:48:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
In-Reply-To: <accd0220-a9d7-145b-6632-9dee085ffc65@epam.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?czVoMkpiM0NUTlVqODRjWHBhOXpRN3MycENwMU9ZeFBra25BcC9pU1FOSnl1?=
 =?utf-8?B?QXNQeDZHbUxScFQwTmZHcGJrZFRuaEVSZmZvVFg2N256cTVHVncrMlhhd29p?=
 =?utf-8?B?cmh2bGRxaHdQcWJ1UTA0QmVNMHZkUW5EaHBBU0ZTdmpYc0RZa2lRV21YRUhG?=
 =?utf-8?B?Q2JmcVVFaDAvSzQ5L2JRRkthcWM5bENEWkt0bmczdGxiZGFsenlXTStEZUZy?=
 =?utf-8?B?cE1BZzJrb0xmR1YzRmxMQ0k2RklGWGxpSVR2dU9QWGQwMytiV1REc3JGUzNo?=
 =?utf-8?B?d3VsTktLOVJtU1FqVm5tSjRqUnRFTDVvZVpwcTRuSGRqMXR4T3RGeWlzMDdE?=
 =?utf-8?B?eEJud2ZIejUzQzhhQ0cyUVZQTEVmQUJVN0NTdEpGWWJjaUNRTi9lTDJobXpw?=
 =?utf-8?B?RThSUzJVeVQrWXdtdWxWN2JhbVBVUVNrN1hQa095MjZaZmNxNVI5ZlN0NkZm?=
 =?utf-8?B?RUR2N1hyVUkxeDdKMnBVT01YV1htUXpNSDZxZGtxN2dBbUxuQkQ0K1JXWWdi?=
 =?utf-8?B?Nm5VanE4Yld0c2JLSjhpTmJBVkhLNUgyV0IrNEdZWEVhc2RvZGwzYUZqY1ZI?=
 =?utf-8?B?Q25jbTZiVkUrUFFEV1draW0wWW4xWDVEbW5LUE5WbHZRcGZFRmN0Q29hWlhv?=
 =?utf-8?B?K21USHlIVmx2Sllncm1MZkJEQzJnTi9oVXdnUit5bjRTdVNPUjZBWERZL0NT?=
 =?utf-8?B?M1RsRkt0cHA1YnErelJCb0NzRzZ4aHFGeDY4a244eHZTTkVTL2tyY2I2NzJx?=
 =?utf-8?B?dVBzSzVSS1c0SWlPajhJVnRIWU5zN0c0U29mTVlFVFUvckIvdlNUZVZ0SHlz?=
 =?utf-8?B?R2hra2pOcjBXaGpFaVFwcnAyemI2VzdncUpsK3p2dVNYZmFIVjVVNWhPS2sx?=
 =?utf-8?B?SEdSditiSW9HN2NTY200dzJJTU5kdHpKandxN0UvY2FPVE5COHFwekxhN3Rq?=
 =?utf-8?B?ZDJDUTlLMWpwamJ3a25SZWN5dWU1ZkRFWFM1R0hNNTFpQUV4d09VaGs4ckF1?=
 =?utf-8?B?Ykt1U2QwR3NQV3puMjRaSFNpVmdqZitEVFh4TVZYdWJXTytDYjR6Y25rSmRw?=
 =?utf-8?B?WWw2QkFTcGxhK3lmYXlHS0ZaYmlFdjkzTU9QOGgzZjNzVmFPdnE3QkNGeFky?=
 =?utf-8?B?SFI5U29aNGRBRi85ZmthckJVWmRwMjYwNkJ1V0xQQ20vWENzQzNjL3RUTDE5?=
 =?utf-8?B?VzhVdHEwRUhabGVhUW5PSEJGYXp3bkgzRmd5L1htdUdKTThtSzR4UWlKVWJZ?=
 =?utf-8?B?aUk0YjFhZEZsRnF5ZkV6UWs2R1NTejlmejlKWkN4NmhlRzBDZ2FOMGVkVWxo?=
 =?utf-8?B?TGJNMlR3dzBKdkx3TnBXY3FWVS9LY3c5WEFMS3gyWWYwNnJTSWxnVWwzNDdo?=
 =?utf-8?B?c3dxSXdwRk1abXNYbUczMXdkM2FDK3lMa0U2QVRyUjEyTktnTWdPRzZReWNV?=
 =?utf-8?B?a1VnWWdLeG9KSDBSd29aTHFNaVk0b2tmMTUzenBpNkx4OVZMdlBOSEZuTzNP?=
 =?utf-8?B?bndTWnMwS00zbnFOWjcvNW14UVJsSHhUTC81RWxrc0l0M21CK0cwZS81OElh?=
 =?utf-8?B?dVdnci8zTDlGVzJka1pMOCtXb0NkS0pVTjY5aTl6T3Q1a0JWY0ZiV2huek5m?=
 =?utf-8?B?Z00zMDRvQ0NPeXMxT2ZOVERpZUFsSzdnRGV3YSsxY1lic0JZWkVVYWpoOEFT?=
 =?utf-8?B?bS9hUUZPSHp4OWJ3dW5ENEp5V2ZNVEhSQ3N3R05jWWNGWUx4T1FsdjZnSlow?=
 =?utf-8?Q?EKWNPoY/xEJEs/k5iHplfnSdXoNG/d/UX6Ux6b0?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c2da389-15c7-47f3-0484-08d9818b3fe9
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5600.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2021 07:48:52.3338
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: HuPWozKGCjYH1uF+sFOYQCrcCyvu3rNSEKI9cIt+99T+ZGtl4v7dPPnrFFMhkPXqYGb2cFuY3mDZe4RSzQ7MPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7024
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 27.09.2021 09:35, Oleksandr Andrushchenko wrote:
> 
> On 27.09.21 10:26, Jan Beulich wrote:
>> On 27.09.2021 08:58, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> Currently PCI backend implements multiple functionalities at a time.
>>> To name a few:
>>> 1. It is used as a database for assignable PCI devices, e.g. xl
>>>     pci-assignable-{add|remove|list} manipulates that list. So, whenever
>>>     the toolstack needs to know which PCI devices can be passed through
>>>     it reads that from the relevant sysfs entries of the pciback.
>>> 2. It is used to hold the unbound PCI devices list, e.g. when passing
>>>     through a PCI device it needs to be unbound from the relevant device
>>>     driver and bound to pciback (strictly speaking it is not required
>>>     that the device is bound to pciback, but pciback is again used as a
>>>     database of the passed through PCI devices, so we can re-bind the
>>>     devices back to their original drivers when guest domain shuts down)
>>> 3. Device reset for the devices being passed through
>>> 4. Para-virtualised use-cases support
>>>
>>> The para-virtualised part of the driver is not always needed as some
>>> architectures, e.g. Arm or x86 PVH Dom0, are not using backend-frontend
>>> model for PCI device passthrough. For such use-cases make the very
>>> first step in splitting the xen-pciback driver into two parts: Xen
>>> PCI stub and PCI PV backend drivers.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> ---
>>> Changes since v3:
>>> - Move CONFIG_XEN_PCIDEV_STUB to the second patch
>> I'm afraid this wasn't fully done:
>>
>>> --- a/drivers/xen/xen-pciback/Makefile
>>> +++ b/drivers/xen/xen-pciback/Makefile
>>> @@ -1,5 +1,6 @@
>>>   # SPDX-License-Identifier: GPL-2.0
>>>   obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback.o
>>> +obj-$(CONFIG_XEN_PCIDEV_STUB) += xen-pciback.o
>> While benign when added here, this addition still doesn't seem to
>> belong here.
> 
> My bad. So, it seems without CONFIG_XEN_PCIDEV_STUB the change seems
> 
> to be non-functional. With CONFIG_XEN_PCIDEV_STUB we fail to build on 32-bit
> 
> architectures...
> 
> What would be the preference here? Stefano suggested that we still define
> 
> CONFIG_XEN_PCIDEV_STUB, but in disabled state, e.g. we add tristate to it
> 
> in the second patch
> 
> Another option is just to squash the two patches.

I'd suggest to do so, but I'm not the maintainer of this code.

Jan