Re: [PATCH/RFC] KVM: track pid for VCPU only on KVM_RUN ioctl

Christian Borntraeger
2014-08-19T09:59:41Z

On 19/08/14 11:53, Paolo Bonzini wrote:
> Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
>> On 19/08/14 11:27, Paolo Bonzini wrote:
>>> Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
>>>>>> The patch may be okay, but I'm worried that it might be
>>>>>> hiding a bug in QEMU.
>>>> On s390 we call "KVM_S390_INITIAL_RESET" from several reset
>>>> functions, e.g. during CPU creation. This is the first hickup and
>>>> the pid now points to the main thread.
>>>
>>> Any reason to have a special ioctl instead of
>>> SET_REGS/SET_ONE_REG/... (via kvm_cpu_synchronize_state, which does
>>> the ioctls in the VCPU thread)?
>>
>> Historical reasons mostly. Older kernel miss several interfaces to
>> bring the CPU in a defined state (pending interrupts, cpu state, some
>> registers...)
>>
>> Good news is that we are working on getting rid of it: cpu states are
>> now available as far as I can see, only local interrupt flushing is
>> missing.This needs some more work on our side. So in some month we
>> probably will have a QEMU version that does not need to call this any
>> more. For todays QEMU this patch help though.
>
> Just by the sound of it, interrupt flushing seems dangerous to do in a
> way that could be concurrent with KVM_RUN...

Its only for the interrupts that are cpu local (like pending IPIs). In addition, we would do that only for the reset case (with an interface that can be used for migration).
Right now KVM_S390_INITIAL_RESET takes the vcpu_mutex, so this protects against KVM_RUN.

Christian