Re: [Xen-devel] [PATCH 0/2] PV framebuffer

[Markus Armbruster <armbru@xxxxxxxxxx>]

Steven Smith <sos22-xen@xxxxxxxxxxxxx> writes:

> On Fri, Nov 10, 2006 at 09:53:44AM +0100, Markus Armbruster wrote:
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> From: Markus Armbruster <armbru@xxxxxxxxxx>
>> Date: Fri, 10 Nov 2006 09:53:44 +0100
>> Subject: [Xen-devel] [PATCH 0/2] PV framebuffer
>
> These patches look a lot better than the last batch which were posted;
> thank you for doing this work.  It's turned out to be a bit more than
> I think anybody was really expecting.

Least of all me :)

> I've got a few comments on the patches themselves, but most of them
> are fairly simple and easily addressed.  I'll send them in separate
> emails.
>
>> Known issues:
>> 
>> * What to do when backend closes the connection?  I guess we want to
>>   keep the frontend running, ready for another connection.  This works
>>   already, but in a rather hackish and limited way.
> The current scheme, as I read it, is just to have the backend ignore
> the fact that it's resuming from an existing connection and pull the
> required settings out of xenbus and the shared memory area?  That's

Correct.

> not actually a bad way of doing things, since it doesn't require much
> cooperation from the frontend, which'll be handy for things like
> migration and suspend/resume.
>
> You'll have problems if the set of supported features changes between
> the two backends, but that shouldn't require too much effort to fix.
>
>> * What to do when the frontend closes the connection?  Make backend
>>   exit?
> Your choices, as far as I can see, are:
>
> -- Make the backend exit.
>
> -- Make the backend sit and wait for the frontend to reconnect.
>    You'll probably want to arrange for the backend to go to state
>    InitWait here, so that the new frontend can reconnect easily,
>    and you'll obviously want to unmap all of the frontend-supplied
>    pages.
>
> I'm not sure why the frontend would ever disconnect except when the
> guest is shutting down, so I'm not sure which approach is best here.

I figure the situation will become clearer to me when I implement
resume.

>> * What happens when multiple backends connect to the same frontend?
>>   Chaos, most likely.
> Yep.  You could put some kind of lock in xenbus if you care about
> this, but it'd cause problems if you want to be able to reconnect
> after a backend crashes.

Need to detect and delete stale locks.

I'd like to have robust behavior here eventually, but don't think we
need it right away.

>> * xm configuration magic doesn't know the new devices, yet.  I'm
>>   ignorant of how this magic works, perhaps somebody can lend me a
>>   hand with it.
> How about something like this:
[...]
> You'll need to do something similar for vkbds as well.  If you need
> additional parameters in the SXP, add them in configure_vfbs.  It
> might be an idea to automatically create the vkbd when you create the
> vfb SXP, since it doesn't make a great deal of sense to have one
> without the other, but I'll leave that up to you.

I'll give this a try, many thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel