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