Re: [PATCH 0/3] Introduce new vcpu ioctls KVM_(GET|SET)_MANY_REGS

[Marc Zyngier <maz@kernel.org>]

On 2020-11-20 12:56, darkhan@amazon.com wrote:
> From: Darkhan Mukashov <darkhan@amazon.com>
> 
> The ultimate goal is to introduce new vcpu ioctls 
> KVM_(GET|SET)_MANY_REGS.
> To introduce these ioctls, implementations of KVM_(GET|SET)_ONE_REG 
> have
> to be refactored. Specifically, KVM_(GET|SET)_ONE_REG should be handled 
> in
> a generic kvm_vcpu_ioctl function.
> 
> New KVM APIs KVM_(GET|SET)_MANY_REGS make it possible to bulk 
> read/write
> vCPU registers at one ioctl call. These ioctls can be very useful when
> vCPU state serialization/deserialization is required (e.g. live update 
> of
> kvm, live migration of guests), hence all registers have to be
> saved/restored. KVM_(GET|SET)_MANY_REGS will help avoid performance
> overhead associated with syscall (ioctl in our case) handling. Tests
> conducted on AWS Graviton2 Processors (64-bit ARM Neoverse cores) show
> that average save/restore time of all vCPU registers can be optimized
> ~3.5 times per vCPU with new ioctls. Test results can be found in Table 
> 1.
> +---------+-------------+---------------+
> |         | kvm_one_reg | kvm_many_regs |
> +---------+-------------+---------------+
> | get all |   123 usec  |    33 usec    |
> +---------+-------------+---------------+
> | set all |   120 usec  |    36 usec    |
> +---------+-------------+---------------+
> 	Table 1. Test results

I have asked in private last week, and didn't get a satisfying answer:

We are talking about 90us over the time taken by enough state to be
transferred to the target so that it can be restarted. What proportion
does this represent? I'd expect userspace to do this from the vcpu
thread, and thus to be able to do everything in parallel, in which case
the gain doesn't scale with the number of vcpu.

One of the reasons for me being reluctant is that the userspace API
breaks extremely often, and that you are now adding yet another one
that can be used concurrently with the existing one.

So I would really like to see the whole picture, and not just this
very narrow "make it faster" approach. I also want to understand
why this is a "MANY" approach, and not "ALL".

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...