Re: [PATCH v2] KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates

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

 



On Tue, Dec 08, 2009 at 04:07:32PM +0200, Avi Kivity wrote:
> On 12/08/2009 04:02 PM, Marcelo Tosatti wrote:
>> On Sun, Dec 06, 2009 at 06:24:15PM +0100, Jan Kiszka wrote:
>>    
>>> User space may not want to overwrite asynchronously changing VCPU event
>>> states on write-back. So allow to skip nmi.pending and sipi_vector by
>>> setting corresponding bits in the flags field of kvm_vcpu_events.
>>>
>>> Signed-off-by: Jan Kiszka<jan.kiszka@xxxxxxxxxxx>
>>>      
>> Can't you handle this in userspace entirely, only updating vcpu_events
>> state when appropriate?
>>    
>
> For what we do now I think you're right, it can be handled in userspace.
>
> But in general, there's currently no way to update vcpu_events without  
> overwriting nmi and sipi_vector, which can also be written concurrently  
> by other vcpus.  So there's a hole in the interface.
>
>> Shouldnt the vcpu be stopped in the first place, when its state is
>> updated?
>>    
>
> It is stopped, but other vcpus are not.

I don't see the need for setting any state in kvm_vcpu_events
automatically, on kernel entry (apparently there was consensus that
saving similar state explicitly in qemu was the way to go).

kvm_arch_put_registers in qemu saves mpstate now that way,
and the same problem is present.

The sites to load vcpu_events would be machine reset and cpu_load
only, right?


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux