Messages in this thread | | | Subject | Re: [PATCH v3 2/2] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall | From | Paolo Bonzini <> | Date | Tue, 4 May 2021 22:56:28 +0200 |
| |
On 04/05/21 22:33, Sean Christopherson wrote: > On Tue, May 04, 2021, Paolo Bonzini wrote: >> On 04/05/21 19:09, Sean Christopherson wrote: >>> On Sat, May 01, 2021, Paolo Bonzini wrote: >>>> - make it completely independent from migration, i.e. it's just a facet of >>>> MSR_KVM_PAGE_ENC_STATUS saying whether the bitmap is up-to-date. It would >>>> use CPUID bit as the encryption status bitmap and have no code at all in KVM >>>> (userspace needs to set up the filter and implement everything). >>> >>> If the bit is purely a "page encryption status is up-to-date", what about >>> overloading KVM_HC_PAGE_ENC_STATUS to handle that status update as well? That >>> would eliminate my biggest complaint about having what is effectively a single >>> paravirt feature split into two separate, but intertwined chunks of ABI. >> >> It's true that they are intertwined, but I dislike not having a way to read >> the current state. > > From the guest?
Yes, host userspace obviously doesn't need one since it's implemented through an MSR filter. It may not be really necessary to read it, but it's a bit jarring compared to how the rest of the PV APIs uses MSRs.
Also from a debugging/crashdump point of view the VMM may have an established way to read an MSR from a vCPU, but it won't work if you come up with a new way to set the state.
Paolo
| |