kvm-43 release

Only one fix, but an important one. It fixes booting of newer Linux versions, which experienced disk and keyboard problems without -no-kvm-irqchip.

As usual, if you have an issue please try with -no-kvm-irqchip and report.

Changes since kvm-42:
- fix ioapic edge-triggered interrupt handling

Notes:
If you use the modules bundled with kvm-43, you can use any version
of Linux from 2.6.9 upwards.
If you use the modules bundled with Linux 2.6.20, you need to use
kvm-12.
If you use the modules bundled with Linux 2.6.21, you need to use
kvm-17.
Modules from Linux 2.6.22 and up will work with any kvm version from
kvm-22. Some features may only be available in newer releases.
For best performance, use Linux 2.6.23-rc2 or later as the host.

http://kvm.qumranet.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Updated from -41. Now my libkvm-using-tool's kvm_callbacks->try_push_interrupts() callback isn't called any more. Hmm. Guess due to the lapic/irqchip changes. Are there any additional initializations I have to do now?

As there isn't any real pic-like hardware emulated maybe using try_to_push_interrupts is a bad idea anyway and I should better move the code (checks state and calls kvm_inject_irq() if needed) to the pre_kvm_run() callback?

hints anyone?

Gerd

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

You can call kvm_disable_irqchip_creation() to kill in-kernel pic and friends.

(the logic is inverted -- the function should be kvm_enable_irqchip_creation() so that this problem would not occur)

Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Ok, will try, next question first though as I'm running in trouble much earlier in -44: I get suspious page faults.

I *think* it happens because I'm changing guest page tables from outside (i.e. host application), and the new intel pgtable optimization bits don't expect that (yes, it is a vt box).

A quick scan of kvmctl.h doesn't show anything which looks like I could call to tell kvm the guest page tables have been modified. Hints how to handle this?

thanks,
Gerd

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Well, the older implementation doesn't expect that either. You can disable the optimization with bypass_guest_pf=0, though.

There's a kvm_mmu_zap_all() function, but it isn't exposed. It's very coarse grained, but can be used for experiments.

You could write a new ioctl that tells kvm that some pages were modified by the host; that's useful for guests which page out page tables (and so, during page in, disk dma could overwrite a page table).

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Thanks. Using bypass_guest_pf=0 and irqchip_disable() brings things back to -41 level of functionality.

kvm not expecting both guest and host app changing pagetables could explain other problems I'm seeing though, so maybe i better fix that. Long term it isn't planned to stay that way anyway, it's just handy for proof-of-concept because userspace is very easy to hack and debug ...

thanks,
Gerd

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/