Re: [PATCH] kvm: make vcpu life cycle separated from kvm instance

[Liu ping fan]

On Sun, Dec 4, 2011 at 8:10 PM, Gleb Natapov <gleb@xxxxxxxxxx> 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@xxxxxxxxxxx> wrote:
>> > On 2011-12-02 07:26, Liu Ping Fan wrote:
>> >> From: Liu Ping Fan <pingfank@xxxxxxxxxxxxxxxxxx>
>> >>
>> >> 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!


Regards,
ping fan



>> protect the vcpu's reference from its destruction.
>>
>> If kvm_vcpu is not needed by guest, user space can close the
>> kvm_vcpu's file
>> descriptors, and then,if the kvm_vcpu has crossed the period of local
>> APCI mode's reference,it will be destroyed.
>>
>> Regards,
>> ping fan
>>
>> > Thanks,
>> > Jan
>> >
>> > --
>> > Siemens AG, Corporate Technology, CT T DE IT 1
>> > Corporate Competence Center Embedded Linux
>
> --
> Â Â Â Â Â Â Â Â Â Â Â ÂGleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/