From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHH2d-0006z5-Sq for qemu-devel@nongnu.org; Tue, 03 May 2011 10:57:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QHH2c-0002ef-Na for qemu-devel@nongnu.org; Tue, 03 May 2011 10:57:35 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:54647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHH2c-0002ea-AM for qemu-devel@nongnu.org; Tue, 03 May 2011 10:57:34 -0400 Message-ID: <4DC017D8.7000408@siemens.com> Date: Tue, 03 May 2011 16:57:28 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1302881578-5357-1-git-send-email-agraf@suse.de> <1302881578-5357-6-git-send-email-agraf@suse.de> <20110418183404.GE16178@volta.aurel32.net> <2CD6A68E-9F9D-46A9-8488-D5FE4C2268E8@suse.de> In-Reply-To: <2CD6A68E-9F9D-46A9-8488-D5FE4C2268E8@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: jan.kiszka@siemens.com Subject: Re: [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Richard Henderson , Avi Kivity , Aurelien Jarno , QEMU-devel Developers On 2011-05-03 16:17, Alexander Graf wrote: > > On 18.04.2011, at 20:34, Aurelien Jarno wrote: > >> On Fri, Apr 15, 2011 at 05:32:46PM +0200, Alexander Graf wrote: >>> We have a generic stub architecture for kvm calls, but some architectures >>> are different from others. So we do want to be able to have stubs for >>> architecture specific functionality as well. >>> >>> This patch adds kvm stubs for all architectures. >>> >>> Signed-off-by: Alexander Graf >>> --- >>> Makefile.target | 2 +- >>> target-alpha/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-arm/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-cris/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-i386/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-lm32/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-m68k/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-microblaze/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-mips/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-ppc/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-s390x/kvm-arch-stub.c | 38 +++++++++++++++++++++++++++++++++++++ >>> target-sh4/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-sparc/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> target-unicore32/kvm-arch-stub.c | 26 +++++++++++++++++++++++++ >>> 14 files changed, 351 insertions(+), 1 deletions(-) >>> create mode 100644 target-alpha/kvm-arch-stub.c >>> create mode 100644 target-arm/kvm-arch-stub.c >>> create mode 100644 target-cris/kvm-arch-stub.c >>> create mode 100644 target-i386/kvm-arch-stub.c >>> create mode 100644 target-lm32/kvm-arch-stub.c >>> create mode 100644 target-m68k/kvm-arch-stub.c >>> create mode 100644 target-microblaze/kvm-arch-stub.c >>> create mode 100644 target-mips/kvm-arch-stub.c >>> create mode 100644 target-ppc/kvm-arch-stub.c >>> create mode 100644 target-s390x/kvm-arch-stub.c >>> create mode 100644 target-sh4/kvm-arch-stub.c >>> create mode 100644 target-sparc/kvm-arch-stub.c >>> create mode 100644 target-unicore32/kvm-arch-stub.c >> >> Do we really want to create so much files on architectures we will never >> see KVM support? Actually I know very few things about KVM, so it would >> be better to have this patch reviewed by someone else. Avi or Anthony >> maybe? > > Well, the main idea is to be able to have a unified place to put stub functions into. And as it stands with most generalizations, we either make it generic or not :). > Maybe there's some Makefile magic to only compile the stub if the file exists? I certainly don't know of any. This approach looks wrong. The point of kvm stubs is to allow generic components to be built independently of kvm enabled/disabled. But target-specific callbacks can't be part of generic components anyway. So there is no need for a stub, those bits will be built per-target anyway. The examples you provided with this patch underline it: s390-virtio-bus.c should be built for s390 but nothing else. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux