Hi Fabrice,

Fabrice Bellard wrote:
> Hi,
> 
> Regarding kqemu, I am still hesitating whether to commit it in the QEMU
> subversion repository. Moreover, I may change its license to another
> open source one so I would prefer that the patches are assigned to my
> copyright, especially if they are just small bugfixes.

Hmm, that leaves an uncomfortable feeling on my side. If the licenses
of the officially supported version did not include a GPL-compatible
one, we would have to stick with what we have at the moment for Linux.
Or will we see a dual licensed kqemu?

> 
> For your information, I will commit some incompatible API changes in
> kqemu in the next few days, so a new version will be needed anyway.

What is the roadmap of kqemu then? Are there functional enhancements
planned, or further performance tunings? What are those?


BTW, I think I understood my problem with kqemu in the meantime: lcall
from ring 0 => fails on lret as the real CS (with "wrong" RPL) is pushed
onto the guest stack. Am I right? How to fix this best, by emulating
lcall at kernel level?

Thanks,
Jan