Message-ID: <5555D26B.8040002@oracle.com>
Date: Fri, 15 May 2015 19:03:07 +0800
From: Bob Liu <bob.liu@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
CC: xen-devel@lists.xen.org, david.vrabel@citrix.com, justing@spectralogic.com,
        konrad.wilk@oracle.com, paul.durrant@citrix.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] driver: xen-blkfront: move talk_to_blkback to the
 correct place
References: <1431428504-6623-1-git-send-email-bob.liu@oracle.com> <5555C3DE.7090603@citrix.com>
In-Reply-To: <5555C3DE.7090603@citrix.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3069
Lines: 75


On 05/15/2015 06:01 PM, Roger Pau Monn? wrote:
> El 12/05/15 a les 13.01, Bob Liu ha escrit:
>> The right place for talk_to_blkback() to query backend features and transport
>> parameters is after backend entered XenbusStateInitWait. There is no problem
> 
> talk_to_blkback doesn't gather any backend features, it just publishes
> the features supported by the frontend, which AFAICT can be done at any

1) But talk_tlkback will also allocate and initialize the request ring which
should be done after backend entered XenbusStateInitWait.

Please see the protocol defined in xen/include/public/io/blkif.h:
 *****************************************************************************
 *                                   Startup                                 *
 *****************************************************************************
 *
 * Tool stack creates front and back nodes with state XenbusStateInitialising.
 *
 * Front                                Back
 * =================================    =====================================
 * XenbusStateInitialising              XenbusStateInitialising
 *  o Query virtual device               o Query backend device identification
 *    properties.                          data.
 *  o Setup OS device instance.          o Open and validate backend device.
 *                                       o Publish backend features and
 *                                         transport parameters.
 *                                                      |
 *                                                      |
 *                                                      V
 *                                      XenbusStateInitWait
 *
 * o Query backend features and
 *   transport parameters.
 * o Allocate and initialize the
 *   request ring.


2) Another problem is after 'mutli-page' ring feature get introduced, we have to know the max
ring pages supported by backend in setup_blkring().
If backend haven't enter XenbusStateInitWait, we may not query the right value. E.g.

Frontend                                          Backend

in .probe:
talk_to_blkback()
 > setup_blkring()
  > xenbus_scanf(max_ring_pages)


                                               in .probe:
                                               xenbus_printf(max_ring_pages)
                                               ^^^^ Too late to write the real value
                                               xenbus_switch_state(dev, XenbusStateInitWait)


Thank you reviewing these patches!

Regards,
-Bob

> time provided that it's before switching to state XenbusStateInitWait.
> Blkfront doesn't have to wait for the backend to switch to state
> XenbusStateInitWait before publishing the features supported by the
> frontend, which is what talk_to_blkback does.
> 
> Roger.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/