[PATCH 0/2] PV framebuffer

[PATCH 0/2] PV framebuffer

[Markus Armbruster]

Summary of changes:

* Use xenbus_device API.

  Some xm configuration magic is still missing, see below.

* Negotiate features through Xen Store.

* Key identification

  Discussed at length on this list.  I fixed sdlfb to use scan codes
  (assumes standard AT or PS/2 keyboard).  vncfb is not fixable.  See
  comments in the code.

* Drop XENKBD_TYPE_BUTTON in favour of XENKBD_TYPE_KEY.  Simpler, and
  gets rid of the three button limit.

* Support shadow translate mode guests (untested).

* Absolute mouse pointer (optional feature)

* Fix event delivery and receipt notification.

* Use __s32 for coordinates instead of __u16 and __s16 for pixel
  coordinates, to match linux/input.h, which uses int.

* Don't drop the first pointer event on the floor in vncfb.

* Backends diagnose lost kbd events.

* Some renames to make xenkbd and xenfb drivers more similar.  Sorry
  for the extra diffs, but the inconsistencies were just too
  confusing.

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.

* What to do when the frontend closes the connection?  Make backend
  exit?

* What happens when multiple backends connect to the same frontend?
  Chaos, most likely.

* Resume not implemented.

* 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.

  Workaround:

  - Convert /etc/xen/FOO into FOO.sxp with xm create -n.  Make sure to
    delete the junk at the beginning of the output.

  - Add
        (device (vfb ()))
        (device (vkbd ())
    and change kernel and ramdisk to point to suitable copies.

  - xm create -F FOO.sxp.

* A couple of FIXMEs are still left in the code.

Future work:

* Investigate ditching LibVNCServer.

* Use grant tables when they become capable of mapping the
  framebuffer.

* Support multiple framebuffers.

* Dynamic screen resolution.

* Support other keyboards.

Re: [PATCH 0/2] PV framebuffer

[Gerd Hoffmann]

  Hi,

>   Discussed at length on this list.  I fixed sdlfb to use scan codes
>   (assumes standard AT or PS/2 keyboard).  vncfb is not fixable.  See
>   comments in the code.

I've hacked up my own vnc client (using gtk and libvncserver).  That one
has a cmd line switch to send us keyboard keysyms no matter what the
local keymap is (using a builtin keycode -> keysym table).  It isn't
perfect, but it is the best solution I've found for vnc so far.

I have at least a sane US keyboard within the guests.  Loading keymaps
within the guest works too and gives the expected results, except that
keys not available on a US keyboard don't work (i.e. the 105th key on
int'l keyboards).  No idea how to tackle that one :-(

It's part of the xenwatch package.  Source is available from
http://dl.bytesex.org/cvs-snapshots/, the opensuse buildservice has
ready-to-go packages for at
http://software.opensuse.org/download/home:/kraxel/

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [PATCH 0/2] PV framebuffer

[Steven Smith]

[-- Attachment #1.1: Type: text/plain, Size: 4093 bytes --]

On Fri, Nov 10, 2006 at 09:53:44AM +0100, Markus Armbruster wrote:
> To: xen-devel@lists.xensource.com
> From: Markus Armbruster <armbru@redhat.com>
> 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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Steven Smith <sos22-xen@srcf.ucam.org> writes:

> On Fri, Nov 10, 2006 at 09:53:44AM +0100, Markus Armbruster wrote:
>> To: xen-devel@lists.xensource.com
>> From: Markus Armbruster <armbru@redhat.com>
>> 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!

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Hi Steven,

Your sketch for the xm configuration magic was quite helpful.  Perhaps
you can lend me a hand with resume as well.

xm restore fails (xend.log appended) because the xenfb backend can't
be connected.  Obviously, I need to start the backend somewhere on
restore, just like I start it on xm create (patch appended).  Where?
How?



[2006-11-21 18:21:21 xend 3303] ERROR (XendDomain:268) Restore failed
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line 263, in d
omain_restore_fd
    return XendCheckpoint.restore(self, fd)
  File "/usr/lib/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 165, 
in restore
    dominfo.waitForDevices() # Wait for backends to set up
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1596,
 in waitForDevices
    self.waitForDevices_(c)
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1090,
 in waitForDevices_
    return self.getDeviceController(deviceClass).waitForDevices()
  File "/usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", line
 145, in waitForDevices
    return map(self.waitForDevice, self.deviceIDs())
  File "/usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", line
 155, in waitForDevice
    raise VmError("Device %s (%s) could not be connected. "
VmError: Device 0 (vkbd) could not be connected. Hotplug scripts not working.


diff -r 73ef90055339 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Thu Nov 16 18:29:06 2006 +0000
+++ b/tools/python/xen/xend/image.py	Fri Nov 17 16:06:23 2006 +0100
@@ -23,6 +23,7 @@ import signal
 import signal
 
 import xen.lowlevel.xc
+import xen.util.auxbin
 from xen.xend import sxp
 from xen.xend.XendError import VmError, XendError
 from xen.xend.XendLogging import log
@@ -209,6 +210,81 @@ class LinuxImageHandler(ImageHandler):
                               cmdline        = self.cmdline,
                               ramdisk        = self.ramdisk,
                               features       = self.vm.getFeatures())
+
+    def configure(self, imageConfig, deviceConfig):
+        ImageHandler.configure(self, imageConfig, deviceConfig)
+
+        self.pid = 0
+        log.info("configuring linux guest")
+
+        # set up the graphics bits.
+        # FIXME: this is much like what we do for HVM, should it be 
+        # for all image types now?
+        self.display = sxp.child_value(imageConfig, 'display')
+        self.xauthority = sxp.child_value(imageConfig, 'xauthority')
+        self.vncconsole = sxp.child_value(imageConfig, 'vncconsole')
+        vncpasswd = sxp.child_value(imageConfig, 'vncpasswd')
+        if not(vncpasswd is None):
+            imageConfig.remove(['vncpasswd', vncpasswd])
+        self.vncpasswd = vncpasswd
+
+        self.vnc = sxp.child_value(imageConfig, 'vnc')
+        self.sdl = sxp.child_value(imageConfig, 'sdl')
+        if self.vnc:
+            self.vncdisplay = int(sxp.child_value(imageConfig, 'vncdisplay',
+                                                  self.vm.getDomid()))
+            self.vncunused = sxp.child_value(imageConfig, 'vncunused')
+            self.vnclisten = sxp.child_value(imageConfig, 'vnclisten')
+            if not(self.vnclisten):
+                self.vnclisten = xen.xend.XendRoot.instance().get_vnclisten_address()
+
+    def createDeviceModel(self):
+        if self.pid:
+            return
+        # Execute device model (for us, it's just the fb frontend)
+        if not self.vnc and not self.sdl:
+            return
+
+        if self.vnc:
+            args = [xen.util.auxbin.pathTo("xen-vncfb")]
+            if self.vncunused:
+                args += ['--unused']
+            elif self.vncdisplay:
+                args += [ "--vncport", "%d" %(5900 + self.vncdisplay,) ]
+            if self.vnclisten:
+                args += [ "--listen", self.vnclisten ]
+
+            # password check
+            if self.vncpasswd is None:
+                # get password from xend-config(if password omitted, None)
+                self.vncpasswd = xen.xend.XendRoot.instance().get_vncpasswd_default()
+
+                if self.vncpasswd is None:
+                    raise VmError('vncpasswd is not setup in the guest config or xend-config.')
+            if self.vncpasswd != '':
+                self.vm.storeVm("vncpasswd", self.vncpasswd)
+                log.info("vncpassword set to '%s'", self.vncpasswd)
+
+        elif self.sdl:
+            args = [xen.util.auxbin.pathTo("xen-sdlfb")]
+        args = args + [ "--domid", "%d" % self.vm.getDomid(),
+                        "--title", self.vm.info['name'] ]
+
+        env = dict(os.environ)
+        if self.display:
+            env['DISPLAY'] = self.display
+        if self.xauthority:
+            env['XAUTHORITY'] = self.xauthority
+        log.info("spawning video: %s", args)
+        self.pid = os.spawnve(os.P_NOWAIT, args[0], args, env)
+        log.info("device model pid: %d", self.pid)
+
+    def destroy(self):
+        if not self.pid:
+            return
+        os.kill(self.pid, signal.SIGKILL)
+        os.waitpid(self.pid, 0)
+        self.pid = 0
 
 class PPC_LinuxImageHandler(LinuxImageHandler):

Re: [PATCH 0/2] PV framebuffer

[Atsushi SAKAI]

Hello, Markus

 I want to test PV patch but current patch does not work.
(as Steven Smith suggested, for example xenfb.h xenkbd.h location is not correct)
Could you give me a working version patch?

Thanks
Atsushi SAKAI

>Summary of changes:
>
>* Use xenbus_device API.
>
>  Some xm configuration magic is still missing, see below.
>
>* Negotiate features through Xen Store.
>
>* Key identification
>
>  Discussed at length on this list.  I fixed sdlfb to use scan codes
>  (assumes standard AT or PS/2 keyboard).  vncfb is not fixable.  See
>  comments in the code.
>
>* Drop XENKBD_TYPE_BUTTON in favour of XENKBD_TYPE_KEY.  Simpler, and
>  gets rid of the three button limit.
>
>* Support shadow translate mode guests (untested).
>
>* Absolute mouse pointer (optional feature)
>
>* Fix event delivery and receipt notification.
>
>* Use __s32 for coordinates instead of __u16 and __s16 for pixel
>  coordinates, to match linux/input.h, which uses int.
>
>* Don't drop the first pointer event on the floor in vncfb.
>
>* Backends diagnose lost kbd events.
>
>* Some renames to make xenkbd and xenfb drivers more similar.  Sorry
>  for the extra diffs, but the inconsistencies were just too
>  confusing.
>
>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.
>
>* What to do when the frontend closes the connection?  Make backend
>  exit?
>
>* What happens when multiple backends connect to the same frontend?
>  Chaos, most likely.
>
>* Resume not implemented.
>
>* 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.
>
>  Workaround:
>
>  - Convert /etc/xen/FOO into FOO.sxp with xm create -n.  Make sure to
>    delete the junk at the beginning of the output.
>
>  - Add
>        (device (vfb ()))
>        (device (vkbd ())
>    and change kernel and ramdisk to point to suitable copies.
>
>  - xm create -F FOO.sxp.
>
>* A couple of FIXMEs are still left in the code.
>
>Future work:
>
>* Investigate ditching LibVNCServer.
>
>* Use grant tables when they become capable of mapping the
>  framebuffer.
>
>* Support multiple framebuffers.
>
>* Dynamic screen resolution.
>
>* Support other keyboards.
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Atsushi SAKAI <sakaia@jp.fujitsu.com> writes:

> Hello, Markus
>
>  I want to test PV patch but current patch does not work.
> (as Steven Smith suggested, for example xenfb.h xenkbd.h location is not correct)
> Could you give me a working version patch?
>
> Thanks
> Atsushi SAKAI

My frontend patch is relative to the Linux tree, not the Xen tree, and
not the *sparse* Linux tree within the Xen tree.

The guardians of the source tree assure me they greatly benefit from
having a sparse tree there.  Good for them[*]!  I don't.  It's a pain
in the neck for me.  By refusing to touch the sparse tree, I shift a
good part of my pain to those who enjoy the benefits.  I consider that
fair.

To try my patch, let Xen create an ordinary source tree, then patch
that.  I do test that it applies there before submitting.

If you'd rather sparsify it, perhaps a knowledgeable user of the
sparse tree can help you.

[*] No irony intended, honest, officer.

Re: [PATCH 0/2] PV framebuffer

[Atsushi SAKAI]

Hi, Markus

your code location of xenfb.h is in 
linux-2.6.16.29-xen/include/xen/interface/io/xenfb.h
it is wrong position.

It should be located in 
xen/include/public/io

please see mkbuildtree@linux-sparce
and 
see your linux-2.6.16.29-xen/include/xen/interface/io
with "ls -l" 
these file is linked from
xen/include/public/io

Thanks
Atsushi SAKAI



>Atsushi SAKAI <sakaia@jp.fujitsu.com> writes:
>
>> Hello, Markus
>>
>>  I want to test PV patch but current patch does not work.
>> (as Steven Smith suggested, for example xenfb.h xenkbd.h location is not correct)
>> Could you give me a working version patch?
>>
>> Thanks
>> Atsushi SAKAI
>
>My frontend patch is relative to the Linux tree, not the Xen tree, and
>not the *sparse* Linux tree within the Xen tree.
>
>The guardians of the source tree assure me they greatly benefit from
>having a sparse tree there.  Good for them[*]!  I don't.  It's a pain
>in the neck for me.  By refusing to touch the sparse tree, I shift a
>good part of my pain to those who enjoy the benefits.  I consider that
>fair.
>
>To try my patch, let Xen create an ordinary source tree, then patch
>that.  I do test that it applies there before submitting.
>
>If you'd rather sparsify it, perhaps a knowledgeable user of the
>sparse tree can help you.
>
>[*] No irony intended, honest, officer.
>

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Atsushi SAKAI <sakaia@jp.fujitsu.com> writes:

> Hi, Markus
>
> your code location of xenfb.h is in 
> linux-2.6.16.29-xen/include/xen/interface/io/xenfb.h
> it is wrong position.
>
> It should be located in 
> xen/include/public/io

If my patch were relative to the Xen source tree, you'd be right.  It
isn't.  There is no xen directory in a Linux source tree.

Yes, that means you can't apply my patch directly to your Xen source
tree.  Sorry about that.  I explained my reasons.

[...]

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Next iteration.  If there's anything left in the way of getting this
merged, please let me know right away.

Changes since last time:

* Minor cleanup of how Xen console detects presence of framebuffer.

* Fix config XEN_KEYBOARD dependencies.

* Fix misuse of __devexit.

* Fix crash when kthread_run() fails.

* Work around xenbus race condition.

* Get rid of xenstore key console/use_graphics.

* Supply missing patch to mm/memory.c

* Fix typo in XendDevices.py

* xm configuration magic for xenfb and xenkbd devices.

* vncfb listens on 127.0.0.1 instead of 0.0.0.0 by default.

* backends put error node into xenstore.

* Move write of hotplug-status to the correct place.

* Make backend reconnect even when status is Closing or Closed.

Diffs since last time follow in separate messages.

Not in this patch, but coming soon: make xend start the backend
automatically.  For now, you need to start it manually, like this:

    # sdlfb -d $(xm domid parafat)

You also have to put the following lines into /etc/xen/DOMNAME:

    vfb = 'yes'
    vkbd = 'yes'

The framebuffer remains inactive without them.  That means behavior of
existing domains should not be affected, which is nice.

If you do put them in, xend will wait for you to start the backend
before it unpauses the domain.  It would be nice if it just went
along, and connecting a backend later just worked, but that's left for
another day.

One last thing to consider: I'm not entirely happy with source file
names and locations.  It's now or never for renames.  Peeves:

* Frontend source usually lives in drivers/xen/<WHAT>front.  xenfb and
  xenkbd are exceptions.  Rename to fbfront and kbdfront?  Same for
  the .c files.  This would also fix the minor annoyance of having the
  same file name in frontend and backend.

* Given how closely related xenfb and xenkbd are, I'm not fond of
  having them in separate directories.  Move kbd into the fb
  directory?

Anything else?

Re: Re: [PATCH 0/2] PV framebuffer

[Steven Smith]

[-- Attachment #1.1: Type: text/plain, Size: 1309 bytes --]

> Next iteration.  If there's anything left in the way of getting this
> merged, please let me know right away.
I hit a couple of problems when testing this:

1) It breaks existing configurations.  Changing the xencons default
   from xencons=tty to xencons=xvc means that any existing
   configurations with gettys etc. set up on /dev/tty1 rather than
   /dev/xvc0 will no longer work.  That really isn't an option.

2) The mouse pointer displayed by X or gpm and the pointer as sent by
   the client often get out of sync.  It looks like X is getting
   relative mouse movement messages rather than absolute.  The backend
   is definitely generating absolute position messages, so I'm not
   sure what's going on there.  It's possible I've just messed up the
   configuration inside the domain.

3) The backend doesn't do the shutdown protocol correctly.  This leads
   to

xenbus_dev_shutdown: device/vkbd/0 timeout closing device

   messages on the console when you try and shut the domain down.
   These are more irritants than actual problems, but it'd be good to
   get them fixed.

I'm kind of bogged down with other stuff at the moment, so I'm not
going to be able to look at the patches in detail until next week, but
I figure that should be enough to keep you busy for a little while. :)

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Steven Smith <sos22-xen@srcf.ucam.org> writes:

>> Next iteration.  If there's anything left in the way of getting this
>> merged, please let me know right away.
> I hit a couple of problems when testing this:
>
> 1) It breaks existing configurations.  Changing the xencons default
>    from xencons=tty to xencons=xvc means that any existing
>    configurations with gettys etc. set up on /dev/tty1 rather than
>    /dev/xvc0 will no longer work.  That really isn't an option.

Done.

> 2) The mouse pointer displayed by X or gpm and the pointer as sent by
>    the client often get out of sync.  It looks like X is getting
>    relative mouse movement messages rather than absolute.  The backend
>    is definitely generating absolute position messages, so I'm not
>    sure what's going on there.  It's possible I've just messed up the
>    configuration inside the domain.

What pointer device did you use?  Almost all use relative modes,
including tablets.

> 3) The backend doesn't do the shutdown protocol correctly.  This leads
>    to
>
> xenbus_dev_shutdown: device/vkbd/0 timeout closing device
>
>    messages on the console when you try and shut the domain down.
>    These are more irritants than actual problems, but it'd be good to
>    get them fixed.

Sure.

I'd prefer to finish resume first.  Still trying to figure out why xm
restore doesn't restart the backend.

> I'm kind of bogged down with other stuff at the moment, so I'm not
> going to be able to look at the patches in detail until next week, but
> I figure that should be enough to keep you busy for a little while. :)

Sigh...

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Next iteration.  If there's anything left in the way of getting this
merged, please let me know right away.

Changes since last time:

* Leave xen console defaulting to /dev/tty1.

* Start backend automatically.

* Fix kernel thread to call try_to_freeze().

* Recreate the image sub-object in XendDomainInfo.py on resume.

* Implement frontend resume methods; xm save and restore work now.

* Implement orderly backend shutdown.

To activate the framebuffer, you have to put the following lines into
/etc/xen/DOMNAME:

    vfb = 'yes'
    vkbd = 'yes'

and either

    sdl = 1

or

    vnc = 1

One last thing to consider: I'm not entirely happy with source file
names and locations.  It's now or never for renames.  Peeves:

* Frontend source usually lives in drivers/xen/<WHAT>front.  xenfb and
  xenkbd are exceptions.  Rename to fbfront and kbdfront?  Same for
  the .c files.  This would also fix the minor annoyance of having the
  same file name in frontend and backend.

* Given how closely related xenfb and xenkbd are, I'm not fond of
  having them in separate directories.  Move kbd into the fb
  directory?

Anything else?

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

> Next iteration.  If there's anything left in the way of getting this
> merged, please let me know right away.
>
> Changes since last time:
>
> * Leave xen console defaulting to /dev/tty1.
>
> * Start backend automatically.
>
> * Fix kernel thread to call try_to_freeze().
>
> * Recreate the image sub-object in XendDomainInfo.py on resume.
>
> * Implement frontend resume methods; xm save and restore work now.
>
> * Implement orderly backend shutdown.

Forgot to mention:

* Fix shadow mode guest support based on a patch from Atsushi SAKAI.

[...]

Re: Re: [PATCH 0/2] PV framebuffer

[Steven Smith]

[-- Attachment #1.1: Type: text/plain, Size: 2938 bytes --]

> Next iteration.  If there's anything left in the way of getting this
> merged, please let me know right away.
> 
> Changes since last time:
> 
> * Leave xen console defaulting to /dev/tty1.
> 
> * Start backend automatically.
I'm not entirely happy with the way this is done; I'd much rather the
device controller started the backend than the image controller.  I
can probably fix this up more easily than you.

> * Fix kernel thread to call try_to_freeze().
> 
> * Recreate the image sub-object in XendDomainInfo.py on resume.
Why did you do this?  I can't see that it has anything to do with the
pvfb work, and everything seems to still work when I get rid of this
part of the patch.

> To activate the framebuffer, you have to put the following lines into
> /etc/xen/DOMNAME:
> 
>     vfb = 'yes'
>     vkbd = 'yes'
> 
> and either
> 
>     sdl = 1
> 
> or
> 
>     vnc = 1
I'm not entirely happy about this configuration syntax:

-- It's redundant: you can't specify a vfb without a vkbd or
   vice-versa, or the domain won't start, so we might as well get rid
   of the vkbd="yes" business
-- It doesn't give any way of specifying parameters to the backend
-- The configuration for a single device ends up split into several
   different items.  It also depends on stuff outside the usual
   (device) sections in the SXP, which is kind of nasty.
-- It potentially conflicts with the way emulated vga is specified in
   hvm guests.  e.g. you can't specify that emulated vga should be
   exported over vnc while the pv framebuffer should be sdl.  Whether
   you'd ever want to do this is another matter, but it'd be nice if
   we didn't rule it out for reasons as trivial as a bad configuration
   file design.
-- It won't extend to supporting multiple pvfbs
-- It doesn't look much like the syntax for configuring other devices.

I'd prefer something more like this:

vfbs = [ 'type=sdl,listen=127.0.0.1' ]

Again, I can probably fix this up more easily than you, if you don't
object.

> One last thing to consider: I'm not entirely happy with source file
> names and locations.  It's now or never for renames.  Peeves:
> 
> * Frontend source usually lives in drivers/xen/<WHAT>front.  xenfb and
>   xenkbd are exceptions.  Rename to fbfront and kbdfront?  Same for
>   the .c files.  This would also fix the minor annoyance of having the
>   same file name in frontend and backend.
> 
> * Given how closely related xenfb and xenkbd are, I'm not fond of
>   having them in separate directories.  Move kbd into the fb
>   directory?
If it were my patch, I'd put everything in drivers/xen/fbfront, but it
doesn't really make a great deal of difference.

Apart from that, I'm happy with this.  If you send me a patch which
applies cleanly to xen-unstable and is signed-off-by the right people,
I'll check it in and fix the things I mentioned myself.

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

Steven Smith <sos22-xen@srcf.ucam.org> writes:

>> Next iteration.  If there's anything left in the way of getting this
>> merged, please let me know right away.
>> 
>> Changes since last time:
>> 
>> * Leave xen console defaulting to /dev/tty1.
>> 
>> * Start backend automatically.
> I'm not entirely happy with the way this is done; I'd much rather the
> device controller started the backend than the image controller.  I
> can probably fix this up more easily than you.

No problem.

>> * Fix kernel thread to call try_to_freeze().
>> 
>> * Recreate the image sub-object in XendDomainInfo.py on resume.
> Why did you do this?  I can't see that it has anything to do with the
> pvfb work, and everything seems to still work when I get rid of this
> part of the patch.

Without it, the framebuffer doesn't survive a save/restore.

There may well be a better way to restart the backend on restore.

>> To activate the framebuffer, you have to put the following lines into
>> /etc/xen/DOMNAME:
>> 
>>     vfb = 'yes'
>>     vkbd = 'yes'
>> 
>> and either
>> 
>>     sdl = 1
>> 
>> or
>> 
>>     vnc = 1
> I'm not entirely happy about this configuration syntax:
>
> -- It's redundant: you can't specify a vfb without a vkbd or
>    vice-versa, or the domain won't start, so we might as well get rid
>    of the vkbd="yes" business

Absolutely.  It was just the simplest conceivable way to get the thing
to work.

> -- It doesn't give any way of specifying parameters to the backend
> -- The configuration for a single device ends up split into several
>    different items.  It also depends on stuff outside the usual
>    (device) sections in the SXP, which is kind of nasty.
> -- It potentially conflicts with the way emulated vga is specified in
>    hvm guests.  e.g. you can't specify that emulated vga should be
>    exported over vnc while the pv framebuffer should be sdl.  Whether
>    you'd ever want to do this is another matter, but it'd be nice if
>    we didn't rule it out for reasons as trivial as a bad configuration
>    file design.
> -- It won't extend to supporting multiple pvfbs
> -- It doesn't look much like the syntax for configuring other devices.
>
> I'd prefer something more like this:
>
> vfbs = [ 'type=sdl,listen=127.0.0.1' ]
>
> Again, I can probably fix this up more easily than you, if you don't
> object.

Not at all.

>> One last thing to consider: I'm not entirely happy with source file
>> names and locations.  It's now or never for renames.  Peeves:
>> 
>> * Frontend source usually lives in drivers/xen/<WHAT>front.  xenfb and
>>   xenkbd are exceptions.  Rename to fbfront and kbdfront?  Same for
>>   the .c files.  This would also fix the minor annoyance of having the
>>   same file name in frontend and backend.
>> 
>> * Given how closely related xenfb and xenkbd are, I'm not fond of
>>   having them in separate directories.  Move kbd into the fb
>>   directory?
> If it were my patch, I'd put everything in drivers/xen/fbfront, but it
> doesn't really make a great deal of difference.
>
> Apart from that, I'm happy with this.  If you send me a patch which
> applies cleanly to xen-unstable and is signed-off-by the right people,
> I'll check it in and fix the things I mentioned myself.

Deal!

Re: [PATCH 0/2] PV framebuffer

[Kasai Takanori]

Hi all,

The keymap is being written in these patches.
However, the keymap seems to be 101 keyboard layout.
Therefore, other keyboard layouts cannot be used.

I think that the mechanism that keyboard layout is selected like qemu-dm is 
necessary.
How do you think about it?

Thanks,
Takanori Kasai

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

"Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:

> Hi all,
>
> The keymap is being written in these patches.

Are you talking about sdlfb or vncfb?

> However, the keymap seems to be 101 keyboard layout.
> Therefore, other keyboard layouts cannot be used.

sdlfb works with scancodes and its mapping to Linux input layer
keycodes assumes a standard AT or PS/2 keyboard.

vncfb can't work with scancodes, because LibVNCServer doesn't provide
them.  It has to work with key symbols instead.  This can't work in
general, see the source code for why.  Its mapping to Linux keycodes
assumes you're using the usual US keymap.

> I think that the mechanism that keyboard layout is selected like
> qemu-dm is necessary.
> How do you think about it?

Nobody coded it yet.  It would sure be useful.

Re: [PATCH 0/2] PV framebuffer

[Ewan Mellor]

On Tue, Nov 21, 2006 at 06:50:30AM +0100, Markus Armbruster wrote:

> "Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:
> 
> > Hi all,
> >
> > The keymap is being written in these patches.
> 
> Are you talking about sdlfb or vncfb?
> 
> > However, the keymap seems to be 101 keyboard layout.
> > Therefore, other keyboard layouts cannot be used.
> 
> sdlfb works with scancodes and its mapping to Linux input layer
> keycodes assumes a standard AT or PS/2 keyboard.
> 
> vncfb can't work with scancodes, because LibVNCServer doesn't provide
> them.  It has to work with key symbols instead.  This can't work in
> general, see the source code for why.  Its mapping to Linux keycodes
> assumes you're using the usual US keymap.
> 
> > I think that the mechanism that keyboard layout is selected like
> > qemu-dm is necessary.
> > How do you think about it?
> 
> Nobody coded it yet.  It would sure be useful.

I think you could steal the keymaps from QEMU, and the parsing and translation
code.  That would be good, because we would have only one set of keymaps to
maintain.  That translation between VNC's X11 keysyms and the appropriate
scancode has been all written once (for QEMU's VNC frontend), so it would be
good if you could take advantage of that.

Cheers,

Ewan.

Re: [PATCH 0/2] PV framebuffer

[Kasai Takanori]

Hi Markus and Ewan,

I confirmed it with paraVM image made by virt-manager on RHEL5β2. 
The keyboard used for the input is Japanese keyboard.(jp106) 
The key input as follows is input by mistake. 

@           ->  2
 :          ->  ;
' (shift+7) ->  "
=           ->  +

I think that it cannot use except for 101 keyboard.  

Do you think that you should support other keyboards?

It cannot be at least used with a Japanese keyboard. 

Thanks,
Takanori Kasai

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

"Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:

> Hi Markus and Ewan,
>
> I confirmed it with paraVM image made by virt-manager on RHEL5β2. The
> keyboard used for the input is Japanese keyboard.(jp106) The key input
> as follows is input by mistake.
>
> @           ->  2
> :          ->  ;
> ' (shift+7) ->  "
> =           ->  +
>
> I think that it cannot use except for 101 keyboard.

VNC or SDL?

vncfb is expected to behave strangely unless you use the US keymap.

sdlfb is expected to behave strangely unless you have a PS/2 keyboard.
Your 106er should qualify, although the extra five keys may or may not
work.  Note that you need to configure the keymap in the guest.

> Do you think that you should support other keyboards?

Certainly.

> It cannot be at least used with a Japanese keyboard.
>
> Thanks,
> Takanori Kasai

Re: [PATCH 0/2] PV framebuffer

[Kasai Takanori]

Hi Markus and Ewan,

>> I confirmed it with paraVM image made by virt-manager on RHEL5β2. The
>> keyboard used for the input is Japanese keyboard.(jp106) The key input
>> as follows is input by mistake.
>>
>> @           ->  2
>> :          ->  ;
>> ' (shift+7) ->  "
>> =           ->  +
>>
>> I think that it cannot use except for 101 keyboard.
>
> VNC or SDL?
>
> vncfb is expected to behave strangely unless you use the US keymap.

Sorry, I was not answering your question.
I am talking about vncfb.

The function to select keyboard layout is provided in qemu-dm.
I contributed the patch to select keyboard layout from configuration file the 
other day.


>I think you could steal the keymaps from QEMU, and the parsing and translation
>code.  That would be good, because we would have only one set of keymaps to
>maintain.  That translation between VNC's X11 keysyms and the appropriate
>scancode has been all written once (for QEMU's VNC frontend), so it would be
>good if you could take advantage of that.

It is necessary to transplant the function that convert
between VNC's X11 keysyms and the appropriate scancode from qemu-dm.

Should I do it?


Thanks
Takanori Kasai 

Re: [PATCH 0/2] PV framebuffer

[Markus Armbruster]

"Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:

> Hi Markus and Ewan,
>
>>> I confirmed it with paraVM image made by virt-manager on RHEL5β2. The
>>> keyboard used for the input is Japanese keyboard.(jp106) The key input
>>> as follows is input by mistake.
>>>
>>> @           ->  2
>>> :          ->  ;
>>> ' (shift+7) ->  "
>>> =           ->  +
>>>
>>> I think that it cannot use except for 101 keyboard.
>>
>> VNC or SDL?
>>
>> vncfb is expected to behave strangely unless you use the US keymap.
>
> Sorry, I was not answering your question.
> I am talking about vncfb.
>
> The function to select keyboard layout is provided in qemu-dm.
> I contributed the patch to select keyboard layout from configuration
> file the other day.
>
>
>>I think you could steal the keymaps from QEMU, and the parsing and translation
>>code.  That would be good, because we would have only one set of keymaps to
>>maintain.  That translation between VNC's X11 keysyms and the appropriate
>>scancode has been all written once (for QEMU's VNC frontend), so it would be
>>good if you could take advantage of that.
>
> It is necessary to transplant the function that convert
> between VNC's X11 keysyms and the appropriate scancode from qemu-dm.
>
> Should I do it?

I take free, working, maintainable code any day :)

I'd love to see LibVNCServer replaced by the QEMU VNC code
alltogether.  I haven't found the time to look into this myself.
Perhaps that would be an even better use of your time.