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

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> > > > > 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?
 
> 
> 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?

> 
> Ian.

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