All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH v2] Add grant references for fbfront/kbdfront
Date: Tue, 08 Mar 2011 16:03:51 -0500	[thread overview]
Message-ID: <4D7699B7.3030606@tycho.nsa.gov> (raw)
In-Reply-To: <1299581067.17339.468.camel@zakaz.uk.xensource.com>

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@citrix.com>
> 
> 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. */

  reply	other threads:[~2011-03-08 21:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-07 20:11 [PATCH v2] Add grant references for fbfront/kbdfront Daniel De Graaf
2011-03-07 20:11 ` [PATCH 1/3] xen-fbfront: Read width/height from backend Daniel De Graaf
2011-03-07 20:11 ` [PATCH 2/3] xen-fbfront: Use grant references when requested Daniel De Graaf
2011-03-09 21:53   ` Konrad Rzeszutek Wilk
2011-03-09 22:36     ` [PATCH 2/3 v2] " Daniel De Graaf
2011-03-07 20:11 ` [PATCH 3/3] xen-kbdfront: Add grant reference for shared page Daniel De Graaf
2011-03-08 10:44 ` [PATCH v2] Add grant references for fbfront/kbdfront Ian Campbell
2011-03-08 21:03   ` Daniel De Graaf [this message]
2011-03-09 10:31     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D7699B7.3030606@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.