On Mon, Jan 10, 2022 at 3:07 PM Raghavendra Rao Ananta
[off-list ref] wrote:

On Fri, Jan 7, 2022 at 4:05 PM Jim Mattson [off-list ref] wrote:

quoted

On Fri, Jan 7, 2022 at 3:43 PM Raghavendra Rao Ananta
[off-list ref] wrote:

quoted

Hi Reiji,

On Thu, Jan 6, 2022 at 10:07 PM Reiji Watanabe [off-list ref] wrote:

quoted

Hi Raghu,

On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta
[off-list ref] wrote:

quoted

Capture the start of the KVM VM, which is basically the
start of any vCPU run. This state of the VM is helpful
in the upcoming patches to prevent user-space from
configuring certain VM features after the VM has started
running.

What about live migration, where the VM has already technically been
started before the first call to KVM_RUN?

My understanding is that a new 'struct kvm' is created on the target
machine and this flag should be reset, which would allow the VMM to
restore the firmware registers. However, we would be running KVM_RUN
for the first time on the target machine, thus setting the flag.
So, you are right; It's more of a resume operation from the guest's
point of view. I guess the name of the variable is what's confusing
here.

I was actually thinking that live migration gives userspace an easy
way to circumvent your restriction. You said, "This state of the VM is
helpful in the upcoming patches to prevent user-space from configuring
certain VM features after the VM has started running." However, if you
don't ensure that these VM features are configured the same way on the
target machine as they were on the source machine, you have not
actually accomplished your stated goal.

Thanks,
Raghavendra

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel