On 21 April 2016 at 19:30, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > So I agree about the latch state, that should be exported, if nothing > else so that a VM can't use this particular change to detect a > migration, for example. > > However, for the input level, I really do see this as a wire state > between userspace and the kernel, and as something that userspace should > re-establish after migration, since userspace already knows what the > line level is, why does it need to pull it out of the kernel again? I guess userspace could track the line level as well as telling the kernel about it, but we would still need an API for telling the kernel "here is your line level state after a migration", because that's not the same as "the line level just changed because the device signaled an interrupt". (For the former, we just want to set your 'level' struct field value. For the latter, a 0->1 level change may mean "set pending"; but for migration we're already telling you the current pending state via a different ioctl and don't want to mess that up when we're telling you about the 'level' info.) And if we have to have migration API for directly writing level bits we might as well have the corresponding directly-read-level-bits one... thanks -- PMM -- 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
