Dor Laor wrote: >>>>> 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. >
qemu would be 99% even if all the time is being spent in the guest context. If the user time is high, an oprofile run would be pretty useful. I've found that the VGA drawing routines can be pretty expensive. Regards, Anthony Liguori >> 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
