On Sun, 2014-03-02 at 21:49 -0700, Alex Williamson wrote: > I understand from talking to Alexey that the BARs are reset by this > BIST, but what about the MSIX capability? If that gets reset to be > disabled, where does it get re-enabled? The guest will do pci_save/restore_state iirc which will attempt to save and restore everything, but qemu might get in the way here... I'm not sure whether the IPR BIST clears the config space but we probably should account for the general case of the driver in the guest doing some kind of reset (BIST or otherwise) and trying to save and restore state itself. > QEMU won't know about the BIST, > so probably assumes nothing changed when the guest writes the enable > bit. VFIO doesn't allow userspace writes to the MSIX capability. So it > seems like the above would restore the table entry, but not necessarily > whether MSIX is enabled on the device. Maybe qemu shouldn't trust its cache and upon guest writes, do a read first to check the HW state ? It's not like any of this is performance sensitive anyway... > When I talked with Alexey I noted that we already have a BAR restore > function, vfio_bar_restore(), that tries to do some fixup when backdoor > resets are noticed. If we were to trigger that upon noting the user > writing BAR values to what we think they're already set to, we could > extend it to trigger an interrupt restore that could fixup both the > capability and the table entries. Thanks, Cheers, Ben. -- 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
