|
From: | R. Armiento |
Subject: | Re: [Qemu-devel] add 'monitor' and 'mwait' instruction (update) |
Date: | Sat, 08 Jul 2006 22:50:11 +0200 |
User-agent: | Thunderbird 1.5.0.4 (X11/20060615) |
Hi,Again, thank you for helping out with updated patches, it is much appreciated.
Joachim Henke wrote:
R. Armiento wrote:So even with your patch applied one should use the 'idle=halt' kernel parameter when booting Linux with -kernel-kqemu on newer processors. [...]To lower the cpu usage, you can additionally apply the attached patch, which makes 'mwait' similar to 'hlt'. This ugly hack seems to be sufficient at least for Linux.
Is this hack really 'safe'? I don't claim to know much about modern x86 instructions, but some googling tells me that mwait is supposed to wake on a monitored memory write (but is allowed to wake up earlier, hence it is acceptable but CPU consuming to emulate it with a nop). Couldn't there be situations where someone depends on mwait waking up without there being an event that wakes hlt? Or are we sure qemu's hlt will happen to wake up anyway?
Yes, the emulation should be done in a cleaner way. But to me it seems impossible to do real mwait emulation in user space.
Again, excuse my lack of knowledge of the internals of qemu and kqemu. If 'hlt' can be emulated to give CPU time back to the host OS until an interrupt occurs in the guest; then it is not obvious why mwait couldn't be simulated in a similar way, only with the addition that qemu also restarts guest CPU execution should there be writes in monitored memory. While I have no idea of how much work it would be, it would much surprise me if this is truly un-doable, at least for non-kqemu emulation.
Rickard
[Prev in Thread] | Current Thread | [Next in Thread] |