On Thu, May 05, 2011 at 10:33:01AM -0300, Marcelo Tosatti wrote: > On Thu, May 05, 2011 at 02:22:57PM +0300, Gleb Natapov wrote: > > On Thu, May 05, 2011 at 11:32:26AM +0200, Jan Kiszka wrote: > > > >> > > > > >> > Of course, if we get a patch soon no one will ever see the > > > >> regression so > > > >> > we can apply the series. > > > >> > > > >> I will still require the usual testing and merging round via upstream > > > >> and back. Not sure when I'll be able to work on it, probably not the > > > >> next days. > > > > > > > > If you can do it within a couple of weeks or so that should be fine. > > > > > > > > > > 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? > > In general its required that userspace properly sets (some of) the > parameters of emulated hardware, including on reset. That's just how things work now. It doesn't have to be this way. > > > We should introduce cpu/lapic/ioapic/pit/pic resets ASAP. > > Thats done through userspace via ioctls, don't get your point? Why userspace shouldn't know such low level details about in kernel device? We had same devices emulated in qemu so it was easy to reuse that for reset, but think about writing device model from the start. With current interfaces you either need to have very low level knowledge about in kernel device in userspace just to reset it properly, or you need to save device state just after creation and reload the saved state on reset (kind of what Avi proposed for MSR). Both solutions are not optional IMO. -- Gleb. -- 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
