On 12.12.2017 19:18, Roman Kagan wrote: > On Tue, Dec 12, 2017 at 05:29:02PM +0100, David Hildenbrand wrote: >> On 12.12.2017 17:22, Paolo Bonzini wrote: >>> On 12/12/2017 17:07, Roman Kagan wrote: >>>> + idx = srcu_read_lock(&vcpu->kvm->srcu); >>>> + ret = kvm_vcpu_read_guest(vcpu, gpa, ¶m, sizeof(param)); >>>> + srcu_read_unlock(&vcpu->kvm->srcu, idx); >>>> + >>> >>> The lock/unlock is not needed (vcpu_enter_guest -> vmx_handle_exit -> >>> handle_vmcall -> kvm_emulate_hypercall -> kvm_hv_hypercall -> >>> kvm_hvcall_signal_event). I'll drop it. >>> >>> Thanks, >>> >> >> Feel free to add my >> >> Reviewed-by: David Hildenbrand <david@xxxxxxxxxx> >> >> (although it would be good to have another look at the hyperv specific >> conn_id handling) > > Are you talking about this weird flag_no part of the hypercall parameter > which we add to the conn_id? > > Yes this is something I'm not quite comfortable with: we've never seen > it being anything but 0, and Linux guest drivers ignore its existence > altogether (and there seem to be no fields in the vmbus protocol > structures to let the guest know of the allowed numbers there). > > So I may be misinterpreting the spec; and it may be prudent just to > reject all flag_no != 0 hypercalls until we actually start seeing ones, > and then research how to handle them correctly. What do you think? Could be done, but if it isn't too much trouble, let's try to get it right from the beginning. Can you point me at the spec so I can verify? > > Thanks, > Roman. > -- Thanks, David / dhildenb
