[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.