* Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
From: Rusty Russell @ 2012-01-22 22:53 UTC (permalink / raw)
To: Michael S. Tsirkin, Benjamin Herrenschmidt
Cc: Christian Borntraeger, Pawel Moll, Sasha Levin, Anthony Liguori,
virtualization
In-Reply-To: <20120118152949.GA2665@redhat.com>
On Wed, 18 Jan 2012 17:29:49 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Jan 13, 2012 at 01:32:42PM +1100, Benjamin Herrenschmidt wrote:
> > Your interrupt may take an unpredictable amount of time to arrive, I
> > don't see how you can use that as a guarantee.
>
> In theory yes.
> Practically, under current KVM, what would delay it?
Indeed, if we're talking about a bandaid, this is fine. For the config
change, I do think we need something more robust.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 1/2] virtio: fix typos of memory barriers
From: Rusty Russell @ 2012-01-22 23:07 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20120122114746.GC27222@redhat.com>
On Sun, 22 Jan 2012 13:47:46 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Jan 20, 2012 at 04:16:59PM +0800, Jason Wang wrote:
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Good catch.
> Note: this fixes a bug introduced by
> 7b21e34fd1c272e3a8c3846168f2f6287a4cd72b.
> It's probably a good idea to mention
> this is the commit log.
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Thanks, applied!
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 2/2] virtio: correct the memory barrier in virtqueue_kick_prepare()
From: Rusty Russell @ 2012-01-22 23:34 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20120122114757.GD27222@redhat.com>
On Sun, 22 Jan 2012 13:47:57 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Jan 20, 2012 at 04:17:08PM +0800, Jason Wang wrote:
> > Use virtio_mb() to make sure the available index to be exposed before
> > checking the the avail event. Otherwise we may get stale value of
> > avail event in guest and never kick the host after.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Good catch.
> Note: this fixes a bug introduced by ee7cd8981e15bcb365fc762afe3fc47b8242f630.
Indeed, great catch. It replaces the missing barrier, and after some
careful thought I've convinced myself that it is necessary for both the
avail index and flag cases.
> > START_USE(vq);
> > - /* Descriptors and available array need to be set before we expose the
> > - * new available array entries. */
> > - virtio_wmb(vq);
> > + /* We need expose available array entries before checking avail
>
> Nit:
> We need expose -> Need to expose
>
> > + * event. */
> > + virtio_mb(vq);
Fixed typo and applied.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 4/4] xen kconfig: describe xen tmem in the config menu
From: Konrad Rzeszutek Wilk @ 2012-01-23 18:34 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <1325842991-4404-5-git-send-email-drjones@redhat.com>
On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
> Add a description to the config menu for xen tmem.
I am not sure what this patch gets us. If this is to minimize the
size of the module - so say it gets loaded, but tmem-enabled is
not set nor cleancache and we just have it consuming memory - we can do it
via returning -ENODEV on the module load.
Like this (completley untested nor compiled tested):
From 45b49b5d565c52e4396dae036ddb4f4094d914ec Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 13:32:17 -0500
Subject: [PATCH] xen/tmem: Return -ENODEV if the backends are not registered.
.. otherwise the driver might still reside in the memory consuming
memory (that is the theory at least).
CC: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
drivers/xen/tmem.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index d369965..e61b5a3 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -377,8 +377,10 @@ static struct frontswap_ops tmem_frontswap_ops = {
static int __init xen_tmem_init(void)
{
+ bool loaded = false;
+
if (!xen_domain())
- return 0;
+ return -ENODEV;
#ifdef CONFIG_FRONTSWAP
if (tmem_enabled && use_frontswap) {
char *s = "";
@@ -390,6 +392,7 @@ static int __init xen_tmem_init(void)
s = " (WARNING: frontswap_ops overridden)";
printk(KERN_INFO "frontswap enabled, RAM provided by "
"Xen Transcendent Memory\n");
+ loaded = true;
}
#endif
#ifdef CONFIG_CLEANCACHE
@@ -402,9 +405,10 @@ static int __init xen_tmem_init(void)
s = " (WARNING: cleancache_ops overridden)";
printk(KERN_INFO "cleancache enabled, RAM provided by "
"Xen Transcendent Memory%s\n", s);
+ loaded = true;
}
#endif
- return 0;
+ return loaded ? 0 : -ENODEV;
}
module_init(xen_tmem_init)
--
1.7.7.5
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/xen/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 1d24061..7e8d728 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -143,7 +143,7 @@ config SWIOTLB_XEN
> select SWIOTLB
>
> config XEN_TMEM
> - bool
> + bool "Xen Transcendent Memory (tmem)"
> default y if (CLEANCACHE || FRONTSWAP)
> help
> Shim to interface in-kernel Transcendent Memory hooks
> --
> 1.7.7.5
^ permalink raw reply related
* Re: [PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
From: Konrad Rzeszutek Wilk @ 2012-01-23 18:35 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <1325842991-4404-3-git-send-email-drjones@redhat.com>
On Fri, Jan 06, 2012 at 10:43:09AM +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
> 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.
This looks OK. Let me test this out to see if there is any silly
fallout.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/input/misc/Kconfig | 2 +-
> drivers/video/Kconfig | 1 +
> 2 files changed, 2 insertions(+), 1 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..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> select FB_DEFERRED_IO
> + select INPUT_XEN_KBDDEV_FRONTEND
> select XEN_XENBUS_FRONTEND
> default y
> help
> --
> 1.7.7.5
^ permalink raw reply
* Re: [PATCH 3/4] xen kconfig: add dom0 support help text
From: Konrad Rzeszutek Wilk @ 2012-01-23 18:42 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <1325842991-4404-4-git-send-email-drjones@redhat.com>
On Fri, Jan 06, 2012 at 10:43:10AM +0100, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.
So I had this reply in my draft and forgot to send it. Sorry about that.
My understanding from the converstion was that we try to "squash"
the XEN_DOM0 option so that it would not be present. But that did not
work as it lead to a string of X86_LOCAL_APIC, X86_IO_ACPI, ACPI, PCI,
and so on. Then the .h with #define XEN_something based on those
symbols, but that is not the job of a header file. It is the job
of Kconfig.
The other way was to squash this in with the backend support. Since
we are moving away from having one initial domain, to having
multitple "initial domains" (priviliged domains) where each can
server as a backend. However (quoting Jeremy) "it is more of
disaggregating the privilege to reduce the amount concentrated in any one
part. Backends don't need any more privilege than to be able to
access the specific device(s) they're being the backend for."
Interestingly, that means DOM0 is kind of .. well, it should be
no different from a normal HVM guest. The old-style PV dom0 remains
would be ..well, almost nothing. The Xen MMU, and Xen SWIOTLB - those
are the ones that pop in mind for Dom0, but they are also used
for PV PCI. In fact, all (I think?) of the CONFIG_XEN_DOM0 functionality
can be _used_ in a PV guest. The 'if (initial_xen_domain()' should
probably be addressed first and to figure which one of those can be
altered as the "backend domain" can run both frontend and backend drivers
(oh joy!). So more relaxing those config options and/or "if (xen..)".
Anyhow, back to the HVM dom0 - that is in the future - and it is going
to take a couple of years to get it. I would rather not shoot my
foot by removing these CONFIG_* option until we get a better grasp of how
we want to deal with the PV hybrid.
What I am saying is that I don't know what the right answer is,
but I don't believe the patch below is it. I wish I had a better
answer in terms of "do this instead", but none of those worked.
Perhaps we can brainstorm some of this at XenSummit by which time
I hope Mukesh's PV hybrid work will be completed and a lot of the
work on the toolstack for backend drivers will be laid out.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> arch/x86/xen/Kconfig | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
> Xen hypervisor.
>
> config XEN_DOM0
> - def_bool y
> + bool "Xen Initial Domain (Dom0) support"
> + default y
> depends on XEN && PCI_XEN && SWIOTLB_XEN
> depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> + help
> + This allows the kernel to be used for the initial Xen domain,
> + Domain0. This is a privileged guest that supplies backends
> + and is used to manage the other Xen domains.
>
> # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
> # name in tools.
> --
> 1.7.7.5
^ permalink raw reply
* Re: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to __attribute__((format(scanf, ...)
From: Konrad Rzeszutek Wilk @ 2012-01-24 1:47 UTC (permalink / raw)
To: Joe Perches
Cc: Jeremy Fitzhardinge, xen-devel, Konrad Rzeszutek Wilk,
linux-kernel, virtualization, Andy Whitcroft, Andrew Morton
In-Reply-To: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
On Fri, Jan 20, 2012 at 04:01:12PM -0800, Joe Perches wrote:
> It's equivalent to __printf, so prefer __scanf.
So ... looking at this patch it just seems to macro-fy the
__printf and __scanf attributes. Is this required to make
cleanpatch.pl work easier?
And there is also some checkpatch.pl features. Should that part
be in a seperate patch?
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> include/linux/compiler-gcc.h | 3 ++-
> include/linux/kernel.h | 8 ++++----
> include/xen/xenbus.h | 4 ++--
> scripts/checkpatch.pl | 6 ++++++
> 4 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 3fd17c2..e5834aa 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -87,7 +87,8 @@
> */
> #define __pure __attribute__((pure))
> #define __aligned(x) __attribute__((aligned(x)))
> -#define __printf(a,b) __attribute__((format(printf,a,b)))
> +#define __printf(a, b) __attribute__((format(printf, a, b)))
> +#define __scanf(a, b) __attribute__((format(scanf, a, b)))
> #define noinline __attribute__((noinline))
> #define __attribute_const__ __attribute__((__const__))
> #define __maybe_unused __attribute__((unused))
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e834342..30f21ec 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -315,10 +315,10 @@ extern __printf(2, 3)
> char *kasprintf(gfp_t gfp, const char *fmt, ...);
> extern char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
>
> -extern int sscanf(const char *, const char *, ...)
> - __attribute__ ((format (scanf, 2, 3)));
> -extern int vsscanf(const char *, const char *, va_list)
> - __attribute__ ((format (scanf, 2, 0)));
> +extern __scanf(2, 3)
> +int sscanf(const char *, const char *, ...);
> +extern __scanf(2, 0)
> +int vsscanf(const char *, const char *, va_list);
>
> extern int get_option(char **str, int *pint);
> extern char *get_options(const char *str, int nints, int *ints);
> diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
> index e8c599b..0a7515c 100644
> --- a/include/xen/xenbus.h
> +++ b/include/xen/xenbus.h
> @@ -139,9 +139,9 @@ int xenbus_transaction_start(struct xenbus_transaction *t);
> int xenbus_transaction_end(struct xenbus_transaction t, int abort);
>
> /* Single read and scanf: returns -errno or num scanned if > 0. */
> +__scanf(4, 5)
> int xenbus_scanf(struct xenbus_transaction t,
> - const char *dir, const char *node, const char *fmt, ...)
> - __attribute__((format(scanf, 4, 5)));
> + const char *dir, const char *node, const char *fmt, ...);
>
> /* Single printf and write: returns -errno or 0. */
> __printf(4, 5)
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index e3bfcbe..2b52aeb 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3117,6 +3117,12 @@ sub process {
> "__printf(string-index, first-to-check) is preferred over __attribute__((format(printf, string-index, first-to-check)))\n" . $herecurr);
> }
>
> +# Check for __attribute__ format(scanf, prefer __scanf
> + if ($line =~ /\b__attribute__\s*\(\s*\(\s*format\s*\(\s*scanf\b/) {
> + WARN("PREFER_SCANF",
> + "__scanf(string-index, first-to-check) is preferred over __attribute__((format(scanf, string-index, first-to-check)))\n" . $herecurr);
> + }
> +
> # check for sizeof(&)
> if ($line =~ /\bsizeof\s*\(\s*\&/) {
> WARN("SIZEOF_ADDRESS",
> --
> 1.7.8.111.gad25c.dirty
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to __attribute__((format(scanf, ...)
From: Joe Perches @ 2012-01-24 2:00 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge, xen-devel, Konrad Rzeszutek Wilk,
linux-kernel, virtualization, Andy Whitcroft, Andrew Morton
In-Reply-To: <20120124014717.GA24204@andromeda.dapyr.net>
On Mon, 2012-01-23 at 21:47 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 20, 2012 at 04:01:12PM -0800, Joe Perches wrote:
> > It's equivalent to __printf, so prefer __scanf.
> So ... looking at this patch it just seems to macro-fy the
> __printf and __scanf attributes.
It's just for __scanf. The __printf change is just
a neatening/spacing change.
> Is this required to make
> cleanpatch.pl work easier?
No. It's a trivial symmetry patch added to
make fewer uses of __attribute__((format(...)
similar to the __printf commit from awhile ago.
commit b9075fa968a0a4347aef35e235e2995c0e57dddd
> And there is also some checkpatch.pl features. Should that part
> be in a seperate patch?
I think it's OK to do the whole thing at once.
^ permalink raw reply
* How to measure time for program running in guest OS?
From: Jidong Xiao @ 2012-01-24 4:09 UTC (permalink / raw)
To: virtualization
Hi,
I am running a guest OS (Fedora 16) with kvm (The host is
OpenSuse11.3), and now I have a program running inside the guest OS
and I want to measure how long the program will run. The accuracy I
need is microsecond. Since we are in the virtualization environment, I
wonder how can we measure the time duration accurately. Can anyone
give me some suggestions, thank you!!
Regards
Jidong
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the config menu
From: Igor Mammedov @ 2012-01-24 8:30 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Andrew Jones, xen-devel, jeremy, virtualization
In-Reply-To: <20120123183454.GA12542@phenom.dumpdata.com>
On 01/23/2012 07:34 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
>> Add a description to the config menu for xen tmem.
>
> I am not sure what this patch gets us. If this is to minimize the
> size of the module - so say it gets loaded, but tmem-enabled is
> not set nor cleancache and we just have it consuming memory - we can do it
> via returning -ENODEV on the module load.
But why compile in something that one may never use? At least with this patch
I'll have a choice to turn it off if I don't need it.
For example when I build hardened kernel, I'd like to turn of all unnecessary
features for a particular config (i.e. reduce attack surface as much as possible).
--
Thanks,
Igor
^ permalink raw reply
* Re: [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Avi Kivity @ 2012-01-24 14:08 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Raghavendra K T, linux-doc, Peter Zijlstra, Jan Kiszka,
Srivatsa Vaddagiri, Paul Mackerras, H. Peter Anvin,
Stefano Stabellini, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, Sasha Levin, Sedat Dilek, Thomas Gleixner,
Virtualization, LKML, Dave Hansen
In-Reply-To: <4F173F0F.5020604@goop.org>
On 01/18/2012 11:52 PM, Jeremy Fitzhardinge wrote:
> On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
> >
> >> That logic relies on the "kick" being level triggered, so that "kick"
> >> before "block" will cause the block to fall out immediately. If you're
> >> using "hlt" as the block and it has the usual edge-triggered behaviour,
> >> what stops a "kick-before-hlt" from losing the kick?
> > Hmm ..'hlt' should result in a check for kick request (in hypervisor
> > context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
> > will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check
> > before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
> >
> > Won't that trap the 'kick-before-hlt' case? What am I missing here?
>
> Nothing, that sounds fine. It wasn't clear to me that your kick
> operation left persistent state, and so has a level-triggered effect on hlt.
>
btw, this persistent state needs to be saved/restored for live
migration. Best to put it into some MSR.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the config menu
From: Konrad Rzeszutek Wilk @ 2012-01-24 17:38 UTC (permalink / raw)
To: Igor Mammedov; +Cc: Andrew Jones, xen-devel, jeremy, virtualization
In-Reply-To: <4F1E6C17.7060609@redhat.com>
On Tue, Jan 24, 2012 at 09:30:15AM +0100, Igor Mammedov wrote:
> On 01/23/2012 07:34 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
> >>Add a description to the config menu for xen tmem.
> >
> >I am not sure what this patch gets us. If this is to minimize the
> >size of the module - so say it gets loaded, but tmem-enabled is
> >not set nor cleancache and we just have it consuming memory - we can do it
> >via returning -ENODEV on the module load.
>
> But why compile in something that one may never use? At least with this patch
> I'll have a choice to turn it off if I don't need it.
Then this patch is misleading. It should state at the start
what its purpose is. It sounds like adding the description is just
a way for the real purpose of this patch - which is to disable tmem.
> For example when I build hardened kernel, I'd like to turn of all unnecessary
> features for a particular config (i.e. reduce attack surface as much as possible).
The 'tmem' gets turned off if you disable cleancache. Can't you just
disable cleancache in your hardened config?
^ permalink raw reply
* Re: [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Raghavendra K T @ 2012-01-24 18:51 UTC (permalink / raw)
To: Avi Kivity
Cc: Jeremy Fitzhardinge, Greg Kroah-Hartman, linux-doc,
Peter Zijlstra, Jan Kiszka, Srivatsa Vaddagiri, Paul Mackerras,
H. Peter Anvin, Stefano Stabellini, Xen, Dave Jiang, KVM,
Glauber Costa, X86, Ingo Molnar, Rik van Riel,
Konrad Rzeszutek Wilk, Sasha Levin, Sedat Dilek, Thomas Gleixner,
Virtualization, LKML, Dave Hansen, Suzuki
In-Reply-To: <4F1EBB73.3000705@redhat.com>
On 01/24/2012 07:38 PM, Avi Kivity wrote:
> On 01/18/2012 11:52 PM, Jeremy Fitzhardinge wrote:
>> On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
>>>
>>>> That logic relies on the "kick" being level triggered, so that "kick"
>>>> before "block" will cause the block to fall out immediately. If you're
>>>> using "hlt" as the block and it has the usual edge-triggered behaviour,
>>>> what stops a "kick-before-hlt" from losing the kick?
>>> Hmm ..'hlt' should result in a check for kick request (in hypervisor
>>> context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
>>> will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check
>>> before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
>>>
>>> Won't that trap the 'kick-before-hlt' case? What am I missing here?
>>
>> Nothing, that sounds fine. It wasn't clear to me that your kick
>> operation left persistent state, and so has a level-triggered effect on hlt.
>>
>
> btw, this persistent state needs to be saved/restored for live
> migration. Best to put it into some MSR.
>
I did not quite get it. Did you mean, add a new MSR to msrs_to_save[],
and may be retain only the kicked/pv_unhalt flag (persistent state) and
get rid of PVLOCK_KICK vcpu->request?
^ permalink raw reply
* Re: [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Raghavendra K T @ 2012-01-24 19:01 UTC (permalink / raw)
To: Marcelo Tosatti, Avi Kivity
Cc: Jeremy Fitzhardinge, Raghavendra K T, linux-doc, Peter Zijlstra,
Jan Kiszka, Virtualization, Paul Mackerras, H. Peter Anvin,
Stefano Stabellini, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
Srivatsa Vaddagiri, Sasha Levin, Sedat Dilek, Thomas Gleixner,
Greg Kroah-Hartman, LKML
In-Reply-To: <4F15C48F.1000000@linux.vnet.ibm.com>
On 01/18/2012 12:27 AM, Raghavendra K T wrote:
> On 01/17/2012 04:32 PM, Marcelo Tosatti wrote:
>> On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
[...]
>>> + || (vcpu->requests& ~(1UL<<KVM_REQ_PVLOCK_KICK))
>>> + || need_resched() || signal_pending(current)) {
>>> vcpu->mode = OUTSIDE_GUEST_MODE;
>>> smp_wmb();
>>> local_irq_enable();
>>> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>>> !vcpu->arch.apf.halted)
>>> || !list_empty_careful(&vcpu->async_pf.done)
>>> || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
>>> + || kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
>>
>> The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
>> on vcpu entry (along with the other kvm_check_request processing).
>>
[...]
>
> I had tried alternative approach earlier, I think that is closer
> to your expectation.
>
> where
> - flag is read in kvm_arch_vcpu_runnable
> - flag cleared in vcpu entry along with others.
>
> But it needs per vcpu flag to remember that pv_unhalted while clearing
> the flag in vcpu enter [ patch below ]. Could not find third alternative
> though.
[...]
> do you think having pv_unhalt flag in below patch cause problem to
> live migration still? (vcpu->request bit is retained as is) OR do we
> have to have KVM_GET_MP_STATE changes also with below patch you
> mentioned earlier.
>
Avi, Marcello, Please let me know, any comments you have on how should
it look like in next version?
Should I get rid of KVM_REQ_PVLOCK_KICK bit in vcpu->request and have
only pv_unahlt flag as below and also add MSR as suggested?
> ---8<---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..1bf8fa8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5684,6 +5717,11 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> r = 1;
> goto out;
> }
> + if (kvm_check_request(KVM_REQ_PVKICK, vcpu)) {
> + vcpu->pv_unhalted = 1;
> + r = 1;
> + goto out;
> + }
> if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
> record_steal_time(vcpu);
> if (kvm_check_request(KVM_REQ_NMI, vcpu))
> @@ -6683,6 +6720,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> !vcpu->arch.apf.halted)
> || !list_empty_careful(&vcpu->async_pf.done)
> || vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> + || (kvm_test_request(KVM_REQ_PVKICK, vcpu) || vcpu->pv_unhalted)
> || atomic_read(&vcpu->arch.nmi_queued) ||
> (kvm_arch_interrupt_allowed(vcpu) &&
> kvm_cpu_has_interrupt(vcpu));
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d526231..a48e0f2 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -154,6 +155,8 @@ struct kvm_vcpu {
> #endif
>
> struct kvm_vcpu_arch arch;
> +
> + int pv_unhalted;
> };
>
> static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> @@ -770,5 +773,12 @@ static inline bool kvm_check_request(int req,
> struct kvm_vcpu *vcpu)
> }
> }
>
> +static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
> +{
> + if (test_bit(req, &vcpu->requests))
> + return true;
> + else
> + return false;
> +}
> #endif
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d9cfb78..55c44a2 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm
> *kvm, unsigned id)
> vcpu->kvm = kvm;
> vcpu->vcpu_id = id;
> vcpu->pid = NULL;
> + vcpu->pv_unhalted = 0;
> init_waitqueue_head(&vcpu->wq);
> kvm_async_pf_vcpu_init(vcpu);
>
> @@ -1509,11 +1510,12 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
> void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> {
> DEFINE_WAIT(wait);
> for (;;) {
> prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
>
> if (kvm_arch_vcpu_runnable(vcpu)) {
> + vcpu->pv_unhalted = 0;
> kvm_make_request(KVM_REQ_UNHALT, vcpu);
> break;
> }
>
^ permalink raw reply
* Re: [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support for KVM guests
From: Raghavendra K T @ 2012-01-25 8:55 UTC (permalink / raw)
To: Alexander Graf
Cc: Jeremy Fitzhardinge, Greg Kroah-Hartman, linux-doc,
Peter Zijlstra, Jan Kiszka, Srivatsa Vaddagiri, Paul Mackerras,
H. Peter Anvin, Stefano Stabellini, Xen, Dave Jiang, KVM,
Glauber Costa, X86, Ingo Molnar, Avi Kivity, Rik van Riel,
Konrad Rzeszutek Wilk, Sasha Levin, Sedat Dilek, Thomas Gleixner,
Virtualization, LKML, Dave Hansen
In-Reply-To: <4F15BFAE.7060500@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]
On 01/18/2012 12:06 AM, Raghavendra K T wrote:
> On 01/17/2012 11:09 PM, Alexander Graf wrote:
[...]
>>>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> B. pre-3.2.0 + Jeremy's above patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> C. pre-3.2.0 + Jeremy's above patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = y
>>>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = n
>>>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with
>>>>> CONFIG_PARAVIRT_SPINLOCKS = y
[...]
>> Maybe it'd be a good idea to create a small in-kernel microbenchmark
>> with a couple threads that take spinlocks, then do work for a
>> specified number of cycles, then release them again and start anew. At
>> the end of it, we can check how long the whole thing took for n runs.
>> That would enable us to measure the worst case scenario.
>>
>
> It was a quick test. two iteration of kernbench (=6runs) and had ensured
> cache is cleared.
>
> echo "1" > /proc/sys/vm/drop_caches
> ccache -C. Yes may be I can run test as you mentioned..
>
Sorry for late reply. Was trying to do more performance analysis.
Measured the worst case scenario with a spinlock stress driver
[ attached below ]. I think S1 (below) is what you were
looking for:
2 types of scenarios:
S1.
lock()
increment counter.
unlock()
S2:
do_somework()
lock()
do_conditional_work() /* this is to give variable spinlock hold time */
unlock()
Setup:
Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
core , 64GB RAM, 16 online cpus.
The below results are taken across total 18 Runs of
insmod spinlock_thread.ko nr_spinlock_threads=4 loop_count=4000000
Results:
scenario S1: plain counter
==========================
total Mega cycles taken for completion (std)
A. 12343.833333 (1254.664021)
B. 12817.111111 (917.791606)
C. 13426.555556 (844.882978)
%improvement w.r.t BASE -8.77
scenario S2: counter with variable work inside lock + do_work_outside_lock
=========================================================================
A. 25077.888889 (1349.471703)
B. 24906.777778 (1447.853874)
C. 21287.000000 (2731.643644)
%improvement w.r.t BASE 15.12
So it seems we have worst case overhead of around 8%. But we see
improvement of at-least 15% once when little more time is spent in
critical section.
>>>
>>> Guest Run
>>> ============
>>> case A case B %improvement case C %improvement
>>> 166.999 (15.7613) 161.876 (14.4874) 3.06768 161.24 (12.6497) 3.44852
>>
>> Is this the same machine? Why is the guest 3x slower?
> Yes non - ple machine but with all 16 cpus online. 3x slower you meant
> case A is slower (pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n) ?
Got your point, There were multiple reasons. guest was 32 bit, and had
only 8vcpu and the current RAM was only 1GB (max 4GB) when I increased
it to 4GB it came around just 127 second.
There is a happy news:
I created a new 64 bit guest and ran with 16GB RAM and 16VCPU.
Kernbench in The pv spinlock (case E) took just around 42sec (against
57 sec of host), an improvement of around 26% against host.
So its much faster rather than 3x slower.
[-- Attachment #2: spinlock_thread.c --]
[-- Type: text/x-csrc, Size: 3529 bytes --]
/*
* spinlock_thread.c
*
* Author: Raghavendra K T
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/sched.h>
#include <linux/kthread.h>
#include <asm/msr.h>
unsigned int start, end, diff;
static struct task_struct **spintask_pid;
static DECLARE_COMPLETION(spintask_exited);
static int total_thread_exit = 0;
static DEFINE_SPINLOCK(counter_spinlock);
#define DEFAULT_NR_THREADS 4
#define DEFAULT_LOOP_COUNT 4000000L
static int nr_spinlock_threads = DEFAULT_NR_THREADS;
static long loop_count = DEFAULT_LOOP_COUNT;
module_param(nr_spinlock_threads, int, S_IRUGO);
module_param(loop_count, long, S_IRUGO);
static long count = 0;
static int a[2][2] = {{2, 5}, {3, 7}};
static int b[2][2] = {{1, 19}, {11, 13}};
static int m[2][2];
static int n[2][2];
static int res[2][2];
static inline void matrix_initialize(int id)
{
int i, j;
for (i=0; i<2; i++)
for(j=0; j<2; j++) {
m[i][j] = (id + 1) * a[i][j];
n[i][j] = (id + 1) * b[i][j];
}
}
static inline void matrix_mult(void)
{
int i, j, k;
for (i=0; i<2; i++)
for (j=0; j<2; j++) {
res[i][j] = 0;
for(k=0; k<2; k++)
res[i][j] += m[i][k] * n[k][j];
}
}
static int input_check_thread(void* arg)
{
int id = (int)arg;
long i = loop_count;
allow_signal(SIGKILL);
#if 0
matrix_initialize(id);
matrix_mult();
#endif
do {
spin_lock(&counter_spinlock);
count++;
#if 0
if (id%3)
matrix_initialize(id);
else if (id%3 + 1)
matrix_mult();
#endif
spin_unlock(&counter_spinlock);
} while(i--);
spin_lock(&counter_spinlock);
total_thread_exit++;
spin_unlock(&counter_spinlock);
if(total_thread_exit == nr_spinlock_threads) {
rdtscl(end);
diff = end - start;
complete_and_exit(&spintask_exited, 0);
}
return 0;
}
static int spinlock_init_module(void)
{
int i;
char name[20];
printk(KERN_INFO "insmod nr_spinlock_threads = %d\n", nr_spinlock_threads);
spintask_pid = kzalloc(sizeof(struct task_struct *)* nr_spinlock_threads, GFP_KERNEL);
rdtscl(start);
for (i=0; i<nr_spinlock_threads; i++)
{
sprintf(name, "spintask%d", i);
spintask_pid[i] = kthread_run(input_check_thread,(void *)i, name);
}
return 0;
}
static void spinlock_cleanup_module(void)
{
wait_for_completion(&spintask_exited);
kfree(spintask_pid);
printk(KERN_INFO "rmmod count = %ld time elaspsed=%u\n", count, diff);
}
module_init(spinlock_init_module);
module_exit(spinlock_cleanup_module);
MODULE_PARM_DESC(loopcount, "How many iterations counter should be incremented");
MODULE_PARM_DESC(nr_spinlock_threads, "How many kernel threads to be spawned");
MODULE_AUTHOR("Raghavendra K T");
MODULE_DESCRIPTION("spinlock stress driver");
MODULE_LICENSE("GPL");
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support for KVM guests
From: Konrad Rzeszutek Wilk @ 2012-01-25 16:35 UTC (permalink / raw)
To: Raghavendra K T
Cc: Jeremy Fitzhardinge, Greg Kroah-Hartman, linux-doc,
Peter Zijlstra, Jan Kiszka, Srivatsa Vaddagiri, Paul Mackerras,
H. Peter Anvin, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Avi Kivity, Rik van Riel, Stefano Stabellini,
Sasha Levin, Sedat Dilek, Thomas Gleixner, Virtualization, LKML,
Dave Hansen, Suzuki Poulose
In-Reply-To: <4F1FC370.5020506@linux.vnet.ibm.com>
On Wed, Jan 25, 2012 at 02:25:12PM +0530, Raghavendra K T wrote:
> On 01/18/2012 12:06 AM, Raghavendra K T wrote:
> >On 01/17/2012 11:09 PM, Alexander Graf wrote:
> [...]
> >>>>>A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>B. pre-3.2.0 + Jeremy's above patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>C. pre-3.2.0 + Jeremy's above patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = y
> >>>>>D. pre-3.2.0 + Jeremy's above patches + V5 patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = n
> >>>>>E. pre-3.2.0 + Jeremy's above patches + V5 patches with
> >>>>>CONFIG_PARAVIRT_SPINLOCKS = y
> [...]
> >>Maybe it'd be a good idea to create a small in-kernel microbenchmark
> >>with a couple threads that take spinlocks, then do work for a
> >>specified number of cycles, then release them again and start anew. At
> >>the end of it, we can check how long the whole thing took for n runs.
> >>That would enable us to measure the worst case scenario.
> >>
> >
> >It was a quick test. two iteration of kernbench (=6runs) and had ensured
> >cache is cleared.
> >
> >echo "1" > /proc/sys/vm/drop_caches
> >ccache -C. Yes may be I can run test as you mentioned..
> >
>
> Sorry for late reply. Was trying to do more performance analysis.
> Measured the worst case scenario with a spinlock stress driver
> [ attached below ]. I think S1 (below) is what you were
> looking for:
>
> 2 types of scenarios:
> S1.
> lock()
> increment counter.
> unlock()
>
> S2:
> do_somework()
> lock()
> do_conditional_work() /* this is to give variable spinlock hold time */
> unlock()
>
> Setup:
> Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
> core , 64GB RAM, 16 online cpus.
> The below results are taken across total 18 Runs of
> insmod spinlock_thread.ko nr_spinlock_threads=4 loop_count=4000000
>
> Results:
> scenario S1: plain counter
> ==========================
> total Mega cycles taken for completion (std)
> A. 12343.833333 (1254.664021)
> B. 12817.111111 (917.791606)
> C. 13426.555556 (844.882978)
>
> %improvement w.r.t BASE -8.77
>
> scenario S2: counter with variable work inside lock + do_work_outside_lock
> =========================================================================
> A. 25077.888889 (1349.471703)
> B. 24906.777778 (1447.853874)
> C. 21287.000000 (2731.643644)
>
> %improvement w.r.t BASE 15.12
>
> So it seems we have worst case overhead of around 8%. But we see
> improvement of at-least 15% once when little more time is spent in
> critical section.
Is this with collecting the histogram information about spinlocks? We found
that if you enable that for production runs it makes them quite slower.
^ permalink raw reply
* Re: [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support for KVM guests
From: Raghavendra K T @ 2012-01-25 17:45 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge, Greg Kroah-Hartman, linux-doc,
Peter Zijlstra, Jan Kiszka, Srivatsa Vaddagiri, Paul Mackerras,
H. Peter Anvin, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Avi Kivity, Rik van Riel, Stefano Stabellini,
Sasha Levin, Sedat Dilek, Thomas Gleixner, Virtualization, LKML,
Dave Hansen, Suzuki Poulose
In-Reply-To: <20120125163552.GB23999@phenom.dumpdata.com>
On 01/25/2012 10:05 PM, Konrad Rzeszutek Wilk wrote:
>> So it seems we have worst case overhead of around 8%. But we see
>> improvement of at-least 15% once when little more time is spent in
>> critical section.
>
> Is this with collecting the histogram information about spinlocks? We found
> that if you enable that for production runs it makes them quite slower.
>
Ok. Are you referring to CONFIG_KVM_DEBUG_FS/CONFIG_XEN_DEBUG_FS?. Not
it was not enabled. But then may be I was not precise. This test was
only on native. So it should have not affected IMO.
It is nice to know that histogram affects, since I was always under the
impression that it does not affect much on guest too. My experiments
had almost always enabled that.
Let me know if you referred to something else..
^ permalink raw reply
* lguest documentation
From: Stephen Hemminger @ 2012-01-25 17:57 UTC (permalink / raw)
To: Rusty Russell, Davidlohr Bueso; +Cc: virtualization
After moving lguest to tools the documentation index was not updated.
Documentation/virtual/00-INDEX still refers to lguest/ when in fact
the documentation is now over in tools/lguest. Maybe make a symlink,
or change the reference in the index?
^ permalink raw reply
* [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: K. Y. Srinivasan @ 2012-01-25 18:29 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering, jbottomley,
hch, linux-scsi
Cc: K. Y. Srinivasan
The storage driver (storvsc_drv.c) handles all block storage devices
assigned to Linux guests hosted on Hyper-V. This driver has been in the
staging tree for a while and this patch moves it out of the staging area.
This patch is based on the storvsc patches that are already on Greg's queue
for the staging tree. This patch-set addressed Christoph's review comments.
If need be, I can re-send this patch-set in Greg's queue
or I can send the fully patched storvsc_drv.c.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/scsi/Kconfig | 7 +++++++
drivers/scsi/Makefile | 3 +++
drivers/{staging/hv => scsi}/storvsc_drv.c | 0
3 files changed, 10 insertions(+), 0 deletions(-)
rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 16570aa..d3d18e8 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -662,6 +662,13 @@ config VMWARE_PVSCSI
To compile this driver as a module, choose M here: the
module will be called vmw_pvscsi.
+config HYPERV_STORAGE
+ tristate "Microsoft Hyper-V virtual storage driver"
+ depends on SCSI && HYPERV
+ default HYPERV
+ help
+ Select this option to enable the Hyper-V virtual storage driver.
+
config LIBFC
tristate "LibFC module"
select SCSI_FC_ATTRS
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 2b88749..e4c1a69 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_SCSI_BNX2_ISCSI) += libiscsi.o bnx2i/
obj-$(CONFIG_BE2ISCSI) += libiscsi.o be2iscsi/
obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o
obj-$(CONFIG_VMWARE_PVSCSI) += vmw_pvscsi.o
+obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
obj-$(CONFIG_ARM) += arm/
@@ -170,6 +171,8 @@ scsi_mod-$(CONFIG_SCSI_PROC_FS) += scsi_proc.o
scsi_mod-y += scsi_trace.o
scsi_mod-$(CONFIG_PM) += scsi_pm.o
+hv_storvsc-y := storvsc_drv.o
+
scsi_tgt-y += scsi_tgt_lib.o scsi_tgt_if.o
sd_mod-objs := sd.o
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
similarity index 100%
rename from drivers/staging/hv/storvsc_drv.c
rename to drivers/scsi/storvsc_drv.c
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support for KVM guests
From: Konrad Rzeszutek Wilk @ 2012-01-25 19:05 UTC (permalink / raw)
To: Raghavendra K T
Cc: Jeremy Fitzhardinge, Greg Kroah-Hartman, linux-doc,
Peter Zijlstra, Jan Kiszka, Srivatsa Vaddagiri, Paul Mackerras,
H. Peter Anvin, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Avi Kivity, Rik van Riel, Stefano Stabellini,
Sasha Levin, Sedat Dilek, Thomas Gleixner, Virtualization, LKML,
Dave Hansen, Suzuki Poulose
In-Reply-To: <4F203FC0.70907@linux.vnet.ibm.com>
On Wed, Jan 25, 2012 at 11:15:36PM +0530, Raghavendra K T wrote:
> On 01/25/2012 10:05 PM, Konrad Rzeszutek Wilk wrote:
> >>So it seems we have worst case overhead of around 8%. But we see
> >>improvement of at-least 15% once when little more time is spent in
> >>critical section.
> >
> >Is this with collecting the histogram information about spinlocks? We found
> >that if you enable that for production runs it makes them quite slower.
> >
>
> Ok. Are you referring to CONFIG_KVM_DEBUG_FS/CONFIG_XEN_DEBUG_FS?. Not
Those were the ones.
> it was not enabled. But then may be I was not precise. This test was
> only on native. So it should have not affected IMO.
Yup.
>
> It is nice to know that histogram affects, since I was always under the
> impression that it does not affect much on guest too. My experiments
> had almost always enabled that.
>
> Let me know if you referred to something else..
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: James Bottomley @ 2012-01-26 16:07 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, ohering, hch,
linux-scsi
In-Reply-To: <1327516187-21793-1-git-send-email-kys@microsoft.com>
On Wed, 2012-01-25 at 10:29 -0800, K. Y. Srinivasan wrote:
> The storage driver (storvsc_drv.c) handles all block storage devices
> assigned to Linux guests hosted on Hyper-V. This driver has been in the
> staging tree for a while and this patch moves it out of the staging area.
>
> This patch is based on the storvsc patches that are already on Greg's queue
> for the staging tree. This patch-set addressed Christoph's review comments.
> If need be, I can re-send this patch-set in Greg's queue
> or I can send the fully patched storvsc_drv.c.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/scsi/Kconfig | 7 +++++++
> drivers/scsi/Makefile | 3 +++
> drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> 3 files changed, 10 insertions(+), 0 deletions(-)
> rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
This doesn't compile:
make[3]: *** No rule to make target `drivers/staging/hv/storvsc_drv.o',
needed by `drivers/staging/hv/hv_storvsc.o'. Stop.
make[3]: *** Waiting for unfinished jobs....
LD drivers/staging/hv/built-in.o
make[2]: *** [drivers/staging/hv] Error 2
make[1]: *** [drivers/staging] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
You need to remove the staging Kconfig/Makefile remnants as well.
James
^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: Rolf Eike Beer @ 2012-01-26 17:17 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, ohering, jbottomley,
hch, linux-scsi
In-Reply-To: <1327516187-21793-1-git-send-email-kys@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
Am Mittwoch 25 Januar 2012, 10:29:47 schrieb K. Y. Srinivasan:
> The storage driver (storvsc_drv.c) handles all block storage devices
> assigned to Linux guests hosted on Hyper-V. This driver has been in the
> staging tree for a while and this patch moves it out of the staging area.
>
> This patch is based on the storvsc patches that are already on Greg's queue
> for the staging tree. This patch-set addressed Christoph's review comments.
> If need be, I can re-send this patch-set in Greg's queue
> or I can send the fully patched storvsc_drv.c.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/scsi/Kconfig | 7 +++++++
> drivers/scsi/Makefile | 3 +++
> drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> 3 files changed, 10 insertions(+), 0 deletions(-)
> rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
>
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 16570aa..d3d18e8 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -662,6 +662,13 @@ config VMWARE_PVSCSI
> To compile this driver as a module, choose M here: the
> module will be called vmw_pvscsi.
>
> +config HYPERV_STORAGE
> + tristate "Microsoft Hyper-V virtual storage driver"
> + depends on SCSI && HYPERV
> + default HYPERV
> + help
> + Select this option to enable the Hyper-V virtual storage driver.
> +
> config LIBFC
> tristate "LibFC module"
> select SCSI_FC_ATTRS
> diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
> index 2b88749..e4c1a69 100644
I still miss a "this driver will be called ..." message here, as it is used
e.g. by the entry before:
> To compile this driver as a module, choose M here: the
> module will be called vmw_pvscsi.
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the staging area
From: KY Srinivasan @ 2012-01-26 17:24 UTC (permalink / raw)
To: Rolf Eike Beer
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
ohering@suse.com, jbottomley@parallels.com, hch@infradead.org,
linux-scsi@vger.kernel.org
In-Reply-To: <4414328.OlPOtXe4lZ@eto>
> -----Original Message-----
> From: Rolf Eike Beer [mailto:eike-kernel@sf-tec.de]
> Sent: Thursday, January 26, 2012 12:17 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; ohering@suse.com;
> jbottomley@parallels.com; hch@infradead.org; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH 1/1] Staging: hv: storvsc: Move the storage driver out of the
> staging area
>
> Am Mittwoch 25 Januar 2012, 10:29:47 schrieb K. Y. Srinivasan:
> > The storage driver (storvsc_drv.c) handles all block storage devices
> > assigned to Linux guests hosted on Hyper-V. This driver has been in the
> > staging tree for a while and this patch moves it out of the staging area.
> >
> > This patch is based on the storvsc patches that are already on Greg's queue
> > for the staging tree. This patch-set addressed Christoph's review comments.
> > If need be, I can re-send this patch-set in Greg's queue
> > or I can send the fully patched storvsc_drv.c.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/scsi/Kconfig | 7 +++++++
> > drivers/scsi/Makefile | 3 +++
> > drivers/{staging/hv => scsi}/storvsc_drv.c | 0
> > 3 files changed, 10 insertions(+), 0 deletions(-)
> > rename drivers/{staging/hv => scsi}/storvsc_drv.c (100%)
> >
> > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> > index 16570aa..d3d18e8 100644
> > --- a/drivers/scsi/Kconfig
> > +++ b/drivers/scsi/Kconfig
> > @@ -662,6 +662,13 @@ config VMWARE_PVSCSI
> > To compile this driver as a module, choose M here: the
> > module will be called vmw_pvscsi.
> >
> > +config HYPERV_STORAGE
> > + tristate "Microsoft Hyper-V virtual storage driver"
> > + depends on SCSI && HYPERV
> > + default HYPERV
> > + help
> > + Select this option to enable the Hyper-V virtual storage driver.
> > +
> > config LIBFC
> > tristate "LibFC module"
> > select SCSI_FC_ATTRS
> > diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
> > index 2b88749..e4c1a69 100644
>
> I still miss a "this driver will be called ..." message here, as it is used
> e.g. by the entry before:
After I moved the file to the scsi directory, in my haste I forgot to git add
the file. Sorry for the confusion; I will send out the corrected patches soon.
Regards,
K. Y
^ permalink raw reply
* [PATCH 0000/0002] Staging: hv: Move the storage driver out of staging
From: K. Y. Srinivasan @ 2012-01-26 17:37 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering, jbottomley,
hch, linux-scsi
Cc: K. Y. Srinivasan
Now that all the relevant maintainers have signed off on moving the Hyper-V
storage driver out of staging, this patch-set moves the driver out of staging:
1. The first patch brings the storage driver in synch with the patches in
Greg's queue for the staging tree. Back on Jan 12, 2012, I had sent a
patch-set to address all of Christoph's comments. Christoph has signed off
on these patches.
2. The second patch moves the updated storage driver out of staging and gets rid
of the unnecessary files in the staging/hv/directory.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 1/2] Staging: hv: Applied all the patches already in the staging queue
From: Greg KH @ 2012-01-26 17:37 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: linux-kernel, devel, virtualization, ohering, jbottomley, hch,
linux-scsi
In-Reply-To: <1327599515-12679-1-git-send-email-kys@microsoft.com>
On Thu, Jan 26, 2012 at 09:38:34AM -0800, K. Y. Srinivasan wrote:
> This patch gets the storage driver to the same level as in the staging tree.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/staging/hv/storvsc_drv.c | 1301 ++++++++++++++++++-------------------
> 1 files changed, 633 insertions(+), 668 deletions(-)
What? That changelog comment makes no sense at all, as you are patching
the staging version of the driver. This isn't an acceptable patch at
all.
Yes, I have pending patches for this driver in my "to-apply" queue, but
that is for 3.4, not now.
So, how about I just apply those patches, and then apply a patch that
moves it out of staging into drivers/scsi/, and queue all of those up
for 3.4.
James, any objection to that?
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox