WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] PV framebuffer
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Mon, 13 Nov 2006 16:29:00 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, sos22@xxxxxxxxxxxxx
Delivery-date: Mon, 13 Nov 2006 07:29:12 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061112142019.GA2014@xxxxxxxxx> (Steven Smith's message of "Sun, 12 Nov 2006 14:20:19 +0000")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87odrfptrb.fsf@xxxxxxxxxxxxxxxxx> <20061112142019.GA2014@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
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