Zhao Forrest wrote: >> The incoming packet is processed by the host ethernet stack; it is >> forwarded to the bridge, which forwards it to the tap. When the tap >> queues the packet, it sends a signal to qemu (since the tap file >> descriptor has a signal associated). When the kernel delivers the >> signal, it notices the qemu thread is running on cpu 1, so it sends an >> inter-processor interrupt to cpu 1. The interrupt causes the processor >> > Is the behavior of "When the kernel delivers the signal, it notices the > qemu thread is running on cpu 1, so it sends an IPI to cpu 1" a generic > signal-delivery behavior in Linux kernel? Or KVM need to add some hook > to achieve this? > >
This is generic behavior. The same thing happens when running plain qemu, except that instead of breaking out from guest mode, the IPI causes the processor to break out from user mode and trap into the kernel. This is one of the most powerful characteristics of kvm: it works with ordinary kernel mechanisms, so that all the properties and features of the kernel apply to kvm automatically. In this particular case, it means that all the scheduler features, including real-time scheduling, apply to kvm guests. With mmu notifiers, the trend will grow even stronger. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
