>>>> >>>> This pushes towards in kernel apic too. Can't see how we avoid it. >>>> >>> >>> Does it really? IIUC, we would avoid TPR traps entirely and would >>> just need to synchronize the TPR whenever we go down to userspace. >>> >> >> It's a bit more complex than that, as userspace would need to tell the >> kernel the highest priority pending interrupt so that it can program >> the hardware to exit when an interrupt is ready. However I agree >> with you that in principle we could split the apic emulation between >> kvm and qemu, even with this featurette. > >Most of H/W-virtualization capable processors out there don't support >that feature today. I think the decision (kvm or qemu) should be done >based on performance data. I'm not worried about maintenance issues; the >APIC code is not expected to change frequently. I'm a bit worried about >extra complexity caused by such split, though. >
I had an in-kernel-apic implementation for KVM and the performance improvement was insignificant. It is mainly a software engineering thing. PV drivers can benefit from APIC in the kernel but again just a mere improvement. >BTW, I see CPU utilization of qemu is almost always 99% in the top >command when I run kernel build in an x86-64 Linux guest. What does qemu do? Idle guest hardly consume cpu, especially KVM powered. >Jun >--- >Intel Open Source Technology Center ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
