On 04/11/19 19:54, Suthikulpanit, Suravee wrote: > I see you point. > >> We can work around it by adding a global mask of inhibit reasons that >> apply to the vendor, and initializing it as soon as possible in vmx.c/svm.c. >> >> Then kvm_request_apicv_update can ignore reasons that the vendor doesn't >> care about. > > What about we enhance the pre_update_apivc_exec_ctrl() to also return > success/fail. In here, the vendor specific code can decide to update > APICv state or not. That works for me, too. Something like return false for deactivate and true for activate. Paolo
