Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices

2012-03-15 Thread Jan Beulich 
 On 14.03.12 at 18:17, Justin T. Gibbs gi...@scsiguy.com wrote:
 On Mar 6, 2012, at 1:34 AM, Jan Beulich wrote:
 
 On 05.03.12 at 22:49, Santosh Jodh santosh.j...@citrix.com wrote:
 
 …
 
 +   }
 +
/* Create shared ring, alloc event channel. */
err = setup_blkring(dev, info);
if (err)
 @@ -889,12 +916,35 @@ again:
goto destroy_blkring;
}
 
 -   err = xenbus_printf(xbt, dev-nodename,
 -   ring-ref, %u, info-ring_ref);
 -   if (err) {
 -   message = writing ring-ref;
 -   goto abort_transaction;
 +   if (legacy_backend) {
 
 Why not use the simpler interface always when info-ring_order == 0?
 
 Because, as I just found out today via a FreeBSD bug report, that's
 not how XenServer works.  If the front-end publishes ring-page-order,
 the backend assumes the ring-refNN XenStore nodes are in effect,
 even if the order is 0.

I was certainly implying to not write the ring-page-order and
num-ring-pages nodes in that case.

 I'm working on a documentation update for blkif.h now.
 
 sigh
 
 --
 Justin


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps

2012-03-15 Thread Konrad Rzeszutek Wilk 
On Wed, Jan 11, 2012 at 11:29:20AM -0500, Andrew Jones wrote:
 
 
 - Original Message -
  On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
   PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
   but
   they don't use the xen frame buffer frontend. For this case it
   doesn't
  
  Ok, but PV does?
   make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
   XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
   i.e.
   if you're using xenfb, then you'll want xenkbd. Switch the
   dependencies.
  
  That sounds like it would be universal irregardless if it is
  PV or PVonHVM?
 
 This patch makes it such that if you want to use both, then you must
 select both. It also says that if you want FB, then you need the
 KBD. However, if you only want the KBD then you're fine with just
 that. So there isn't any risk of breaking configs designed to use
 FB, because FB should be manually selected for those configs anyway.

Dmitry,

I am OK with this patch. Should I pick it up on my tree for 3.4 or
are you OK doing it via your tree?

Thanks!
 
 Drew
 
   
   Signed-off-by: Andrew Jones drjo...@redhat.com
   ---
drivers/input/misc/Kconfig |2 +-
drivers/video/Kconfig  |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
   
   diff --git a/drivers/input/misc/Kconfig
   b/drivers/input/misc/Kconfig
   index 22d875f..36c15bf 100644
   --- a/drivers/input/misc/Kconfig
   +++ b/drivers/input/misc/Kconfig
   @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C

config INPUT_XEN_KBDDEV_FRONTEND
 tristate Xen virtual keyboard and mouse support
   - depends on XEN_FBDEV_FRONTEND
   + depends on XEN
 default y
 select XEN_XENBUS_FRONTEND
 help
   diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
   index d83e967..3e38c2f 100644
   --- a/drivers/video/Kconfig
   +++ b/drivers/video/Kconfig
   @@ -2263,7 +2263,7 @@ config FB_VIRTUAL

config XEN_FBDEV_FRONTEND
 tristate Xen virtual frame buffer support
   - depends on FB  XEN
   + depends on FB  XEN  INPUT_XEN_KBDDEV_FRONTEND
 select FB_SYS_FILLRECT
 select FB_SYS_COPYAREA
 select FB_SYS_IMAGEBLIT
   --
   1.7.7.5
   
   
   ___
   Xen-devel mailing list
   xen-de...@lists.xensource.com
   http://lists.xensource.com/xen-devel
  
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization