On 2011-05-05 14:23, Gleb Natapov wrote: > On Thu, May 05, 2011 at 02:58:27PM +0300, Avi Kivity wrote: >> On 05/05/2011 02:22 PM, Gleb Natapov wrote: >>>> >>>> We'll see, but I still do not share your concern regarding future >>>> regressions when removing the fragile reset code. >>>> >>> Why do we rely on userspace to properly reset kernel component anyway? >>> We should introduce cpu/lapic/ioapic/pit/pic resets ASAP. >> >> We should, but we'll always have to deal with kernels that don't >> have reset ioctls. >> > s/always/for quite a while/. Unfortunately yes. Unless we put qemu in the kernel > tree and will release them in lock steps of course :) Seriously, I do not see much added-value of a reset service. The pattern we will use for MSRs could just be applied to other in-kernel resources as well - unless they are already architecturally defined in a way that leaves no questions regarding the proper future reset state. Except for the CPU, all other in-kernel devices are not extensible in their current form. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
