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

[Xen-devel] Re: [PATCH v2] Add grant references for fbfront/kbdfront

On Tue, 2011-03-08 at 21:03 +0000, Daniel De Graaf wrote:
> On 03/08/2011 05:44 AM, Ian Campbell wrote:
> > On Mon, 2011-03-07 at 20:11 +0000, Daniel De Graaf wrote:
> >> This series fixes the interface for the fbfront and kbdfront devices,
> >> which were storing MFNs in xenstore rather than creating grant table
> >> entries. To maintain backwards compatibility, a different xenstore key
> >> is used (page-gref instead of page-ref) and the use of grants must be
> >> requested for fbfront (because two levels of page references are
> >> embedded within the shared page). This makes it possible to move a
> >> display server out of dom0 without giving the display domain full access
> >> to other domain's memory.
> > 
> > Looks good to me. I presume this was all tested with the existing
> > backends as well as the separate display server backend?
> > 
> > Under that assumption all 3:
> > 
> > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > 
> > I think it would be good to get the backend patches into the tree as
> > well, to be used even when running in domain 0. Not just for good form
> > but because it should help avoid this stuff from bit-rotting etc which
> > seems like a danger if the only user is your display server.
> > 
> > Ian.
> > 
> 
> The kernel changes have been tested using both qemu-dm (for PV guest; the
> emulated device is still used for HVM) and a custom display server (for
> both PV and HVM). I have not tested using a qemu-dm on HVM guests (dom0 or
> stub-domain), since the default on HVM is to use qemu's own emulated
> graphics card rather than the Xen framebuffer.

OK, thanks.

> Testing on HVM guests requires another patch (below) that I did not submit
> because it will cause HVM domains to delay boot for the 300-second device
> timeout when vfb entries are placed in xenstore without actually providing
> a vfb backend. Unfortunately, this is how XM stores the VNC parameters for
> HVM guests so that they are in the same location as for PV guests
> (tools/python/xen/xend/XendConfig.py line 942), so providing the xenstore
> entries without a backend is a common configuration.

Hrm, I guess that something we'll have to figure out some other time.

Ian.

> ---
> 
> diff --git a/drivers/input/xen-kbdfront.c b/drivers/input/xen-kbdfront.c
> index a5c064e..54b48df 100644
> --- a/drivers/input/xen-kbdfront.c
> +++ b/drivers/input/xen-kbdfront.c
> @@ -358,7 +358,7 @@ static struct xenbus_driver xenkbd_driver = {
>  
>  static int __init xenkbd_init(void)
>  {
> -     if (!xen_pv_domain())
> +     if (!xen_domain())
>               return -ENODEV;
>  
>       /* Nothing to do if running in dom0. */
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index b3107e4..03d7ef3 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -748,7 +748,7 @@ static struct xenbus_driver xenfb_driver = {
>  
>  static int __init xenfb_init(void)
>  {
> -     if (!xen_pv_domain())
> +     if (!xen_domain())
>               return -ENODEV;
>  
>       /* Nothing to do if running in dom0. */



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