From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH v2] Add grant references for fbfront/kbdfront Date: Tue, 08 Mar 2011 16:03:51 -0500 Message-ID: <4D7699B7.3030606@tycho.nsa.gov> References: <1299528672-5299-1-git-send-email-dgdegra@tycho.nsa.gov> <1299581067.17339.468.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1299581067.17339.468.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , "konrad.wilk@oracle.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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 > > 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. 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. --- 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. */