qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]