[Qemu-devel] Re: KQEMU code organization

[Jan Kiszka]

Fabrice Bellard wrote:
> 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.
> 
> This is purely cosmetic and I am generally against such changes.

See, the current code structure is not optimal /wrt understandability.
KQEMU is a complex topic, no question. But this doesn't mean the
structuring need to be that complex as well. Everything that helps to
make things straighter, quicker to overview, can also help third parties
to analyze KQEMU, debug potential issues, or even enhance its feature set.

>> 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.
> 
> For true kernel components I agree it is useful.
> 
> Regarding the kqemu evolution, I am doing small API changes to make it
> more independent from the QEMU internal data structures and to allow
> usage from a 32 bit user QEMU application with a 64 bit host. There is
> also another small change I did some time ago but never published to
> allow paravirtualization of the Linux kernel.

OK, thanks for the info. Just leaves me with the open questions about
the planned license(s) and how/where KQEMU is going to be maintained in
the future. I would really like to see it being driven as actively (and
broadly) as the QEMU core - specifically as long as HW-virtualization is
still not the rule on existing platforms :-/.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux