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.
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
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.
> * 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.
> * 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:
diff -r f70b56aab8a2 tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py Thu Nov 02 13:20:32 2006 +0000
+++ b/tools/python/xen/xm/create.py Fri Nov 03 16:48:34 2006 +0000
@@ -277,6 +277,11 @@ gopts.var('usbport', val='PATH',
use="""Add a physical USB port to a domain, as specified by the path
to that port. This option may be repeated to add more than one
port.""")
+gopts.var('vfb', val="foo",
+ fn=append_value,
+ default=[],
+ use="""Do stuff""")
+
gopts.var('vif',
val="mac=MAC,bridge=BRIDGE,ip=IPADDR,script=SCRIPT,backend=DOM,vifname=NAME",
fn=append_value, default=[],
use="""Add a network interface with the given MAC address and bridge.
@@ -544,6 +549,9 @@ def configure_usb(config_devs, vals):
config_usb = ['usbport', ['path', path]]
config_devs.append(['device', config_usb])
+def configure_vfbs(config_devs, vals):
+ for path in vals.vfb:
+ config_devs.append(['device', ['vfb', []]])
def configure_security(config, vals):
"""Create the config for ACM security labels.
@@ -717,6 +724,7 @@ def make_config(vals):
configure_vifs(config_devs, vals)
configure_usb(config_devs, vals)
configure_vtpm(config_devs, vals)
+ configure_vfbs(config_devs, vals)
configure_security(config, vals)
config += config_devs
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.
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home