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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-01-18 at 16:58 +0000, Thanos Makatos wrote:
> > -----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.

"backend/<device-type>" is a relative not absolute path so it is
relative to the driver domains /local/domid/<DOMID>.

I wouldn't expect that a tapback process in one domain would be able to
setup the necessary rings/evtchns in such a way that a tapdisk in
another process could use them.

Ian.


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