qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 0/7] KVM SMP support, early version


From: Glauber Costa
Subject: Re: [Qemu-devel] Re: [PATCH 0/7] KVM SMP support, early version
Date: Tue, 1 Dec 2009 10:20:33 -0200

On Tue, Dec 1, 2009 at 10:17 AM, Jan Kiszka <address@hidden> wrote:
> Avi Kivity wrote:
>> On 11/30/2009 07:30 PM, Jan Kiszka wrote:
>>>>> No.  But what's wrong with on_vcpu?
>>>>>
>>>> intrinsically racy. signal passing slow down things, etc.
>>>>
>>>> That said, as I've stated many times: I don't believe there's anything
>>>> fundamentally wrong with on_vcpu. But we might get benefits from a 
>>>> re-design
>>>> of things to avoid it whenever possible. (just like the vcpu_reset()
>>>> I've just posted)
>>>>
>>>>
>>> If you don't want immediate execution of update_guest_debug, save the
>>> state that shall be transferred, set some flag, and run the transfer
>>> before guest entry inside the vcpu threads (after putting the registers
>>> as older kernels may otherwise overwrite the flags register). Should
>>> work, may even avoid redundant calls during a gdb session.
>>>
>>
>> There's no guarantee the vcpu will ever exit to qemu, so you have to
>> signal the vcpu thread anyway.  When you do that, you might as well load
>> the new state.
>
> Debugging is special here as it involves vmstop before you start playing
> with the debug settings. But I may also oversee some corner case right now.
>

I imagined so. In this case, it might be better to set a flag before
vmstop, and then
honor it on vcpu entry. I had this feeling that in most cases where we
current signal the
vcpu, the VM will be already stopped anyway, so we don't need to resignal.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."




reply via email to

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