[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: KQEMU code organization

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: KQEMU code organization
Date: Thu, 29 May 2008 12:43:57 -0500
User-agent: Thunderbird (X11/20080501)

Jamie Lokier wrote:
Paul Brook wrote:
I.e. kvm has two sub-modules for Intel VT and AMD SVM extensions (I
think that's their names).  It would be great if it hard a third KQEMU
sub-module (which would of course be the most complicated ;-)
I believe this is also a prerequisite for getting kqemu merged into
maintream kernels, which IMHO is the only sane goal to have. Out of
tree kernel modules simply aren't worth the effort.

I think there's utility in crossover between both of them too.

There are some architectural incompatibilities. For instance, KVM support guest SMP but the code TCG generates does not ensure atomic operations are truly atomic. In general, it may not be possible to do this across architectures without employing the use of a big lock.

Also, when you mix dynamic translation in userspace with direct execution, it implies you have to completely flush the shadow page table cache. This is going to severely impact performance so I don't know that there are a lot of circumstances where using TCG would improve performance.

KVM already does some instruction patching FWIW. For instance, TPR accesses are modified in Windows guests to prevent a vmexit from occurring since Windows accesses the TPR so frequently.


Anthony Liguori

Sometimes it would be nice to have the speed and directness of kvm,
with the code scanning and replacement abilities of kqemu to block
particular instructions, pretend to be a specific CPU model, or
replace some hardware-accessing instruction sequences instead of
trapping and emulating them - without the guest seeing the replacement.

-- Jamie

reply via email to

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