Re: [PATCH v3] displif: add ABI for para-virtual display

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

.snip..
> > > > > I will define 2 sections:
> > > > >    *------------------ Connector Request Transport Parameters
> > > > > -------------------
> > > > >    *
> > > > >    * ctrl-event-channel
> > > > >    * ctrl-ring-ref
> > > > >    *
> > > > >    *------------------- Connector Event Transport Parameters
> > > > > --------------------
> > > > >    *
> > > > >    * event-channel
> > > > >    * event-ring-ref
> > > > > 
> > > > > > Or is the other ring buffer the one that is created via 'gref_directory' ?
> > > > > no
> > > > > At the bottom:
> > > > >    * In order to deliver asynchronous events from back to front a shared page
> > > > > is
> > > > >    * allocated by front and its gref propagated to back via XenStore entries
> > > > >    * (event-XXX).
> > > > AAnd you may want to say this is guarded by REQ_ALLOC feature right?
> > > Not sure I understood you. Event path is totally independent
> > > from any feature, e.g. REQ_ALLOC.
> > > It just provides means to send async events
> > > from back to front, "page flip done" in my case.
> > <scratche his head> Why do you need a seperate ring to send
> > responses back? Why not use the same ring on which requests
> > were sent
> Ok, it seems we are not on the same page for rings/channels usage.
> Let me describe how those are used:
> 
> 1. Command/control event channel and its corresponding ring are used
> to pass requests from front to back (XENDISPL_OP_XXX) and get responses
> from the back. These are synchronous, use macros from ring.h:
> ctrl-event-channel + ctrl-ring-ref
> I call them "ctrl-" because this way front controls back, or sends commands
> if you will. Maybe "cmd-" would fit better here?
> 
> 2. Event channel - asynchronous path for the backend to signal activity
> to the frontend, currently used for "page flip done" event which is sent
> at some point of time after back has actually completed the page flip
> requested
> (so, before that the corresponding request was sent and response received,
> but
> operation didn't complete yet, instead it was scheduled)
> No macros exist for this use-case in ring.h (kbdif+fbif implement
> this on their own, so do I)
> These are:  event-channel + event-ring-ref
> Probably here is the point from where confusion comes, naming.
> We can have something like "be-to-fe-event-channel" or anything else
> more cute and descriptive.
> 
> Hope this explains the need for 2 paths

Aha!

So this is like the network where there is an 'rx' and 'tx'!

Now I get it.

In that case why not just prefix it with 'in' and 'out'? Such as:

'out-ring-ref' and 'out-event-channel' and 'in-ring-ref' along
with 'in-event-channel'.

Or perhaps better - borrow the same idea that Stefano came up for
9pfs and PV calls - where his ring does both.

Then you just need 'ring-ref', 'event-channel', 'max-page-ring-order'
(which must be 1 or larger).

And you split the ring-ref in two - one for 'in' events and the other
part for 'out' events?

..giant snip..

> > > > > Thus, I was thinking of XenbusStateReconfiguringstate as appropriate in this
> > > > > case
> > > > Right, but somebody has to move to this state. Who would do it?
> > > when backend dies its state changes to "closed".
> > > At this moment front tries to remove virtualized device
> > > and if it is possible/done, then it goes into "initialized"
> > > state. If not - "reconfiguring".
> > > So, you would ask how does the front go from "reconfiguring"
> > > into "initialized" state? This is OS/front specific, but:
> > > 1. the underlying framework, e.g. DRM/KMS, ALSA, provide
> > > a callback(s) to signal that the last client to the
> > > virtualized device has gone and the driver can be removed
> > > (equivalent to module's usage counter 0)
> > > 2. one can schedule a delayed work (timer/tasklet/workqueue)
> > > to periodically check if this is the right time to re-try
> > > the removal and remove
> > > 
> > > In both cases, after the virtualized device has been removed we move
> > > into "initialized" state again and are ready for new connections
> > > with backend (if it arose from the dead :)
> > > > Would the
> > > > frontend have some form of timer to make sure that the backend is still
> > > > alive? And if it had died then move to Reconfiguring?
> > > There are at least 2 ways to understand if back is dead:
> > > 1. XenBus state change (back is closed)
> > .. If the backend does a nice shutdown..
> hm, on Linux I can kill -9 backend and XenBus driver seems
> to be able to turn back's state into "closed"
> isn't this expected behavior?

That is the expected behavior. I was thinking more of a backend
being a guest - and the guest completly going away and nobody
clearing its XenStore keys.

In which case your second option of doing a timeout will work.
But you may need an 'PING' type request to figure this out?


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