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: Thu, 27 Nov 2014 16:31:29 +0100 Message-ID: <20141127153128.GD8120@potion.brq.redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Phil White Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbaK0Pbd (ORCPT ); Thu, 27 Nov 2014 10:31:33 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2014-11-27 05:30-0800, Phil White: > This introduces a list of entries which associate a function pointer of > kvm_hc_type to a hypercall number and allows the ability to register and > unregister entries. In addition, it also allows the ability to retrieve 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 they own > rather than requiring the addition of a stub of some sort. It will also > allow each arch to maintain separate lists of hypercalls rather than 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 it is static, someone could have registered it beforehand => this needs some kind of synchronization with host modules. A hardcoded reservation?)