On Mon, May 10, 2021, Maxim Levitsky wrote:
On Tue, 2021-05-04 at 14:58 -0700, Jim Mattson wrote:
On Tue, May 4, 2021 at 2:57 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:I vote too for this.
On 04/05/21 23:53, Sean Christopherson wrote:
Does the right thing happen here if the vCPU is in guest mode whenI hate our terminology. By "guest mode", do you mean running the vCPU, or do
userspace decides to toggle the CPUID.80000001H:EDX.RDTSCP bit on or
you specifically mean running in L2?
Guest mode should mean L2.
(I wonder if we should have a capability that says "KVM_SET_CPUID2 can
only be called prior to KVM_RUN").
It would certainly make it easier to reason about potential security issues.
Alternatively, what about adding KVM_VCPU_RESET to let userspace explicitly
pull RESET#, and defining that ioctl() to freeze the vCPU model? I.e. after
userspace resets the vCPU, KVM_SET_CPUID (and any other relevant ioctls() is
Lack of proper RESET emulation is annoying, e.g. userspace has to manually stuff
EDX after vCPU creation to get the right value at RESET. A dedicated ioctl()
would kill two birds with one stone, without having to add yet another "2"