All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: "Xu, Quan" <quan.xu@intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [v3 2/5] Qemu-Xen-vTPM: Xen frontend driver infrastructure
Date: Thu, 29 Jan 2015 17:32:37 +0000	[thread overview]
Message-ID: <alpine.DEB.2.02.1501291732160.9702@kaball.uk.xensource.com> (raw)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28890E87FDE4@SHSMSX101.ccr.corp.intel.com>

On Thu, 29 Jan 2015, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Tuesday, January 20, 2015 1:15 AM
> > To: Xu, Quan
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org;
> > stefano.stabellini@eu.citrix.com
> > Subject: Re: [v3 2/5] Qemu-Xen-vTPM: Xen frontend driver infrastructure
> > 
> > On Tue, 30 Dec 2014, Quan Xu 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.
> > >
> > > --Changes in v3:
> > > -New xen_frontend.c file
> > > -Move xenbus_switch_state() to xen_frontend.c -Move xen_stubdom_be()
> > > to xenstore_fe_read_be_str() -Move *_stubdom_*() to *_fe_*()
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > ---
> > >  hw/xen/Makefile.objs         |   2 +-
> > >  hw/xen/xen_backend.c         |  11 +-
> > >  hw/xen/xen_frontend.c        | 323
> > +++++++++++++++++++++++++++++++++++++++++++
> > >  include/hw/xen/xen_backend.h |  14 ++
> > >  4 files changed, 348 insertions(+), 2 deletions(-)  create mode
> > > 100644 hw/xen/xen_frontend.c
> > >
> > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index
> > > a0ca0aa..b0bb065 100644
> > > --- a/hw/xen/Makefile.objs
> > > +++ b/hw/xen/Makefile.objs
> > > @@ -1,5 +1,5 @@
> > >  # xen backend driver support
> > > -common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> > > +common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> > > +xen_frontend.o
> > >
> > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > >  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
> > > xen_pt_msi.o diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> > > index b2cb22b..ad6e324 100644
> > > --- a/hw/xen/xen_backend.c
> > > +++ b/hw/xen/xen_backend.c
> > > @@ -275,7 +275,7 @@ static struct XenDevice *xen_be_get_xendev(const
> > > char *type, int dom, int dev,
> > >  /*
> > >   * release xen backend device.
> > >   */
> > > -static struct XenDevice *xen_be_del_xendev(int dom, int dev)
> > > +struct XenDevice *xen_be_del_xendev(int dom, int dev)
> > >  {
> > >      struct XenDevice *xendev, *xnext;
> > >
> > > @@ -681,6 +681,10 @@ static void xenstore_update(void *unused)
> > >      if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, &ptr) == 1) {
> > >          xenstore_update_fe(vec[XS_WATCH_PATH], (void*)ptr);
> > >      }
> > > +    if (sscanf(vec[XS_WATCH_TOKEN], "stub:%" PRIxPTR ":%d:%" PRIxPTR,
> > > +               &type, &dom, &ops) == 3) {
> > > +        xenstore_fe_update(vec[XS_WATCH_PATH], (void *)type, dom,
> > (void *)ops);
> > > +    }
> > 
> > Why "stub:"? Where is it coming from?
> > 
> > I think that the xenstore_update function should be moved to a new file:
> > we don't want xen_backend.c to be handling any frontend updates.
> > Maybe you could create a new file, hw/xen/xen_pvdev.c?
> > 
> 
> Stefano,
> 	I'd like to create hw/xen/xen_pvdev.c , include/hw/xen/ xen_pvdev.h and 
> include/hw/xen/xen_frontend.h
> 
> include/hw/xen/ xen_pvdev.h is for 
> struct XenDevOps{} and struct XenDevice {} definition and some other macro.
> 
> include/hw/xen/xen_frontend.h is for 
> xen frontend interface, such as xen_fe_register() .etc
> 
> hw/xen/xen_pvdev.c is for 
> some general parts of xen_backend/xen_frontend.
> It includes xenstore_update function xendevs management, such as xen_qtail_insert_xendev(..),
> xenstore_update(...) .etc.
> 
> do you agree with it?

It seems reasonable.

  parent reply	other threads:[~2015-01-29 17:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 23:03 [Qemu-devel] [v3 2/5] Qemu-Xen-vTPM: Xen frontend driver infrastructure Quan Xu
2014-12-30 23:03 ` Quan Xu
2015-01-19 17:15 ` [Qemu-devel] " Stefano Stabellini
2015-01-19 17:15   ` Stefano Stabellini
2015-01-20  2:47   ` Xu, Quan
2015-01-20  2:47   ` [Qemu-devel] " Xu, Quan
2015-01-20 10:46     ` Stefano Stabellini
2015-01-20 10:46     ` [Qemu-devel] " Stefano Stabellini
2015-01-29 16:07   ` Xu, Quan
2015-01-29 17:32     ` Stefano Stabellini
2015-01-29 17:32     ` Stefano Stabellini [this message]
2015-01-30  1:46       ` Xu, Quan
2015-01-30  1:46       ` [Qemu-devel] " Xu, Quan
2015-01-29 16:07   ` Xu, Quan

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=alpine.DEB.2.02.1501291732160.9702@kaball.uk.xensource.com \
    --to=stefano.stabellini@eu.citrix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quan.xu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.