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 17:15 +0000, Thanos Makatos wrote:
> > > > > > 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>.
> 
> Then there's no problem with that. So, going back to your original
> question, there is one tapback daemon per driver domain.
> 
> What I don't understand, however, is how a front-end's VBD creation
> request will end up to the correct driver domain. Does the front-end
> know under which /local/domid tree in XenStore it should write to? Is
> this explained somewhere?

The frontend looks in devices/vbd/<foo>/backend which to get the full
path to to the backend. The toolstack writes this and knows both the
front- and back-end domain ids.

>  
> > 
> > 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.
> 
> I guess a tapback daemon could delegate this operation to the tapback
> running at the appropriate driver domain via XenStore, no?

Yes.

In fact I'm wondering why the tapback daemon does all the ring setup,
xenbus negotiation anyway. It could just watch "backend/<device-type>"
and when it sees a new backend/<device-type>/<domid>/<devid> fork a new
"tapdisk --domain <domid> --devid <devid>" and have tapdisk take care of
the protocol entirely. Saves a bunch of messaging back and forth I
think.

I don't have a problem with the existing model, it just strikes me as a
bit odd (but then I don't really know the architecture)

Ian.


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