From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH] KVM: Introduce dynamically registered hypercall capability Date: Mon, 1 Dec 2014 14:47:40 +0100 Message-ID: <20141201134736.GA8553@potion.redhat.com> References: <20141127153128.GD8120@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Phil White Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753412AbaLANrp (ORCPT ); Mon, 1 Dec 2014 08:47:45 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2014-11-28 17:29-0800, Phil White: > Good questions. >=20 > One thing that prompted this code is the presence and proliferation o= f > architecture specific hypercalls in include/uapi/linux/kvm_para.h. > I'm not sure why the tree has continued on for as long as it has with > a list of reserved hypercall indices -- most of which are unused on > any given architecture. Is there a reason that I'm unaware of? Name-space won't be exhausted, so nothing forced them to separate and centralization easily avoids conflicts with generic hypercalls. > This was written because I had a module which was meant to be loaded > for paravirtualized VMs and it needed a hook to receive a hypercall. > We originally reserved an index, but that struck me as sloppy for the > same reason I mentioned before -- not every system is going to need > that hypercall number reserved. Makes sense; out-of-tree modules are in an especially bad position to get their hypercalls into the kernel. (Is a hypercall necessary?) > I didn't have a problem communicating the hypercall number to the > guest incidentally -- it had a bit of shared memory where the request > structure was placed. That said, it could just as easily be used in = a > static arrangement where each request is made to claim a particular > ID. My main trouble is that we would export a very specific/limited feature for an unknown problem -- we can't even tell if it is appropriate, whic= h strongly favors rejecting it. I'd say that a virtio device is the way to go if you want to stay in th= e kernel, but outside of kvm modules. In which ways is virtio lacking? > It does occur to me that in the absence of the setup which I had > available, one could simply treat hc_nr as a 4 character ID rather > than a particular digit. (This would probably solve the situation in practice, but the conflict is still there, so design hasn't improved.) > "The generation of random numbers is too important to be left to > chance." -Robert R. Coveyou, Oak Ridge National Laboratory, 1969 :) (Exactly.) > On Thu, Nov 27, 2014 at 7:31 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > 2014-11-27 05:30-0800, Phil White: > >> This introduces a list of entries which associate a function point= er of > >> kvm_hc_type to a hypercall number and allows the ability to regist= er and > >> unregister entries. In addition, it also allows the ability to re= trieve a > >> function pointer of kvm_hc_type for a given hypercall number which= is meant > >> to be called from the arch-specific section. > >> > >> The main intent is to allow modules to register hypercalls which t= hey own > >> rather than requiring the addition of a stub of some sort. It wil= l also > >> allow each arch to maintain separate lists of hypercalls rather th= an having > >> to respect changes in include/uapi/linux/kvm_para.h > >> > >> Signed-off-by: Phil White > >> --- > > > > Apart from other problems, > > how are guests going to use these hypercalls? > > > > (If hc_nr is dynamic, a guest doesn't know its number and even if i= t is > > static, someone could have registered it beforehand =3D> this need= s some > > kind of synchronization with host modules. A hardcoded reservatio= n?)