Avi Kivity wrote: > Dong, Eddie wrote: >>> I think #2. Synchronization will be difficult; we'll need to send >>> signals to all other vcpus so that they drop the vcpu mutex. >>> >>> >> How about add a new ABI KVM_RESET_KERNDEVS ? >> We don't want to implement RESET ABIs for each kernel devices >> especially when we move PIT down and then RTC, pmtimer etc. >> > > I thought that was what Qing proposed :) > > I think we want at least a separate reset for LAPIC and IOAPICs, that > pushes the synchronization issues to userspace (though it may > introduce other issues like lapic issuing eois to ioapic after the > ioapic has been > reset). >
Mmm, if we implement 2, then we will have many. How about pv driver in future? They also need to be reseted. If implementing 1, then everything is left to kernel itself. BTW, for simplicity, this API may be per VCPU since reset a cross CPU LAPIC state is problemtic. BSP will issue platform wide device model reset. Eddie ------------------------------------------------------------------------- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
