On Fri, Jun 29, 2018 at 05:25:56PM +0200, Vitaly Kuznetsov wrote: > Roman Kagan <rkagan@xxxxxxxxxxxxx> writes: > > > On Fri, Jun 29, 2018 at 03:10:14PM +0200, Vitaly Kuznetsov wrote: > >> Roman Kagan <rkagan@xxxxxxxxxxxxx> writes: > >> > >> > On Fri, Jun 29, 2018 at 01:37:44PM +0200, Vitaly Kuznetsov wrote: > >> >> The problem we're trying to solve here is: with PV TLB flush and IPI we > >> >> need to walk through the supplied list of VP_INDEXes and get VCPU > >> >> ids. Usually they match. But in case they don't [...] > >> > > >> > Why wouldn't they *in practice*? Only if the userspace wanted to be > >> > funny and assigned VP_INDEXes randomly? I'm not sure we need to > >> > optimize for this case. > >> > >> Can someone please remind me why we allow userspace to change it in the > >> first place? > > > > I can ;) > > > > We used not to, and reported KVM's vcpu index as the VP_INDEX. However, > > later we realized that VP_INDEX needed to be persistent across > > migrations and otherwise also known to userspace. Relying on the kernel > > to always initialize its indices in the same order was unacceptable, and > > we came up with no better way of synchronizing VP_INDEX between the > > userspace and the kernel than to let the former to set it explicitly. > > > > However, this is basically a future-proofing feature; in practice, both > > QEMU and KVM initialize their indices in the same order. > > > Thanks! > > But in the theoretical case when these indices start to differ after > migration, users will notice a slowdown which will be hard to explain, > right? That's exactly why I suggested a warning on VP_INDEX != vcpu index in kvm_hv_set_msr. > Does it justify the need for vp_idx_to_vcpu_idx? I'd personally prefer being pointed at a scenario where this becomes relevant first. Roman.
