xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Anthony PERARD <anthony.perard@citrix.com>
To: Emil Condrea <emilcondrea@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	wei.liu2@citrix.com, stefanb@linux.vnet.ibm.com,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	quan.xu@intel.com, dgdegra@tycho.nsa.gov, eblake@redhat.com
Subject: Re: [PATCH 15/19] Qemu-Xen-vTPM: Xen frontend driver infrastructure
Date: Mon, 25 Jul 2016 17:01:40 +0100	[thread overview]
Message-ID: <20160725160140.GM1835@perard.uk.xensource.com> (raw)
In-Reply-To: <1468151270-12984-16-git-send-email-emilcondrea@gmail.com>

On Sun, Jul 10, 2016 at 02:47:46PM +0300, Emil Condrea wrote:
> This patch adds infrastructure for xen front drivers living in qemu,
> so drivers don't need to implement common stuff on their own.  It's
> mostly xenbus management stuff: some functions to access XenStore,
> setting up XenStore watches, callbacks on device discovery and state
> changes, and handle event channel between the virtual machines.
> 
> Call xen_fe_register() function to register XenDevOps, and make sure,
> XenDevOps's flags is DEVOPS_FLAG_FE, which is flag bit to point out
> the XenDevOps is Xen frontend.
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> Signed-off-by: Emil Condrea <emilcondrea@gmail.com>
> 
> ---
> Changes in v9:
>  * xenstore_dev should not be global, it will not work correctly with
> multiple xen frontends living in qemu
>  * reuse some common functions:
>     - xen_fe_printf -> xen_pv_printf
>     - xen_fe_evtchn_event -> xen_pv_evtchn_event
>  * use libxenevtchn stable API instead of xc_* calls:
>     - xc_evtchn_fd -> xenevtchn_fd
>     - xc_evtchn_close -> xenevtchn_close
>     - xc_evtchn_bind_unbound_port -> xenevtchn_bind_unbound_port
> ---
>  hw/xen/xen_frontend.c         | 308 ++++++++++++++++++++++++++++++++++++++++++
>  hw/xen/xen_pvdev.c            |  15 ++
>  include/hw/xen/xen_frontend.h |   6 +
>  include/hw/xen/xen_pvdev.h    |   1 +
>  4 files changed, 330 insertions(+)
> 
> diff --git a/hw/xen/xen_frontend.c b/hw/xen/xen_frontend.c
> index 6b92cf1..7b305ce 100644
> --- a/hw/xen/xen_frontend.c
> +++ b/hw/xen/xen_frontend.c
> @@ -3,6 +3,10 @@
>   *
>   *  (c) 2008 Gerd Hoffmann <kraxel@redhat.com>
>   *
> + *  Copyright (c) 2015 Intel Corporation
> + *  Authors:
> + *    Quan Xu <quan.xu@intel.com>
> + *
>   * This library is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU Lesser General Public
>   * License as published by the Free Software Foundation; either
> @@ -23,6 +27,8 @@
>  #include "hw/xen/xen_frontend.h"
>  #include "hw/xen/xen_backend.h"
>  
> +static int debug = 0;
> +
>  char *xenstore_read_fe_str(struct XenDevice *xendev, const char *node)
>  {
>      return xenstore_read_str(xendev->fe, node);
> @@ -86,3 +92,305 @@ void xenstore_update_fe(char *watch, struct XenDevice *xendev)
>      xen_fe_frontend_changed(xendev, node);
>      xen_be_check_state(xendev);
>  }
> +
> +struct XenDevice *xen_fe_get_xendev(const char *type, int dom, int dev,
> +                                    char *backend, struct XenDevOps *ops)

This function looks similare to xen_be_get_xendev(), could they be
shared?

In any case, there is a few issue with this implementation.

> +{
> +    struct XenDevice *xendev;
> +
> +    xendev = xen_pv_find_xendev(type, dom, dev);
> +    if (xendev) {
> +        return xendev;
> +    }
> +
> +    /* init new xendev */
> +    xendev = g_malloc0(ops->size);
> +    xendev->type  = type;
> +    xendev->dom   = dom;
> +    xendev->dev   = dev;
> +    xendev->ops   = ops;
> +
> +    /*return if the ops->flags is not DEVOPS_FLAG_FE*/
> +    if (!(ops->flags & DEVOPS_FLAG_FE)) {

Here, xendev is leaked.

> +        return NULL;
> +    }
> +
> +    snprintf(xendev->be, sizeof(xendev->be), "%s", backend);
> +    snprintf(xendev->name, sizeof(xendev->name), "%s-%d",
> +             xendev->type, xendev->dev);
> +
> +    xendev->debug = debug;
> +    xendev->local_port = -1;
> +
> +    xendev->evtchndev = xenevtchn_open(NULL, 0);
> +    if (xendev->evtchndev == NULL) {
> +        xen_pv_printf(NULL, 0, "can't open evtchn device\n");
> +        g_free(xendev);

We could use goto here, so there would be only one cleanup path.

> +        return NULL;
> +    }
> +    fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> +
> +    if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
> +        xendev->gnttabdev = xengnttab_open(NULL, 0);
> +        if (xendev->gnttabdev == NULL) {
> +            xen_pv_printf(NULL, 0, "can't open gnttab device\n");
> +            xenevtchn_close(xendev->evtchndev);
> +            g_free(xendev);

goto, same as before.

> +            return NULL;
> +        }
> +    } else {
> +        xendev->gnttabdev = NULL;
> +    }
> +
> +    xen_pv_insert_xendev(xendev);
> +
> +    if (xendev->ops->alloc) {
> +        xendev->ops->alloc(xendev);
> +    }
> +
> +    return xendev;
> +}
> +
> +int xen_fe_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom){

'{' should be on a new line.

> +    xendev->local_port = xenevtchn_bind_unbound_port(xendev->evtchndev,
> +                                                     remote_dom);
> +    if (xendev->local_port == -1) {
> +        xen_pv_printf(xendev, 0, "xenevtchn_bind_unbound_port failed\n");
> +        return -1;
> +    }
> +    xen_pv_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> +    qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
> +                        xen_pv_evtchn_event, NULL, xendev);
> +    return 0;
> +}
> +
> +/*
> + * Make sure, initialize the 'xendev->fe' in xendev->ops->init() or
> + * xendev->ops->initialize()
> + */
> +int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)

There is a function that do a similar job for backends,
xen_be_set_state(). I think we could rename this function
xen_fe_set_state. Also "xbus" is a confusing name, "state" would be
fine.

> +{
> +    xs_transaction_t xbt = XBT_NULL;
> +
> +    if (xendev->fe_state == xbus) {
> +        return 0;
> +    }
> +
> +    xendev->fe_state = xbus;
> +    if (xendev->fe == NULL) {
> +        xen_pv_printf(NULL, 0, "xendev->fe is NULL\n");
> +        return -1;
> +    }
> +
> +retry_transaction:
> +    xbt = xs_transaction_start(xenstore);
> +    if (xbt == XBT_NULL) {
> +        goto abort_transaction;
> +    }

There is a transaction started, but I don't think it is used by the
function below. Could you remove the transaction?

> +    if (xenstore_write_int(xendev->fe, "state", xbus)) {
> +        goto abort_transaction;
> +    }
> +
> +    if (!xs_transaction_end(xenstore, xbt, 0)) {
> +        if (errno == EAGAIN) {
> +            goto retry_transaction;
> +        }
> +    }
> +
> +    return 0;
> +
> +abort_transaction:
> +    xs_transaction_end(xenstore, xbt, 1);
> +    return -1;
> +}
> +
> +/*
> + * Simplify QEMU side, a thread is running in Xen backend, which will
> + * connect frontend when the frontend is initialised. Call these initialised
> + * functions.
> + */

This comment does not make much sense to me.

> +static int xen_fe_try_init(void *opaque)
> +{
> +    struct XenDevOps *ops = opaque;
> +    int rc = -1;
> +
> +    if (ops->init) {
> +        rc = ops->init(NULL);
> +    }
> +
> +    return rc;
> +}
> +
> +static int xen_fe_try_initialise(struct XenDevice *xendev)
> +{
> +    int rc = 0, fe_state;
> +
> +    if (xenstore_read_fe_int(xendev, "state", &fe_state) == -1) {
> +        fe_state = XenbusStateUnknown;
> +    }
> +    xendev->fe_state = fe_state;
> +
> +    if (xendev->ops->initialise) {
> +        rc = xendev->ops->initialise(xendev);
> +    }
> +    if (rc != 0) {
> +        xen_pv_printf(xendev, 0, "initialise() failed\n");
> +        return rc;
> +    }
> +
> +    xenbus_switch_state(xendev, XenbusStateInitialised);
> +    return 0;
> +}
> +
> +static void xen_fe_try_connected(struct XenDevice *xendev)

This function looks exactly the same as xen_be_try_connected, should not
it be different and check the status of the backend?

> +{
> +    if (!xendev->ops->connected) {
> +        return;
> +    }
> +
> +    if (xendev->fe_state != XenbusStateConnected) {
> +        if (xendev->ops->flags & DEVOPS_FLAG_IGNORE_STATE) {
> +            xen_pv_printf(xendev, 2, "frontend not ready, ignoring\n");
> +        } else {
> +            xen_pv_printf(xendev, 2, "frontend not ready (yet)\n");
> +            return;
> +        }
> +    }
> +
> +    xendev->ops->connected(xendev);
> +}
> +
> +static int xen_fe_check(struct XenDevice *xendev, uint32_t domid,
> +                        int handle)

What is this function checking? The name of the function is not very
helpfull.

> +{
> +    int rc = 0;
> +
> +    rc = xen_fe_try_initialise(xendev);
> +    if (rc != 0) {
> +        xen_pv_printf(xendev, 0, "xendev %s initialise error\n",
> +                      xendev->name);
> +        goto err;
> +    }
> +    xen_fe_try_connected(xendev);
> +
> +    return rc;
> +
> +err:
> +    xen_pv_del_xendev(domid, handle);
> +    return -1;
> +}
> +
> +static char *xenstore_fe_get_backend(const char *type, int be_domid,
> +                                     uint32_t domid, int *hdl)
> +{
> +    char *name, *str, *ret = NULL;
> +    uint32_t i, cdev;
> +    int handle = 0;
> +    char path[XEN_BUFSIZE];
> +    char **dev = NULL;
> +
> +    name = xenstore_get_domain_name(domid);

The path backend of the backend would normally be located in:
device/$type/$devid/backend

Could not you use that instead of a domain name?

> +    snprintf(path, sizeof(path), "frontend/%s/%d", type, be_domid);
> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    for (i = 0; i < cdev; i++) {
> +        handle = i;
> +        snprintf(path, sizeof(path), "frontend/%s/%d/%d",
> +        type, be_domid, handle);
> +        str = xenstore_read_str(path, "domain");
> +        if (!strcmp(name, str)) {
> +            break;
> +        }
> +
> +        free(str);
> +
> +        /* Not the backend domain */
> +        if (handle == (cdev - 1)) {
> +            goto err;
> +        }
> +    }
> +
> +    snprintf(path, sizeof(path), "frontend/%s/%d/%d",
> +    type, be_domid, handle);
> +    str = xenstore_read_str(path, "backend");
> +    if (str != NULL) {
> +        ret = g_strdup(str);
> +        free(str);
> +    }
> +
> +    *hdl = handle;
> +    free(dev);
> +
> +    return ret;
> +err:
> +    *hdl = -1;
> +    free(dev);
> +    return NULL;
> +}
> +
> +static int xenstore_fe_scan(const char *type, uint32_t domid,
> +                            struct XenDevOps *ops)
> +{
> +    struct XenDevice *xendev;
> +    char path[XEN_BUFSIZE], token[XEN_BUFSIZE];
> +    unsigned int cdev, j;
> +    char *backend;
> +    char **dev = NULL;
> +    int rc;
> +    int xenstore_dev;
> +
> +    /* ops .init check, xendev is NOT initialized */
> +    rc = xen_fe_try_init(ops);
> +    if (rc != 0) {
> +        return -1;
> +    }
> +
> +    /* Get /local/domain/0/${type}/{} directory */

This comment does not reflect what is done by the next line, also what
is "{}"?

> +    snprintf(path, sizeof(path), "frontend/%s", type);

I have not seen "frontend" used anywhere else, frontends are usully
within "device", like "device/vbd/$DEVID/*" for a block device
frontend. Can this be change?

> +    dev = xs_directory(xenstore, 0, path, &cdev);
> +    if (dev == NULL) {
> +        return 0;
> +    }
> +
> +    for (j = 0; j < cdev; j++) {
> +
> +        /* Get backend via domain name */
> +        backend = xenstore_fe_get_backend(type, atoi(dev[j]),
> +                                          domid, &xenstore_dev);
> +        if (backend == NULL) {
> +            continue;
> +        }
> +
> +        xendev = xen_fe_get_xendev(type, domid, xenstore_dev, backend, ops);
> +        free(backend);
> +        if (xendev == NULL) {
> +            xen_pv_printf(xendev, 0, "xendev is NULL.\n");
> +            continue;
> +        }
> +
> +        /*
> +         * Simplify QEMU side, a thread is running in Xen backend, which will
> +         * connect frontend when the frontend is initialised.
> +         */
> +        if (xen_fe_check(xendev, domid, xenstore_dev) < 0) {
> +            xen_pv_printf(xendev, 0, "xendev fe_check error.\n");
> +            continue;
> +        }
> +
> +        /* Setup watch */
> +        snprintf(token, sizeof(token), "be:%p:%d:%p",
> +                 type, domid, xendev->ops);
> +        if (!xs_watch(xenstore, xendev->be, token)) {
> +            xen_pv_printf(xendev, 0, "xs_watch failed.\n");
> +            continue;
> +        }
> +    }
> +
> +    free(dev);
> +    return 0;
> +}
> +
> +int xen_fe_register(const char *type, struct XenDevOps *ops)
> +{
> +    return xenstore_fe_scan(type, xen_domid, ops);
> +}


Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-07-25 16:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1468151270-12984-1-git-send-email-emilcondrea@gmail.com>
2016-07-10 11:47 ` [PATCH 01/19] xen: Create a new file xen_pvdev.c Emil Condrea
2016-07-10 11:47 ` [PATCH 02/19] xen: Create a new file xen_frontend.c Emil Condrea
2016-07-25 13:45   ` Anthony PERARD
2016-07-10 11:47 ` [PATCH 03/19] xen: Move xenstore_update to xen_pvdev.c Emil Condrea
2016-07-10 11:47 ` [PATCH 04/19] xen: Move evtchn functions " Emil Condrea
2016-07-25 13:53   ` Anthony PERARD
     [not found]   ` <20160725135311.GI1835@perard.uk.xensource.com>
2016-07-27 23:16     ` Eric Blake
2016-07-31  9:47     ` Emil Condrea
2016-07-10 11:47 ` [PATCH 05/19] xen: Prepare xendev qtail to be shared with frontends Emil Condrea
2016-07-10 11:47 ` [PATCH 06/19] xen: Rename xen_be_printf to xen_pv_printf Emil Condrea
2016-07-10 11:47 ` [PATCH 07/19] xen: Rename xen_be_unbind_evtchn Emil Condrea
2016-07-25 13:56   ` Anthony PERARD
2016-07-10 11:47 ` [PATCH 08/19] xen: Rename xen_be_send_notify Emil Condrea
2016-07-25 13:58   ` Anthony PERARD
2016-07-10 11:47 ` [PATCH 09/19] xen: Rename xen_be_evtchn_event Emil Condrea
2016-07-10 11:47 ` [PATCH 10/19] xen: Rename xen_be_find_xendev Emil Condrea
2016-07-10 11:47 ` [PATCH 11/19] xen: Rename xen_be_del_xendev Emil Condrea
2016-07-10 11:47 ` [PATCH 12/19] xen: Rename xen_be_frontend_changed Emil Condrea
2016-07-10 11:47 ` [PATCH 13/19] xen: Distinguish between frontend and backend devops Emil Condrea
2016-07-10 11:47 ` [PATCH 14/19] Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options Emil Condrea
2016-07-10 11:47 ` [PATCH 15/19] Qemu-Xen-vTPM: Xen frontend driver infrastructure Emil Condrea
2016-07-25 16:01   ` Anthony PERARD [this message]
2016-08-07 11:39     ` Emil Condrea
     [not found]     ` <CAAULxKKk-UiLFPWn8GH4oDEqQEAowBSgdUHCPGvfX_Ubr_rztg@mail.gmail.com>
2016-08-09 11:40       ` Xuquan (Euler)
2016-07-10 11:47 ` [PATCH 16/19] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver Emil Condrea
2016-07-10 11:47 ` [PATCH 17/19] Qemu-Xen-vTPM: Move tpm_passthrough_is_selftest() into tpm_util.c Emil Condrea
2016-07-10 11:47 ` [PATCH 18/19] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backend Emil Condrea
2016-07-10 11:47 ` [PATCH 19/19] Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init() Emil Condrea
2016-07-13  2:55 ` [v9 00/19] QEMU:Xen stubdom vTPM for HVM virtual machine(QEMU Part) Xu, Quan
     [not found] ` <945CA011AD5F084CBEA3E851C0AB28894B8FD7C8@SHSMSX101.ccr.corp.intel.com>
2016-07-14 15:33   ` Stefano Stabellini
2016-07-17  6:56   ` Quan Xu
     [not found] ` <1468151270-12984-2-git-send-email-emilcondrea@gmail.com>
2016-07-25 13:41   ` [Qemu-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c Anthony PERARD
2016-07-25 14:09 ` [Qemu-devel] [v9 00/19] QEMU:Xen stubdom vTPM for HVM virtual machine(QEMU Part) Anthony PERARD
     [not found] ` <20160725140941.GL1835@perard.uk.xensource.com>
2016-07-31  9:57   ` Emil Condrea
2016-10-04  6:52   ` Emil Condrea

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160725160140.GM1835@perard.uk.xensource.com \
    --to=anthony.perard@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=eblake@redhat.com \
    --cc=emilcondrea@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quan.xu@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).