lkml.org 
[lkml]   [2011]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] kvm: make vcpu life cycle separated from kvm instance
    On Mon, Dec 05, 2011 at 01:39:37PM +0800, Liu ping fan wrote:
    > On Sun, Dec 4, 2011 at 8:10 PM, Gleb Natapov <gleb@redhat.com> wrote:
    > > On Sun, Dec 04, 2011 at 07:53:37PM +0800, Liu ping fan wrote:
    > >> On Sat, Dec 3, 2011 at 2:26 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
    > >> > On 2011-12-02 07:26, Liu Ping Fan wrote:
    > >> >> From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
    > >> >>
    > >> >> Currently, vcpu can be destructed only when kvm instance destroyed.
    > >> >> Change this to vcpu's destruction taken when its refcnt is zero,
    > >> >> and then vcpu MUST and CAN be destroyed before kvm's destroy.
    > >> >
    > >> > I'm lacking the big picture yet (would be good to have in the change log
    > >> > - at least I'm too lazy to read the code):
    > >> >
    > >> > What increments the refcnt, what decrements it again? IOW, how does user
    > >> > space controls the life-cycle of a vcpu after your changes?
    > >> >
    > >> In local APIC mode, delivering IPI to target APIC, target's refcnt is
    > >> incremented, and decremented when finished. At other times, using RCU to
    > > Why is this needed?
    > >
    > Suppose the following scene:
    >
    > #define kvm_for_each_vcpu(idx, vcpup, kvm) \
    > for (idx = 0; \
    > idx < atomic_read(&kvm->online_vcpus) && \
    > (vcpup = kvm_get_vcpu(kvm, idx)) != NULL; \
    > idx++)
    >
    > ------------------------------------------------------------------------------------------>
    > Here kvm_vcpu's destruction is called
    > vcpup->vcpu_id ... //oops!
    >
    >
    And this is exactly how your code looks. i.e you do not increment
    reference count in most of the loops, you only increment it twice
    (in pic_unlock() and kvm_irq_delivery_to_apic()) because you are using
    vcpu outside of rcu_read_lock() protected section and I do not see why
    not just extend protected section to include kvm_vcpu_kick(). As far as
    I can see this function does not sleep.

    What should protect vcpu from disappearing in your example above is RCU
    itself if you are using it right. But since I do not see any calls to
    rcu_assign_pointer()/rcu_dereference() I doubt you are using it right
    actually.

    --
    Gleb.


    \
     
     \ /
      Last update: 2011-12-05 09:45    [W:2.280 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site