Dong, Eddie wrote: > 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. >
We can have two APIs: reset vcpu (per-vcpu) and reset platform (everything else). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
