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;
Date:   Thu, 23 Sep 2021 08:48:43 -0700 (PDT)
From:   Stefano Stabellini <sstabellini@kernel.org>
To:     Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
cc:     Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
        "julien@xen.org" <julien@xen.org>,
        "jbeulich@suse.com" <jbeulich@suse.com>,
        Oleksandr Andrushchenko <andr2000@gmail.com>
Subject: Re: [PATCH 2/2] xen-pciback: prepare for the split for stub and PV
In-Reply-To: <98e432f0-6be1-6394-1c06-ac5e726c708d@epam.com>
Message-ID: <alpine.DEB.2.21.2109230848290.17979@sstabellini-ThinkPad-T480s>
References: <20210922101422.2319240-1-andr2000@gmail.com> <20210922101422.2319240-2-andr2000@gmail.com> <alpine.DEB.2.21.2109221407350.17979@sstabellini-ThinkPad-T480s> <4552e4b6-21a8-4829-16b4-7cda8ba0c0d1@epam.com> <7880dee9-7372-5a25-db55-018f21e8b08c@suse.com>
 <98e432f0-6be1-6394-1c06-ac5e726c708d@epam.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1873022447-1632412124=:17979"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1873022447-1632412124=:17979
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> On 23.09.21 12:05, Juergen Gross wrote:
> > On 23.09.21 11:02, Oleksandr Andrushchenko wrote:
> >>
> >> On 23.09.21 00:10, Stefano Stabellini wrote:
> >>> On Wed, 22 Sep 2021, Oleksandr Andrushchenko wrote:
> >>>> --- a/drivers/xen/xen-pciback/xenbus.c
> >>>> +++ b/drivers/xen/xen-pciback/xenbus.c
> >>>> @@ -743,6 +743,9 @@ const struct xen_pcibk_backend *__read_mostly xen_pcibk_backend;
> >>>>       int __init xen_pcibk_xenbus_register(void)
> >>>>    {
> >>>> +    if (!xen_pcibk_pv_support())
> >>>> +        return 0;
> >>> Is this truly enough to stop the PV backend from initializing? Have you
> >>> actually tested it to make sure? If it works, amazing! I am quite happy
> >>> about this approach :-)
> >>
> >> Well, I put some logs into the driver and saw nothing obvious pointing
> >>
> >> to any backend activities (probably this is also because I don't have any
> >>
> >> frontend). I see that the xenbus driver is not registered. In XenStore I see:
> >>
> >> root@dom0:~# xenstore-ls -f | grep pci
> >> /local/domain/0/backend/pci = ""
> >> /local/domain/0/backend/pci/2 = ""
> >> /local/domain/0/backend/pci/2/0 = ""
> >> /local/domain/0/backend/pci/2/0/frontend = "/local/domain/2/device/pci/0"
> >> /local/domain/0/backend/pci/2/0/frontend-id = "2"
> >> /local/domain/0/backend/pci/2/0/online = "1"
> >> /local/domain/0/backend/pci/2/0/state = "1"
> >> /local/domain/0/backend/pci/2/0/domain = "DomU"
> >> /local/domain/0/backend/pci/2/0/key-0 = "0000:03:00.0"
> >> /local/domain/0/backend/pci/2/0/dev-0 = "0000:03:00.0"
> >> /local/domain/0/backend/pci/2/0/opts-0 = "msitranslate=0,power_mgmt=0,permissive=0,rdm_policy=strict"
> >> /local/domain/0/backend/pci/2/0/state-0 = "1"
> >> /local/domain/0/backend/pci/2/0/num_devs = "1"
> >> /local/domain/2/device/pci = ""
> >> /local/domain/2/device/pci/0 = ""
> >> /local/domain/2/device/pci/0/backend = "/local/domain/0/backend/pci/2/0"
> >> /local/domain/2/device/pci/0/backend-id = "0"
> >> /local/domain/2/device/pci/0/state = "1"
> >> /libxl/pci = ""
> >> /libxl/pci/0000-03-00-0 = ""
> >> /libxl/pci/0000-03-00-0/domid = "2"
> >>
> >> But IIUIC these come from the toolstack
> >>
> >> @Juergen, do you know how to check if the backend is indeed not running
> >>
> >> or the above should be enough to prove?
> >
> > I don't see how the backend could be running without being registered
> > with xenbus. It won't receive any watches, so there is no way a
> > connection with a frontend could be established.
> 
> This is my understanding too, so the only change I've put in patch I removed
> 
> register/unregister. It seems this is just enough and the patch should be ok as is

Fantastic! Thanks for checking.
--8323329-1873022447-1632412124=:17979--