On 11/09/2010 03:29 PM, Jan Kiszka wrote:
Am 09.11.2010 13:35, Avi Kivity wrote: > On 11/08/2010 01:21 PM, Jan Kiszka wrote: >> The guest may change states that pci_reset_function does not touch. So >> we better save/restore the assigned device across guest usage. > > Why do we care? Shouldn't the next user reset the state to its taste? Maybe he should, but are we sure this actually happens? E.g. pci_reset_function preserves the config state, thus does not remove the traces of guest.
Oh yes, I read the code but it didn't register. Of course this change is quite necessary.
(I understood you to mean that the PCI 2.3 reset doesn't reset everything, but that isn't what you said).
> Or are you worried about information leakage? Anyone who's worried about security should not assign the same device to different users (host or guest) that should be isolated from each other. You never know in what state the firmware and/or internal memory of the device are. Probably, anyone concerned about security should not give a device in untrusted hands at all...
Agreed, it's much more suitable to the embedded/fixed function case.
> > This assumes no one else calls pci_save_state()/pci_restore_state() Correct.
Given the above, this is of secondary concern.
> while the guest is running. Is this true? What about suspend/resume? > (can this even work without guest assistance?) Well, so far suspend/resume does not work at all once assigned devices are in use. IIUC, the guest is not informed about the fact that power will be cut off, trashing the states of its assigned devices. We would have to signal this event to the guest and give it a chance to save the states. Maybe we could generate an ACPI event that corresponds to pressing a standby button. Or we would have to signal PCI unplug events for all assigned devices. In any case, suspend/resume of the host then becomes dependent on guest proper reaction.
Yeah. -- error compiling committee.c: too many arguments to function -- 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
