From: Marcelo Tosatti <mtosatti@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "ryanh@linux.vnet.ibm.com" <ryanh@linux.vnet.ibm.com>,
"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Eric B Munson <emunson@mgebm.net>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [PATCH] Guest stop notification
Date: Thu, 1 Dec 2011 19:25:03 -0200 [thread overview]
Message-ID: <20111201212503.GB25290@amt.cnet> (raw)
In-Reply-To: <4ED7BB11.1050309@siemens.com>
On Thu, Dec 01, 2011 at 06:36:17PM +0100, Jan Kiszka wrote:
> On 2011-12-01 18:22, Eric B Munson wrote:
> > On Thu, 01 Dec 2011, Jan Kiszka wrote:
> >
> >> On 2011-11-29 22:36, Eric B Munson wrote:
> >>> Often when a guest is stopped from the qemu console, it will report spurious
> >>> soft lockup warnings on resume. There are kernel patches being discussed that
> >>> will give the host the ability to tell the guest that it is being stopped and
> >>> should ignore the soft lockup warning that generates.
> >>>
> >>> Signed-off-by: Eric B Munson <emunson@mgebm.net>
> >>> Cc: ryanh@linux.vnet.ibm.com
> >>> Cc: aliguori@us.ibm.com
> >>> Cc: mtosatti@redhat.com
> >>> Cc: avi@redhat.com
> >>> Cc: kvm@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> ---
> >>> target-i386/kvm.c | 6 ++++++
> >>> 1 files changed, 6 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> >>> index 5bfc21f..defd364 100644
> >>> --- a/target-i386/kvm.c
> >>> +++ b/target-i386/kvm.c
> >>> @@ -336,12 +336,18 @@ static int kvm_inject_mce_oldstyle(CPUState *env)
> >>> return 0;
> >>> }
> >>>
> >>> +static void kvm_put_guest_paused(CPUState *penv)
> >>> +{
> >>> + kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
> >>> +}
> >>
> >> I see no need in encapsulating this in a separate function.
> >>
> >>> +
> >>> static void cpu_update_state(void *opaque, int running, RunState state)
> >>> {
> >>> CPUState *env = opaque;
> >>>
> >>> if (running) {
> >>> env->tsc_valid = false;
> >>> + kvm_put_guest_paused(env);
> >>
> >> checkpatch.pl would have asked you to remove this tab.
> >>
> >> More general:
> >>
> >> Why is this x86-only? If the kernel interface is x86-only, what prevents
> >> making it generic right from the beginning?
> >
> > Sorry, missed this question on the first pass, this is x86 only because the
> > flag used lives in the pvclock structure. AFAICT, there aren't any other
> > architectures out there that implement paravirtualized clocks yet.
>
> That's an implementation "detail" of the kernel. The interface (IOCTL or
> kvm_run field) is generic, no?
>
> I would just fire this notification from generic code, evaluate the
> error (that was lacking so far), and only report it if it's something
> else than "not supported".
Yes, it should live in hw/kvmclock.c preferably.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Eric B Munson <emunson@mgebm.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"ryanh@linux.vnet.ibm.com" <ryanh@linux.vnet.ibm.com>,
"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [PATCH] Guest stop notification
Date: Thu, 1 Dec 2011 19:25:03 -0200 [thread overview]
Message-ID: <20111201212503.GB25290@amt.cnet> (raw)
In-Reply-To: <4ED7BB11.1050309@siemens.com>
On Thu, Dec 01, 2011 at 06:36:17PM +0100, Jan Kiszka wrote:
> On 2011-12-01 18:22, Eric B Munson wrote:
> > On Thu, 01 Dec 2011, Jan Kiszka wrote:
> >
> >> On 2011-11-29 22:36, Eric B Munson wrote:
> >>> Often when a guest is stopped from the qemu console, it will report spurious
> >>> soft lockup warnings on resume. There are kernel patches being discussed that
> >>> will give the host the ability to tell the guest that it is being stopped and
> >>> should ignore the soft lockup warning that generates.
> >>>
> >>> Signed-off-by: Eric B Munson <emunson@mgebm.net>
> >>> Cc: ryanh@linux.vnet.ibm.com
> >>> Cc: aliguori@us.ibm.com
> >>> Cc: mtosatti@redhat.com
> >>> Cc: avi@redhat.com
> >>> Cc: kvm@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> ---
> >>> target-i386/kvm.c | 6 ++++++
> >>> 1 files changed, 6 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> >>> index 5bfc21f..defd364 100644
> >>> --- a/target-i386/kvm.c
> >>> +++ b/target-i386/kvm.c
> >>> @@ -336,12 +336,18 @@ static int kvm_inject_mce_oldstyle(CPUState *env)
> >>> return 0;
> >>> }
> >>>
> >>> +static void kvm_put_guest_paused(CPUState *penv)
> >>> +{
> >>> + kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
> >>> +}
> >>
> >> I see no need in encapsulating this in a separate function.
> >>
> >>> +
> >>> static void cpu_update_state(void *opaque, int running, RunState state)
> >>> {
> >>> CPUState *env = opaque;
> >>>
> >>> if (running) {
> >>> env->tsc_valid = false;
> >>> + kvm_put_guest_paused(env);
> >>
> >> checkpatch.pl would have asked you to remove this tab.
> >>
> >> More general:
> >>
> >> Why is this x86-only? If the kernel interface is x86-only, what prevents
> >> making it generic right from the beginning?
> >
> > Sorry, missed this question on the first pass, this is x86 only because the
> > flag used lives in the pvclock structure. AFAICT, there aren't any other
> > architectures out there that implement paravirtualized clocks yet.
>
> That's an implementation "detail" of the kernel. The interface (IOCTL or
> kvm_run field) is generic, no?
>
> I would just fire this notification from generic code, evaluate the
> error (that was lacking so far), and only report it if it's something
> else than "not supported".
Yes, it should live in hw/kvmclock.c preferably.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "ryanh@linux.vnet.ibm.com" <ryanh@linux.vnet.ibm.com>,
"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Eric B Munson <emunson@mgebm.net>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Guest stop notification
Date: Thu, 1 Dec 2011 19:25:03 -0200 [thread overview]
Message-ID: <20111201212503.GB25290@amt.cnet> (raw)
In-Reply-To: <4ED7BB11.1050309@siemens.com>
On Thu, Dec 01, 2011 at 06:36:17PM +0100, Jan Kiszka wrote:
> On 2011-12-01 18:22, Eric B Munson wrote:
> > On Thu, 01 Dec 2011, Jan Kiszka wrote:
> >
> >> On 2011-11-29 22:36, Eric B Munson wrote:
> >>> Often when a guest is stopped from the qemu console, it will report spurious
> >>> soft lockup warnings on resume. There are kernel patches being discussed that
> >>> will give the host the ability to tell the guest that it is being stopped and
> >>> should ignore the soft lockup warning that generates.
> >>>
> >>> Signed-off-by: Eric B Munson <emunson@mgebm.net>
> >>> Cc: ryanh@linux.vnet.ibm.com
> >>> Cc: aliguori@us.ibm.com
> >>> Cc: mtosatti@redhat.com
> >>> Cc: avi@redhat.com
> >>> Cc: kvm@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> ---
> >>> target-i386/kvm.c | 6 ++++++
> >>> 1 files changed, 6 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> >>> index 5bfc21f..defd364 100644
> >>> --- a/target-i386/kvm.c
> >>> +++ b/target-i386/kvm.c
> >>> @@ -336,12 +336,18 @@ static int kvm_inject_mce_oldstyle(CPUState *env)
> >>> return 0;
> >>> }
> >>>
> >>> +static void kvm_put_guest_paused(CPUState *penv)
> >>> +{
> >>> + kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
> >>> +}
> >>
> >> I see no need in encapsulating this in a separate function.
> >>
> >>> +
> >>> static void cpu_update_state(void *opaque, int running, RunState state)
> >>> {
> >>> CPUState *env = opaque;
> >>>
> >>> if (running) {
> >>> env->tsc_valid = false;
> >>> + kvm_put_guest_paused(env);
> >>
> >> checkpatch.pl would have asked you to remove this tab.
> >>
> >> More general:
> >>
> >> Why is this x86-only? If the kernel interface is x86-only, what prevents
> >> making it generic right from the beginning?
> >
> > Sorry, missed this question on the first pass, this is x86 only because the
> > flag used lives in the pvclock structure. AFAICT, there aren't any other
> > architectures out there that implement paravirtualized clocks yet.
>
> That's an implementation "detail" of the kernel. The interface (IOCTL or
> kvm_run field) is generic, no?
>
> I would just fire this notification from generic code, evaluate the
> error (that was lacking so far), and only report it if it's something
> else than "not supported".
Yes, it should live in hw/kvmclock.c preferably.
next prev parent reply other threads:[~2011-12-01 21:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 21:36 [PATCH] Guest stop notification Eric B Munson
2011-11-29 21:36 ` [Qemu-devel] " Eric B Munson
2011-11-29 21:36 ` Eric B Munson
2011-11-29 22:10 ` Anthony Liguori
2011-11-29 22:10 ` [Qemu-devel] " Anthony Liguori
2011-11-29 22:10 ` Anthony Liguori
2011-12-01 14:37 ` Jan Kiszka
2011-12-01 14:37 ` [Qemu-devel] " Jan Kiszka
2011-12-01 17:19 ` Eric B Munson
2011-12-01 17:19 ` [Qemu-devel] " Eric B Munson
2011-12-01 17:19 ` Eric B Munson
2011-12-01 17:31 ` Arend van Spriel
2011-12-01 17:31 ` [Qemu-devel] " Arend van Spriel
2011-12-01 17:35 ` Jan Kiszka
2011-12-01 17:35 ` [Qemu-devel] " Jan Kiszka
2011-12-01 17:35 ` Jan Kiszka
2011-12-01 17:35 ` Jan Kiszka
2011-12-01 17:35 ` [Qemu-devel] " Jan Kiszka
2011-12-01 17:35 ` Jan Kiszka
2011-12-01 21:22 ` Marcelo Tosatti
2011-12-01 21:22 ` [Qemu-devel] " Marcelo Tosatti
2011-12-01 21:22 ` Marcelo Tosatti
2011-12-01 17:22 ` Eric B Munson
2011-12-01 17:22 ` [Qemu-devel] " Eric B Munson
2011-12-01 17:36 ` Jan Kiszka
2011-12-01 17:36 ` [Qemu-devel] " Jan Kiszka
2011-12-01 17:36 ` Jan Kiszka
2011-12-01 21:25 ` Marcelo Tosatti [this message]
2011-12-01 21:25 ` [Qemu-devel] " Marcelo Tosatti
2011-12-01 21:25 ` Marcelo Tosatti
2011-12-01 21:32 ` Eric B Munson
2011-12-01 21:32 ` [Qemu-devel] " Eric B Munson
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=20111201212503.GB25290@amt.cnet \
--to=mtosatti@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=emunson@mgebm.net \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=ryanh@linux.vnet.ibm.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.