Rusty Russell <ru...@rustcorp.com.au> writes: > Jamie Lokier <ja...@shareable.org> writes: > >> Rusty Russell wrote: >>> I don't think it'll be that bad; reset clears the device to unknown, >>> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from >>> unknown->modern mode, and anything else is bad (I prefer being strict so >>> we catch bad implementations from the beginning). >> >> Will that work, if the guest with kernel that uses modern mode, kexecs >> to an older (but presumed reliable) kernel that only knows about legacy mode? >> >> I.e. will the replacement kernel, or (ideally) replacement driver on >> the rare occasion that is needed on a running kernel, be able to reset >> the device hard enough? > > Well, you need to reset the device, so yes.
MST said something which made me think harder about this case. Either there needs to be a way to tell what mode the device is in, or legacy reset has to work, even in modern mode. The latter is preferable, since it allows an older kernel to do the reset. Now, since qemu would almost certainly have to add code to stop that working, it'll probably be fine. But I'd really like to add a "strict mode" to qemu virtio which does extra sanity checking for driver authors, and that might break this. That's OK. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
