Re: [Xen-devel] [PATCH 0 of 9 RFC v2] blktap3: Introduce a small subset of blktap3 files

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 18 January 2013 16:47
> To: Thanos Makatos
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH 0 of 9 RFC v2] blktap3: Introduce a
> small subset of blktap3 files
> 
> On Fri, 2013-01-18 at 16:37 +0000, Thanos Makatos wrote:
> > > > 4. tapback: a user space daemon that acts as the back-end of each
> > > virtual
> > > >    block device: it monitors XenStore for the block front-end's
> state
> > > changes,
> > > >    creates/destroys the shared ring, and instructs the tapdisk to
> > > connect
> > > >    to/disconnect from the shared ring. It also communicates to
> the
> > > block
> > > >    front-end required parameters (e.g. block device size in
> sectors)
> > > via
> > > >    XenStore.
> > >
> > > There is 1 tapdisk per VBD but how many tapbacks are there? One per
> VBD
> > > as well or one per domain or per driver domain?
> >
> > There is one tapback daemon in total, serving all VBDs/domains.
> 
> You mean one per backend domain I assume?

I haven't thought of that, but I believe there can be only one tapback daemon 
across multiple driver domains. This is because tapback monitors XenStore path 
"backend/<device type>" (i.e. backend/vbd), so if there were multiple tapback 
daemon they would all try to serve this event. Is my understanding correct? If 
this is true then it's a serious limitation for driver domains.

> 
> > The tapback daemon sets a XenStore watch to "backend/<device type>"
> to
> > serve VBD creations for completely new domains, and then sets an
> > additional watch to the front-end state path for each VBD. I guess
> > there could be one tapback daemon detecting completely new domains,
> > responsible for spawning tapback daemons designated to a specific
> > domain/VBD. I'm not sure of the implications of this approach,
> though.
> > (We could also have one thread designated to each domain/VBD.) Is
> > there a particular reason why a single tapback daemon wouldn't
> > suffice?
> 
> No, it sounds reasonable. I was more concerned there might be one per
> VBD in which case it would have made sense to merge tapdisk and
> tapback.
> 
> > > Is tapback involved in things after the ring has been setup and it
> has
> > > instructed tapdisk to use it? i.e. is it on the datapath at all?
> >
> > The tapback daemon is involved only for running the Xenbus protocol
> > when the front-end is set up/torn down -- no participation in the
> data
> > path.
> 
> Oh good.

I'll update the patch description with this information.

> 
> Ian.
> 

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