From: Gleb Natapov <gleb@redhat.com>
To: Liu ping fan <kernelfans@gmail.com>
Cc: Avi Kivity <avi@redhat.com>,
aliguori@us.ibm.com, kvm@vger.kernel.org, qemu-devel@nongnu.org,
linux-kernel@vger.kernel.org, ryanh@us.ibm.com,
jan.kiszka@web.de
Subject: Re: [Qemu-devel] [PATCH 2/2] kvm: exit to userspace with reason KVM_EXIT_VCPU_DEAD
Date: Mon, 28 Nov 2011 10:46:43 +0200 [thread overview]
Message-ID: <20111128084643.GP2557@redhat.com> (raw)
In-Reply-To: <CAFgQCTscektJsC-2ThQn7FhHA7=Qf4t3t0+X+i0zT_yZZjwL0g@mail.gmail.com>
On Mon, Nov 28, 2011 at 03:16:01PM +0800, Liu ping fan wrote:
> On Sun, Nov 27, 2011 at 6:50 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Nov 27, 2011 at 12:36:55PM +0200, Avi Kivity wrote:
> >> On 11/27/2011 04:42 AM, Liu Ping Fan wrote:
> >> > From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> >> >
> >> > The vcpu can be safely released when
> >> > --1.guest tells us that the vcpu is not needed any longer.
> >> > --2.vcpu hits the last instruction _halt_
> >> >
> >> > If both of the conditions are satisfied, kvm exits to userspace
> >> > with the reason vcpu dead. So the user thread can exit safely.
> >> >
> >> >
> >>
> >> Seems to be completely unnecessary. If you want to exit from the vcpu
> >> thread, send it a signal.
> >>
> Hi Avi and Gleb,
>
> First, I wanted to make sure my assumption is right, so I can grab
> your meaning more clearly -:). Could you elaborate it for me, thanks.
>
> I had thought that when a vcpu was being removed from guest, kvm must
> satisfy the following conditions to safely remove the vcpu:
> --1. The tasks on vcpu in GUEST have already been migrated to other
> vcpus and ONLY idle_task left ---- The CPU_DEAD is the checkpoint.
> --2. We must wait the idle task to hit native_halt() in GUEST, till
> that time, this vcpu is no needed even by idle_task. In KVM, the vcpu
> thread will finally sit on "kvm_vcpu_block(vcpu);"
> We CAN NOT suppose the sequence of the two condition because they come
> from different threads. Am I right?
>
No, KVM can remove vcpu whenever it told to do so (may be not in the
middle of emulated io though). It is a guest responsibility to eject cpu
only when it is safe to do so from guest's point of view.
> And here comes my question,
> --1. I think the signal will make vcpu_run exit to user, but is it
> allow vcpu thread to finally call "kernel/exit.c : void do_exit(long
> code)" in current code in kvm or in qemu?
Yes. Why not?
> --2. If we got CPU_DEAD event, and then send a signal to vcpu thread,
> could we ensure that we have already sit on "kvm_vcpu_block(vcpu);"
CPU_DEAD event is internal to a guest (one of them). KVM does not care
about it. And to remove vcpu it does not have to sit in kvm_vcpu_block().
And actually since signal kicks vcpu thread out from kernel into userspace
you can be sure it is not sitting in kvm_vcpu_block().
>
> Thanks and regards,
> ping fan
>
> > Also if guest "tells us that the vcpu is not needed any longer" (via
> > ACPI I presume) and vcpu actually doing something critical instead of
> > sitting in 1:hlt; jmp 1b loop then it is guest's problem if it stops
> > working after vcpu destruction.
> >
>
>
> > --
> > Gleb.
> >
--
Gleb.
WARNING: multiple messages have this Message-ID (diff)
From: Gleb Natapov <gleb@redhat.com>
To: Liu ping fan <kernelfans@gmail.com>
Cc: aliguori@us.ibm.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
ryanh@us.ibm.com, jan.kiszka@web.de, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] kvm: exit to userspace with reason KVM_EXIT_VCPU_DEAD
Date: Mon, 28 Nov 2011 10:46:43 +0200 [thread overview]
Message-ID: <20111128084643.GP2557@redhat.com> (raw)
In-Reply-To: <CAFgQCTscektJsC-2ThQn7FhHA7=Qf4t3t0+X+i0zT_yZZjwL0g@mail.gmail.com>
On Mon, Nov 28, 2011 at 03:16:01PM +0800, Liu ping fan wrote:
> On Sun, Nov 27, 2011 at 6:50 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Nov 27, 2011 at 12:36:55PM +0200, Avi Kivity wrote:
> >> On 11/27/2011 04:42 AM, Liu Ping Fan wrote:
> >> > From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> >> >
> >> > The vcpu can be safely released when
> >> > --1.guest tells us that the vcpu is not needed any longer.
> >> > --2.vcpu hits the last instruction _halt_
> >> >
> >> > If both of the conditions are satisfied, kvm exits to userspace
> >> > with the reason vcpu dead. So the user thread can exit safely.
> >> >
> >> >
> >>
> >> Seems to be completely unnecessary. If you want to exit from the vcpu
> >> thread, send it a signal.
> >>
> Hi Avi and Gleb,
>
> First, I wanted to make sure my assumption is right, so I can grab
> your meaning more clearly -:). Could you elaborate it for me, thanks.
>
> I had thought that when a vcpu was being removed from guest, kvm must
> satisfy the following conditions to safely remove the vcpu:
> --1. The tasks on vcpu in GUEST have already been migrated to other
> vcpus and ONLY idle_task left ---- The CPU_DEAD is the checkpoint.
> --2. We must wait the idle task to hit native_halt() in GUEST, till
> that time, this vcpu is no needed even by idle_task. In KVM, the vcpu
> thread will finally sit on "kvm_vcpu_block(vcpu);"
> We CAN NOT suppose the sequence of the two condition because they come
> from different threads. Am I right?
>
No, KVM can remove vcpu whenever it told to do so (may be not in the
middle of emulated io though). It is a guest responsibility to eject cpu
only when it is safe to do so from guest's point of view.
> And here comes my question,
> --1. I think the signal will make vcpu_run exit to user, but is it
> allow vcpu thread to finally call "kernel/exit.c : void do_exit(long
> code)" in current code in kvm or in qemu?
Yes. Why not?
> --2. If we got CPU_DEAD event, and then send a signal to vcpu thread,
> could we ensure that we have already sit on "kvm_vcpu_block(vcpu);"
CPU_DEAD event is internal to a guest (one of them). KVM does not care
about it. And to remove vcpu it does not have to sit in kvm_vcpu_block().
And actually since signal kicks vcpu thread out from kernel into userspace
you can be sure it is not sitting in kvm_vcpu_block().
>
> Thanks and regards,
> ping fan
>
> > Also if guest "tells us that the vcpu is not needed any longer" (via
> > ACPI I presume) and vcpu actually doing something critical instead of
> > sitting in 1:hlt; jmp 1b loop then it is guest's problem if it stops
> > working after vcpu destruction.
> >
>
>
> > --
> > Gleb.
> >
--
Gleb.
next prev parent reply other threads:[~2011-11-28 8:46 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-25 2:35 [PATCH 0] A series patches for kvm&qemu to enable vcpu destruction in kvm Liu Ping Fan
2011-11-25 2:35 ` [Qemu-devel] " Liu Ping Fan
2011-11-25 2:35 ` Liu Ping Fan
2011-11-25 2:35 ` [PATCH 1/2] kvm: make vcpu life cycle separated from kvm instance Liu Ping Fan
2011-11-25 2:35 ` [Qemu-devel] " Liu Ping Fan
2011-11-25 2:35 ` Liu Ping Fan
2011-11-27 10:36 ` Avi Kivity
2011-11-27 10:36 ` [Qemu-devel] " Avi Kivity
2011-11-27 10:36 ` Avi Kivity
2011-12-02 6:26 ` [PATCH] " Liu Ping Fan
2011-12-02 18:26 ` Jan Kiszka
2011-12-04 11:53 ` Liu ping fan
2011-12-04 12:10 ` Gleb Natapov
2011-12-05 5:39 ` Liu ping fan
2011-12-05 8:41 ` Gleb Natapov
2011-12-06 6:54 ` Liu ping fan
2011-12-06 8:14 ` Gleb Natapov
2011-12-04 10:23 ` Avi Kivity
2011-12-05 5:29 ` Liu ping fan
2011-12-05 5:29 ` Liu ping fan
2011-12-05 9:30 ` Avi Kivity
2011-12-05 9:42 ` Gleb Natapov
2011-12-05 9:58 ` Avi Kivity
2011-12-05 10:18 ` Gleb Natapov
2011-12-05 10:22 ` Avi Kivity
2011-12-05 10:40 ` Gleb Natapov
2011-12-09 5:23 ` [PATCH V2] " Liu Ping Fan
2011-12-09 14:23 ` Gleb Natapov
2011-12-12 2:41 ` [PATCH v3] " Liu Ping Fan
2011-12-12 12:54 ` Gleb Natapov
2011-12-13 9:29 ` Liu ping fan
2011-12-13 9:47 ` Gleb Natapov
2011-12-13 11:36 ` Marcelo Tosatti
2011-12-13 11:54 ` Gleb Natapov
2011-12-15 3:21 ` Liu ping fan
2011-12-15 4:28 ` [PATCH v4] " Liu Ping Fan
2011-12-15 5:33 ` Xiao Guangrong
2011-12-15 6:53 ` Liu ping fan
2011-12-15 8:25 ` Xiao Guangrong
2011-12-15 8:57 ` Xiao Guangrong
2011-12-15 6:48 ` Takuya Yoshikawa
2011-12-16 9:38 ` Marcelo Tosatti
2011-12-17 3:57 ` Liu ping fan
2011-12-19 1:16 ` Takuya Yoshikawa
2011-12-15 9:10 ` Gleb Natapov
2011-12-16 7:50 ` Liu ping fan
2011-12-16 7:50 ` Liu ping fan
2011-12-15 8:33 ` [PATCH v3] " Gleb Natapov
2011-12-15 9:06 ` Liu ping fan
2011-12-15 9:08 ` Gleb Natapov
2011-12-17 3:19 ` [PATCH v5] " Liu Ping Fan
2011-12-26 11:09 ` Gleb Natapov
2011-12-26 11:17 ` Avi Kivity
2011-12-26 11:21 ` Gleb Natapov
2011-12-27 7:53 ` Liu ping fan
2011-12-27 8:38 ` [PATCH v6] " Liu Ping Fan
2011-12-27 11:22 ` Takuya Yoshikawa
2011-12-28 6:54 ` Liu ping fan
2011-12-28 9:53 ` Avi Kivity
2011-12-29 14:03 ` Liu ping fan
2011-12-29 14:31 ` Avi Kivity
2012-01-05 9:35 ` Liu ping fan
2011-12-28 10:29 ` Takuya Yoshikawa
2011-12-28 9:53 ` Avi Kivity
2011-12-28 9:54 ` Avi Kivity
2011-12-28 10:19 ` Takuya Yoshikawa
2011-12-28 10:28 ` Avi Kivity
2012-01-07 2:55 ` [PATCH v7] " Liu Ping Fan
2012-01-12 12:37 ` Avi Kivity
2012-01-15 13:17 ` Liu ping fan
2012-01-15 13:37 ` Avi Kivity
2011-11-25 17:54 ` [PATCH 0] A series patches for kvm&qemu to enable vcpu destruction in kvm Jan Kiszka
2011-11-25 17:54 ` [Qemu-devel] " Jan Kiszka
2011-11-25 17:54 ` Jan Kiszka
2011-11-27 3:07 ` Liu ping fan
2011-11-27 3:07 ` [Qemu-devel] " Liu ping fan
2011-11-27 3:07 ` Liu ping fan
2011-11-27 2:42 ` [PATCH 2/2] kvm: exit to userspace with reason KVM_EXIT_VCPU_DEAD Liu Ping Fan
2011-11-27 2:42 ` [Qemu-devel] " Liu Ping Fan
2011-11-27 2:42 ` Liu Ping Fan
2011-11-27 10:36 ` Avi Kivity
2011-11-27 10:36 ` [Qemu-devel] " Avi Kivity
2011-11-27 10:36 ` Avi Kivity
2011-11-27 10:50 ` Gleb Natapov
2011-11-27 10:50 ` [Qemu-devel] " Gleb Natapov
2011-11-27 10:50 ` Gleb Natapov
2011-11-28 7:16 ` Liu ping fan
2011-11-28 8:46 ` Gleb Natapov [this message]
2011-11-28 8:46 ` Gleb Natapov
2011-11-27 2:45 ` [PATCH 1/5] QEMU Add cpu_phyid_to_cpu() to map cpu phyid to CPUState Liu Ping Fan
2011-11-27 2:45 ` [Qemu-devel] " Liu Ping Fan
2011-11-27 2:45 ` Liu Ping Fan
2011-11-27 2:45 ` [PATCH 2/5] QEMU Add cpu_free() to support arch related CPUState release Liu Ping Fan
2011-11-27 2:45 ` [Qemu-devel] " Liu Ping Fan
2011-11-27 2:45 ` Liu Ping Fan
2011-11-27 2:45 ` [PATCH 3/5] QEMU Introduce a pci device "cpustate" to get CPU_DEAD event in guest Liu Ping Fan
2011-11-27 2:45 ` [Qemu-devel] " Liu Ping Fan
2011-11-27 2:45 ` Liu Ping Fan
2011-11-27 10:56 ` Gleb Natapov
2011-11-27 10:56 ` [Qemu-devel] " Gleb Natapov
2011-11-27 10:56 ` Gleb Natapov
2011-11-27 2:45 ` [PATCH 4/5] QEMU Release vcpu and finally exit vcpu thread safely Liu Ping Fan
2011-11-27 2:45 ` [Qemu-devel] " Liu Ping Fan
2011-11-29 5:37 ` ShaoHe Feng
2011-11-27 2:45 ` [PATCH 5/5] QEMU tmp patches for linux-header files Liu Ping Fan
2011-11-27 2:45 ` [Qemu-devel] " Liu Ping Fan
2011-11-27 2:45 ` Liu Ping Fan
2011-11-27 2:47 ` [PATCH] virtio: add a pci driver to notify host the CPU_DEAD event Liu Ping Fan
2011-11-27 2:47 ` [Qemu-devel] " Liu Ping Fan
2011-11-27 2:47 ` Liu Ping Fan
2011-11-27 11:10 ` Gleb Natapov
2011-11-27 11:10 ` [Qemu-devel] " Gleb Natapov
2011-11-27 11:10 ` Gleb Natapov
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=20111128084643.GP2557@redhat.com \
--to=gleb@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kernelfans@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=ryanh@us.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.