[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <89fa5648-e034-6435-9b21-a6ca0cb22a46@redhat.com>
Date: Wed, 18 Aug 2021 22:49:05 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: suleiman@...gle.com, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
John Stultz <john.stultz@...aro.org>,
Sean Christopherson <seanjc@...gle.com>,
Stephen Boyd <sboyd@...nel.org>,
Wanpeng Li <wanpengli@...cent.com>, kvm@...r.kernel.org,
x86@...nel.org, Hikaru Nishida <hikalium@...omium.org>,
linux-kernel@...r.kernel.org, dme@....org, tglx@...utronix.de,
mlevitsk@...hat.com
Subject: Re: [v2 PATCH 3/4] x86/kvm: Add host side support for virtual suspend
time injection
On 18/08/21 11:32, Vitaly Kuznetsov wrote:
> On the host side, I'd vote for keeping MSR_KVM_ASYNC_PF_INT for async PF
> mechanism only for two reasons:
> - We may want to use (currently reserved) upper 56 bits of it for new
> asyncPF related features (e.g. flags) and it would be unnatural to add
> them to 'MSR_KVM_HYPERVISOR_CALLBACK_INT'
> - We should probably leave it to the guest if it wants to share 'suspend
> time' notification interrupt with async PF (and if it actually wants to
> get one/another).
I agree that it's fine either way. That said, more MSRs are more
complexity and more opportunity for getting things wrong (in either KVM
or userspace---for example, migration). There are still 14 free bits in
MSR_ASYNC_PF_EN (bits 63-52 and 5-4, so it should not be a problem to
repurpose MSR_ASYNC_PF_INT.
Paolo
> On the guest side, it is perfectly fine to reuse
> HYPERVISOR_CALLBACK_VECTOR for everything.
Powered by blists - more mailing lists