Avi Kivity <avi@xxxxxxxxxx> writes: > So the jump-to-vector reset code cannot work on real hardware? It works in > qemu, but of course that's easy. In general yes. Nothing regularly uses that path so there is little point adding a new users if we can avoid it. Heck there are machines with unreliable cmos. >> You might be able to get a full cpu reset but not a reset of the I/O >> devices. >> >> The premise of kexec is that we are doing things on our own, and don't >> get a 3rd piece of software involved that has not been heavily tested >> on the path we want to use. Occassionally it is a pain to do everything >> ourselves but at least when we do and we test it we know it is going >> to work. >> >> Cpu designers lately seem fond of adding features that require all >> kind of coordination to turn on and off. We handle the hardware >> virtualization mode features now, and if x2apic has similar problems >> being turned on and off I am certain we can handle that case in a >> similar fashion. >> >> When we can my preference is to keep code like that out of the >> kexec on panic path if we can figure out how to write the software >> to do something reasonable. >> >> Once we figure out how to work without putting the interrupt controllers >> in legacy mode to handle the timer interrupts I expect all kinds of >> things will become simpler. >> > > I think it makes sense to add full reset support as a non-default option. > Leaving hardware running and dmaing left and right has its risks. It is easy enough to do that in user space in /sbin/kexec if that proves useful for some reason. As for the leaving hardware running and dmaing left and right. You are talking about the kexec on panic code path. On a normal reboot we do our darndest to cleanly shut everything down properly. We avoid the dmaing left and right problem by reserving a chunk of memory at boot time and we probably should be reserving a chunk of the iommus as well for that purpose. Hardware resets in general don't preserve the contents of memory. In general the kexec on panic path is about teaching drivers to initialize in the worst possible scenario and using those drivers that can to get information out of the system. At the same time 99% of the code that runs is in user space so it should be easy to jump through whatever hoops make sense in the user space component. While keeping the kexec on panic code path as slim as possible. Eric -- 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
