Re: [Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

[Stefano Stabellini <stefano@xxxxxxxxxxx>]

On Wed, 3 Aug 2016, Stefano Stabellini wrote:
> On Wed, 3 Aug 2016, Wei Liu wrote:
> > > # PV Calls Protocol
> > > 
> > > ## Rationale
> > > 
> > > PV Calls is a paravirtualized protocol for the POSIX socket API.
> > > 
> > > The purpose of PV Calls is to allow the implementation of a specific set
> > > of POSIX functions to be done in a domain other than your own. It allows
> > > connect, accept, bind, release, listen, poll, recvmsg and sendmsg to be
> > > implemented in another domain.
> > > 
> > 
> > The wording isn't really clear here. This design document as-is would
> > inevitably make people start to compare PV Calls to various HV socks I'm
> > afraid.
> 
> You are right, thanks for the feedback. I'll clarify it.

Actually there are quite a few things I should change to make this
document more generic. They'll be in the next version.
 
 
> > Is PV Calls going to cover other stuff other than socket API? If it
> > targets POSIX interfaces, maybe call it PV POSIX?
> > 
> > But then, if you extend the scope to cover POSIX APIs, I think you might
> > want some discovery mechanism to see what APIs are paravirtualised?
> 
> Yes, it can potentially cover other interfaces -- I have a couple of
> ideas in that area but I need to do some experiments first.
> 
> I fully agree that we need a discovery mechanism. What it is briefly
> covered by this document, is that if a cmd is not supported by the
> backend, ret is ENOTSUPP. But maybe we could also add a version node to
> xenstore, that could be used to version the protocol supported by the
> backend.


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