Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
On Thu, Mar 15, 2012 at 01:23:05PM -0400, Konrad Rzeszutek Wilk wrote: > 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? Konrad, I don't have a good copy of the patch so it you could pick it up that would be great. Thanks. -- Dmitry ___ 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
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 > > > --- > > > 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
Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices
>>> On 15.03.12 at 09:51, Ian Campbell wrote: > On Thu, 2012-03-15 at 08:03 +, Jan Beulich wrote: >> >>> On 14.03.12 at 18:01, Justin Gibbs wrote: >> > While we're talking about fixing ring data structures, can RING_IDX >> > be defined as a "uint32_t" instead of "unsigned int". The structure >> > padding in the ring macros assumes RING_IDX is exactly 4 bytes, >> > so this should be made explicit. ILP64 machines may still be a way >> > out, but the use of non-fixed sized types in places where size really >> > matters just isn't clean. >> >> Yes, if we're going to rev the interface, then any such flaws should be >> corrected. > > There has been talk of doing something similar for netif too. IIRC the > netchannel2 work included a new generic ring scheme with support for > variable sized req/rsp elements and such. > > If we are going to rev the rings then should we try and use a common > ring mechanism? I think so. If so then we could do worse than to start > from the netchannel2 ring stuff and/or concepts? > > Looks like that is > http://xenbits.xen.org/ext/netchannel2/linux-2.6.18/log/075f6677a290/include > /xen/interface/io/uring.h > still a bit nc2 specific though. Taking the concept (and the implementation as a starting point) would seem like a good idea to me. Separate request and reply rings as well as variable size entries would certainly benefit blkif too. Jan ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices
On Thu, 2012-03-15 at 08:03 +, Jan Beulich wrote: > >>> On 14.03.12 at 18:01, Justin Gibbs wrote: > > While we're talking about fixing ring data structures, can RING_IDX > > be defined as a "uint32_t" instead of "unsigned int". The structure > > padding in the ring macros assumes RING_IDX is exactly 4 bytes, > > so this should be made explicit. ILP64 machines may still be a way > > out, but the use of non-fixed sized types in places where size really > > matters just isn't clean. > > Yes, if we're going to rev the interface, then any such flaws should be > corrected. There has been talk of doing something similar for netif too. IIRC the netchannel2 work included a new generic ring scheme with support for variable sized req/rsp elements and such. If we are going to rev the rings then should we try and use a common ring mechanism? I think so. If so then we could do worse than to start from the netchannel2 ring stuff and/or concepts? Looks like that is http://xenbits.xen.org/ext/netchannel2/linux-2.6.18/log/075f6677a290/include/xen/interface/io/uring.h still a bit nc2 specific though. Ian. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices
>>> On 14.03.12 at 18:17, "Justin T. Gibbs" wrote:
> On Mar 6, 2012, at 1:34 AM, Jan Beulich wrote:
>
> On 05.03.12 at 22:49, Santosh Jodh 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.
>
>
>
> --
> Justin
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices
>>> On 14.03.12 at 18:01, Justin Gibbs wrote: > While we're talking about fixing ring data structures, can RING_IDX > be defined as a "uint32_t" instead of "unsigned int". The structure > padding in the ring macros assumes RING_IDX is exactly 4 bytes, > so this should be made explicit. ILP64 machines may still be a way > out, but the use of non-fixed sized types in places where size really > matters just isn't clean. Yes, if we're going to rev the interface, then any such flaws should be corrected. (Also shrinking the Cc list a little.) Jan ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
