[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: KQEMU code organization
From: |
Jan Kiszka |
Subject: |
[Qemu-devel] Re: KQEMU code organization |
Date: |
Wed, 28 May 2008 20:34:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Jan Kiszka wrote:
> Fabrice Bellard wrote:
>> Jan Kiszka wrote:
>>> Fabrice Bellard wrote:
>>>> Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> is there a technical reason why the kqemu kernel module is built out of
>>>>> a binary blob (monitor-image.bin->monitor-image.h)? Does this simply
>>>>> date back to the time when wrapper and core were distributed under
>>>>> different licenses?
>>>> This is a technical reason: the "blob" is run in an address space
>>>> different from the host kernel.
>>> Well, easy to claim, I know, but I don't think this is a hard reason.
>>> However, as overcoming genmon and genoffset may require quite some
>>> refactoring, I'm not sure if it's worth it.
>> I may change the monitor blob format to ELF to allow relocation, but the
>> idea stays the same, and I don't think you can do it another way...
>
> I agree (from my current knowledge of the problem) that the monitor
> remains "foreign" code to the kernel module. But at least the
> repackaging into a c-structure should be unnecessary.
>
> The offset generation can be skipped if the assembly files are converted
> into inline assembly. Might be tricky in some cases, but I see no
> show-stopper yet.
>
> The give it a tiny start, I will look if I can unify the build process
> for all "true" kernel components. That is what currently breaks the
> debugability of the driver frame (up to kernel2monitor), and which also
> causes a kbuild warning. Likely harmless ATM, but it is fragile on
> long-term.
Here we go. Still not nice (I would put all monitor code in its own
directory, moving those few host kernel bits into the top-level dir),
but at least much cleaner from kbuild's POV.
Signed-off-by: Jan Kiszka <address@hidden>
---
Makefile | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Index: b/Makefile
===================================================================
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ ifdef CONFIG_KBUILD26
all: kqemu.ko
kqemu.ko:
- make -C common all
+ make -C common monitor-image.h
make -C $(KERNEL_PATH) M=`pwd` modules
else
@@ -38,7 +38,8 @@ endif # !CONFIG_WIN32
clean:
$(MAKE) -C common clean
- rm -f kqemu.ko *.o *~
+ rm -rf kqemu.ko *.o *~ .kqemu* Module.* modules.order kqemu.mod.c
.tmp_versions \
+ common/.kernel* common/*/.kernel*
FILES=configure Makefile README Changelog LICENSE COPYING \
install.sh kqemu-linux.c kqemu.h \
@@ -89,10 +90,10 @@ kqemu.o: $(kqemu-objs)
else
# called from 2.6 kernel kbuild
-obj-m:= kqemu.o
-kqemu-objs:= kqemu-linux.o kqemu-mod.o
+EXTRA_AFLAGS=-I $(PWD)/common
+EXTRA_CFLAGS=-I $(PWD)
-$(obj)/kqemu-mod.o: $(src)/kqemu-mod-$(ARCH).o
- cp $< $@
+obj-m:= kqemu.o
+kqemu-objs:= kqemu-linux.o common/kernel.o common/$(ARCH)/kernel_asm.o
endif
endif # PATCHLEVEL
BTW, there is more trouble ahead for kqemu. This is what I get booting a
x86-64 OpenSuse 10.3 image on a 64-bit platform:
RAX=ffff810001008220 RBX=ffff81002f88a160 RCX=0000000000000036
RDX=0000000000000000
RSI=ffffe20000065aa0 RDI=ffff81002f88a164 RBP=ffff81002df99e68
RSP=ffff81002df99e68
R8 =0000000000000000 R9 =0000000000000000 R10=ffff81002df99db8
R11=0000000000010246
R12=ffff81002f88a164 R13=0000000000000004 R14=ffff81002f4a6b10
R15=ffff81002df99f58
RIP=ffffffff80447515 RFL=00010246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 00000000 00000000
CS =0010 0000000000000000 ffffffff 00a09b00
SS =0000 0000000000000000 ffffffff 00c09300
DS =0000 0000000000000000 00000000 00000000
FS =0000 0000000000000000 00000000 00000000
GS =0000 ffffffff8059b000 00000000 00000000
LDT=0000 0000000000000000 00000000 00008000
TR =0040 ffff81000101c280 00002087 00008900
GDT= ffffffff8061e000 00000080
IDT= ffffffff8067f000 00000fff
CR0=8005003b CR2=00007fff4183bf70 CR3=000000002e8a7000 CR4=000006a0
Unsupported return value: 0xffffffff
Kernel log says
kqemu: aborting: Unexpected exception 0x0d in monitor space
err=0000 CS:EIP=f180:00000000f0001f6f SS:SP=0000:00000000f00c6e20
with the official kqemu and, interestingly,
kqemu: aborting: mon_get_ptel_l3() failed
with Ben's repos.
Jan
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] KQEMU code organization, Jan Kiszka, 2008/05/27
- Re: [Qemu-devel] KQEMU code organization, Ben Taylor, 2008/05/27
- Re: [Qemu-devel] KQEMU code organization, Fabrice Bellard, 2008/05/27
- Re: [Qemu-devel] KQEMU code organization, Fabrice Bellard, 2008/05/27
- [Qemu-devel] Re: KQEMU code organization, Jan Kiszka, 2008/05/28
- Re: [Qemu-devel] Re: KQEMU code organization, Fabrice Bellard, 2008/05/28
- [Qemu-devel] Re: KQEMU code organization, Jan Kiszka, 2008/05/28
- [Qemu-devel] Re: KQEMU code organization,
Jan Kiszka <=
- Re: [Qemu-devel] Re: KQEMU code organization, Fabrice Bellard, 2008/05/29
- [Qemu-devel] Re: KQEMU code organization, Jan Kiszka, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Jamie Lokier, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Paul Brook, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Jamie Lokier, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Anthony Liguori, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Fabrice Bellard, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Mulyadi Santosa, 2008/05/29
- Re: [Qemu-devel] Re: KQEMU code organization, Andreas Färber, 2008/05/30
- Re: [Qemu-devel] Re: KQEMU code organization, Anthony Liguori, 2008/05/29