On Tue, Nov 05, 2019 at 07:05:57AM +0000, Graf (AWS), Alexander wrote: > > > > Am 04.11.2019 um 22:50 schrieb Paolo Bonzini <pbonzini@xxxxxxxxxx>: > > > > 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. > > I'm trying to wrap my head around how that will work with live > migration. Do we also need to save/restore the deactivate reasons? Nope, this is all invisible to userland. The target will deduce the deactivation reasons on its own from the user-visible setup like PIT configuration, Hyper-V SynIC, etc. Roman.
