[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/2] xen-pciback: prepare for the split for stub and PV


  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>, Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 27 Sep 2021 09:48:53 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4rwhkrQJ9kLkgjnOKQPT+JHOelIXQyjB/Af+cIBoY/g=; b=Ui9Mpp6RIXpW81lQegAykOes9pw0Iiqz51xWzponhwScX49iPEN8C/1H9+q/JzHowXYG16X7+pXEX2MnsAxuhI6KTy6ekbVQVEmf7FSg87lDTHEmFitCorW9973C2T3SIFGZxHwEHnzUZGSWVtoJ4PDQPrRtq95w4g8Vx49uBMQOSSEUcuY8YSekKRiuMGMyRWSTqhMb2uV9mfMoUmNht/R2S1ksQIxfZriMI2FEFWW/tikIqAbtjIYZEJ5OhGdJsRZHITSnDx2mBuJJS+BMsC1P3VVsS62gJGh4x7N0SbpwZZAhw1qDyW1iHKWgVNE2xJSvChvyAI5jqoxmihulBA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kHi0XFL68jt+EhgIJVb+oysbP6DiqEkr59EOnu7SnCO48cWiGGoDqrGp5yXhr6ORc3Zgpf4DxSjDO+is6tnXbeUuM7+Wb8zMlTeEzKmDajF/Ss3KY30bgkwopQSjQXJiBa9UeHuFOX/J1YeLvaxronfDjfkwdLtlrR+TsU+fTL9/Cw4e23VFxpUoew9pqUROPAPdRm7DByKSD/LQPc9nxeR87ZDKrwUuDaZsj08hNaKw2HAQkKhw2Zf6jcnt9YQ3znMofxFP3VNJCYHjpukGanvnESkbQ5h8vTDV2R+SW/cLdOn56GxV54rSIxyfdtjjBMgLNSENvHmvUBKSpBJWnw==
  • Authentication-results: vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=none action=none header.from=suse.com;
  • Cc: "boris.ostrovsky@xxxxxxxxxx" <boris.ostrovsky@xxxxxxxxxx>, "jgross@xxxxxxxx" <jgross@xxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 27 Sep 2021 07:49:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.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@xxxxxxxx>
>>>
>>> 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@xxxxxxxx>
>>>
>>> ---
>>> 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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.