qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Guest stop notification


From: Eric B Munson
Subject: Re: [Qemu-devel] [PATCH] Guest stop notification
Date: Thu, 1 Dec 2011 12:22:44 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden>
> > Cc: address@hidden
> > Cc: address@hidden
> > Cc: address@hidden
> > Cc: address@hidden
> > Cc: address@hidden
> > Cc: address@hidden
> > ---
> >  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.

> 
> Why do we need a new IOCTL for this? Was there no space left in the
> kvm_run structure e.g. to pass this flag down on next vcpu execution? No
> big deal, just wondering.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
> 

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]