From: Roman Kagan <rkagan@virtuozzo.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, x86@kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"Stephen Hemminger" <sthemmin@microsoft.com>,
"Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>,
"Mohammed Gamal" <mmorsy@redhat.com>,
"Cathy Avery" <cavery@redhat.com>,
"Wanpeng Li" <wanpeng.li@hotmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/5] KVM: x86: hyperv: introduce vp_index_to_vcpu_idx mapping
Date: Fri, 29 Jun 2018 13:11:36 +0300 [thread overview]
Message-ID: <20180629101134.GA15656@rkaganb.sw.ru> (raw)
In-Reply-To: <20180628135313.17468-3-vkuznets@redhat.com>
On Thu, Jun 28, 2018 at 03:53:10PM +0200, Vitaly Kuznetsov wrote:
> While it is easy to get VP index from vCPU index the reverse task is hard.
> Basically, to solve it we have to walk all vCPUs checking if their VP index
> matches. For hypercalls like HvFlushVirtualAddress{List,Space}* and the
> upcoming HvSendSyntheticClusterIpi* where a single CPU may be specified in
> the whole set this is obviously sub-optimal.
>
> As VP index can be set to anything <= U32_MAX by userspace using plain
> [0..MAX_VP_INDEX] array is not a viable option. Use condensed sorted
> array with logarithmic search complexity instead. Use RCU to make read
> access as fast as possible and maintain atomicity of updates.
Quoting TLFS 5.0C section 7.8.1:
> Virtual processors are identified by using an index (VP index). The
> maximum number of virtual processors per partition supported by the
> current implementation of the hypervisor can be obtained through CPUID
> leaf 0x40000005. A virtual processor index must be less than the
> maximum number of virtual processors per partition.
so this is a dense index, and VP_INDEX >= KVM_MAX_VCPUS is invalid. I
think we're better off enforcing this in kvm_hv_set_msr and keep the
translation simple. If the algorithm in get_vcpu_by_vpidx is not good
enough (and yes it can be made to return NULL early on vpidx >=
KVM_MAX_VCPUS instead of taking the slow path) then a simple index array
of KVM_MAX_VCPUS entries should certainly do.
Roman.
next prev parent reply other threads:[~2018-06-29 10:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 13:53 [PATCH v2 0/5] KVM: x86: hyperv: PV IPI support for Windows guests Vitaly Kuznetsov
2018-06-28 13:53 ` [PATCH v2 1/5] KVM: x86: hyperv: optimize 'all cpus' case in kvm_hv_flush_tlb() Vitaly Kuznetsov
2018-06-28 13:53 ` [PATCH v2 2/5] KVM: x86: hyperv: introduce vp_index_to_vcpu_idx mapping Vitaly Kuznetsov
2018-06-28 18:49 ` kbuild test robot
2018-06-28 19:09 ` [PATCH] KVM: x86: hyperv: fix semicolon.cocci warnings kbuild test robot
2018-06-28 19:09 ` [PATCH v2 2/5] KVM: x86: hyperv: introduce vp_index_to_vcpu_idx mapping kbuild test robot
2018-06-29 10:11 ` Roman Kagan [this message]
2018-06-29 10:26 ` Vitaly Kuznetsov
2018-06-29 11:12 ` Roman Kagan
2018-06-29 11:37 ` Vitaly Kuznetsov
2018-06-29 12:52 ` Roman Kagan
2018-06-29 13:10 ` Vitaly Kuznetsov
2018-06-29 14:32 ` Roman Kagan
2018-06-29 15:25 ` Vitaly Kuznetsov
2018-06-29 15:55 ` Roman Kagan
2018-06-28 13:53 ` [PATCH v2 3/5] KVM: x86: hyperv: use vp_idx_to_vcpu_idx() in kvm_hv_flush_tlb() Vitaly Kuznetsov
2018-06-28 13:53 ` [PATCH v2 4/5] x86/hyper-v: rename ipi_arg_{ex,non_ex} structures Vitaly Kuznetsov
2018-06-28 13:53 ` [PATCH v2 5/5] KVM: x86: hyperv: implement PV IPI send hypercalls Vitaly Kuznetsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180629101134.GA15656@rkaganb.sw.ru \
--to=rkagan@virtuozzo.com \
--cc=Michael.H.Kelley@microsoft.com \
--cc=cavery@redhat.com \
--cc=haiyangz@microsoft.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mmorsy@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sthemmin@microsoft.com \
--cc=vkuznets@redhat.com \
--cc=wanpeng.li@hotmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).