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

Re: [PATCH] drivers/xen: Improve the late XenStore init protocol


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Henry Wang <xin.wang2@xxxxxxx>
  • Date: Fri, 17 May 2024 09:17:43 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Kp85KC0psuXALGt1cPe+mlXd7lcMqilrHi8mw7kjljQ=; b=PeEQBbpWtWNRLigApQDsH77U5eonflQ7bbYX++NCiWED+FRfsC/1OpNdA2DyQ4zPVVNPwgtw/Kt6vqkXRlV7RsXA+0f/Kn+SuXydLXTDYQxzVo56pbmFkc7hoiSH7YC8AH1CjhUOrIfA70tsZKmwFq6+4kpc5G0KuTXYwP9oort+RRdXOHxmOIK+zqDGul4hTbND/WpAitWW+1n5nd0xgqaJBbJVqgjLwwRGNLzitw8Cx5isSiSUUFWEK4/k5x8hWj+m3dMw1lo+JyT4JHv/rwAcf0tyGwqz17gHbv8OAdHyVoI4KV8ezAQm4rph49dccgir4zLiTfPM9+3mtFK2gg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bs/Q2jv0yG8Cn7b+ptGujytF/rTmER1KRPEPyDGmxgmaNf8utFBfLzP+zhX6knag0xmb5L/cZ0xVIp5z15HKxC5uZuaZd2R5PhVPHx3ztQNLSG/tnWmUQQAV3qHQLnmwFPUGqJvB3MXENzoqro9I6JkYkcAfo8GZwSR9SJHPk2wcV8I0KFw+lB0cihQyc0jqhMZUSCiKryeHmFK93dRBYy48NsfY5jlermTP5lP4HjhlsCeJyDYVq1lUVRIy9mmhpea1vUn4w+ecZ0Sdznie/KYVwPz86L50tI5Nxl7gynSP1VthMpbKgjPkvUWaBjqUhNP664R+GzrkYycVKioe8Q==
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, "Juergen Gross" <jgross@xxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Fri, 17 May 2024 01:17:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Stefano,

On 5/17/2024 8:52 AM, Stefano Stabellini wrote:
On Thu, 16 May 2024, Henry Wang wrote:
   enum xenstore_init xen_store_domain_type;
   EXPORT_SYMBOL_GPL(xen_store_domain_type);
   @@ -751,9 +755,10 @@ static void xenbus_probe(void)
   {
        xenstored_ready = 1;
   -    if (!xen_store_interface) {
-               xen_store_interface = memremap(xen_store_gfn <<
XEN_PAGE_SHIFT,
-                                              XEN_PAGE_SIZE, MEMREMAP_WB);
+       if (!xen_store_interface || XS_INTERFACE_READY) {
+               if (!xen_store_interface)
These two nested if's don't make sense to me. If XS_INTERFACE_READY
succeeds, it means that  ((xen_store_interface != NULL) &&
(xen_store_interface->connection == XENSTORE_CONNECTED)).

So it is not possible that xen_store_interface == NULL immediately
after. Right?
I think this is because we want to free the irq for the late init case,
otherwise the init-dom0less will fail. For the xenstore PFN allocated case,
the connection is already set to CONNECTED when we execute init-dom0less. But
I agree with you, would below diff makes more sense to you?

diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 8aec0ed1d047..b8005b651a29 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -76,6 +76,8 @@ EXPORT_SYMBOL_GPL(xen_store_interface);
         ((xen_store_interface != NULL) && \
          (xen_store_interface->connection == XENSTORE_CONNECTED))

+static bool xs_late_init = false;
+
  enum xenstore_init xen_store_domain_type;
  EXPORT_SYMBOL_GPL(xen_store_domain_type);

@@ -755,7 +757,7 @@ static void xenbus_probe(void)
  {
         xenstored_ready = 1;

-       if (!xen_store_interface || XS_INTERFACE_READY) {
+       if (xs_late_init) {
                 if (!xen_store_interface)
                         xen_store_interface = memremap(xen_store_gfn <<

I would just remove the outer 'if' and do this:


        if (!xen_store_interface)
                xen_store_interface = memremap(xen_store_gfn << XEN_PAGE_SHIFT,
                                XEN_PAGE_SIZE, MEMREMAP_WB);
        /*
         * Now it is safe to free the IRQ used for xenstore late
         * initialization. No need to unbind: it is about to be
         * bound again from xb_init_comms. Note that calling
         * unbind_from_irqhandler now would result in xen_evtchn_close()
         * being called and the event channel not being enabled again
         * afterwards, resulting in missed event notifications.
         */
        if (xs_init_irq > 0)
                free_irq(xs_init_irq, &xb_waitq);


I think this should work fine in all cases.

Thanks. I followed your suggestion in v2.

  I am unsure if
xs_init_irq==0 is possible valid value for xs_init_irq. If it is not,
then we are fine. If 0 is a possible valid irq number, then we should
initialize xs_init_irq to -1, and here check for xs_init_irq >= 0.

Yeah the xs_init_irq==0 is a valid value. I followed your latter comment to init it to -1 and check it >=0.

Kind regards,
Henry



 


Rackspace

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