Dong, Eddie wrote: > Avi Kivity wrote: > >> Dong, Eddie wrote: >> >>>> N+1, for me is that synchronous device emulation (like pio and mmio) >>>> happens in in the vcpu thread and asynchronous device emulation >>>> (handling signals in qemu, performing dma, and injecting interrupts) >>>> happens in the device thread. This minimizes context switching and >>>> heavyweight exits. >>>> >>>> >>>> >>> If this is true, then the N+1 thread won't be able to execute >>> qemu_system_reset which is in VCPU contents, >>> >> I don't understand. It can certainly access any qemu object (after >> taking qemu_mutex), and it can call any kvm vm ioctl. >> > > It can in theory, but do we have the real usage for > qemu_system_reset which is the only caller of > KERNEL RESET. > >
Well, if the guest resets itself, then reset is called from the vcpu thread. If we reset from the qemu monitor, it can be called from a non-vcpu thread. >>> >> Do you mean signal handlers? Sure, but we wait for socket I/O in >> select() and even dequeue signals synchronously. >> >> >> > Qemu_system_reset is called only when a VCPU thread is doing. > > Anyway, wanna to see your whole proposal. > Yes, I'll prepare and post patched for review. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
