From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alexander Graf <agraf@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Richard Henderson <rth@twiddle.net>, Avi Kivity <avi@redhat.com>,
Aurelien Jarno <aurelien@aurel32.net>,
QEMU-devel Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff
Date: Wed, 04 May 2011 10:31:16 +0200 [thread overview]
Message-ID: <4DC10ED4.7080609@siemens.com> (raw)
In-Reply-To: <84F85E83-8C55-4438-806A-0B08A073920D@suse.de>
On 2011-05-04 07:19, Alexander Graf wrote:
>
> On 03.05.2011, at 16:57, Jan Kiszka wrote:
>
>> 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 <agraf@suse.de>
>>>>> ---
>>>>> 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.
>
> And it is, yes. The point is to not require #ifdefs in device emulation code :).
But that's not the purpose of the stubs. They shall avoid building
components target specific when just the kvm on/off dependency would
force them to. Moreover, I do not see any need for such in
infrastructure beyond s390 when considering that case valid.
Why not simply define those few functions as static inline in the
already s390-specific header depending on #ifdef CONFIG_KVM?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2011-05-04 8:31 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 15:32 [Qemu-devel] [PATCH 00/17] s390x emulation support v4 Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 01/17] tcg: extend max tcg opcodes on 32bit Alexander Graf
2011-04-18 18:42 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 02/17] s390x: s390x-linux-user support Alexander Graf
2011-04-18 11:38 ` Riku Voipio
2011-04-18 12:06 ` Alexander Graf
2011-04-18 12:19 ` Riku Voipio
2011-04-18 13:21 ` Jan-Simon Möller
2011-04-18 13:31 ` Alexander Graf
2011-04-18 13:36 ` Aurelien Jarno
2011-04-18 13:42 ` Alexander Graf
2011-04-18 13:54 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 03/17] linux-user: define a couple of syscalls for non-uid16 targets Alexander Graf
2011-04-18 16:32 ` Riku Voipio
2011-04-18 21:11 ` Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 04/17] linux-user: add s390x to llseek list Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff Alexander Graf
2011-04-18 18:34 ` Aurelien Jarno
2011-05-03 14:17 ` Alexander Graf
2011-05-03 14:57 ` Jan Kiszka
2011-05-04 5:19 ` Alexander Graf
2011-05-04 8:31 ` Jan Kiszka [this message]
2011-05-04 8:40 ` Alexander Graf
2011-05-04 8:43 ` Jan Kiszka
2011-05-04 8:53 ` Alexander Graf
2011-05-03 15:05 ` Peter Maydell
2011-04-15 15:32 ` [Qemu-devel] [PATCH 06/17] s390x: Prepare cpu.h for emulation Alexander Graf
2011-04-18 18:55 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 07/17] s390x: Enable s390x-softmmu target Alexander Graf
2011-04-18 18:56 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 08/17] s390x: Dispatch interrupts to KVM or the real CPU Alexander Graf
2011-04-18 19:01 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 09/17] s390x: virtio machine storage keys Alexander Graf
2011-04-18 19:02 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 10/17] s390x: keep hint on virtio managing size Alexander Graf
2011-04-18 19:06 ` Aurelien Jarno
2011-04-18 21:03 ` Alexander Graf
2011-04-20 10:21 ` Aurelien Jarno
2011-04-15 15:32 ` [Qemu-devel] [PATCH 11/17] s390x: helper functions for system emulation Alexander Graf
2011-04-20 10:38 ` Aurelien Jarno
2011-05-04 4:57 ` Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 12/17] s390x: Implement opcode helpers Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 13/17] s390x: Adjust internal kvm code Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 14/17] s390x: translate engine for s390x CPU Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 15/17] s390x: Adjust GDB stub Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 16/17] s390x: remove compatibility cc field Alexander Graf
2011-04-15 15:32 ` [Qemu-devel] [PATCH 17/17] s390x: build s390x by default Alexander Graf
2011-04-27 14:35 ` [Qemu-devel] [PATCH 00/17] s390x emulation support v4 Aurelien Jarno
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=4DC10ED4.7080609@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=agraf@suse.de \
--cc=aurelien@aurel32.net \
--cc=avi@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).