Am 17.09.2010 18:16, schrieb ext Alex Williamson:
On Fri, 2010-09-17 at 17:27 +0200, Bernhard Kohl wrote:This is necessary because during reboot of a VM the assigned devices continue DMA transfers which causes memory corruption. Signed-off-by: Thomas Ostler<thomas.ostler@xxxxxxx> Signed-off-by: Bernhard Kohl<bernhard.kohl@xxxxxxx> --- hw/device-assignment.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 87f7418..fb47813 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -1450,6 +1450,17 @@ static void assigned_dev_unregister_msix_mmio(AssignedDevice *dev) dev->msix_table_page = NULL; } +static void reset_assigned_device(void *opaque) +{ + PCIDevice *d = (PCIDevice *)opaque; + uint32_t conf; + + /* reset the bus master bit to avoid further DMA transfers */ + conf = assigned_dev_pci_read_config(d, PCI_COMMAND, 2); + conf&= ~PCI_COMMAND_MASTER; + assigned_dev_pci_write_config(d, PCI_COMMAND, conf, 2); +} + static int assigned_initfn(struct PCIDevice *pci_dev) { AssignedDevice *dev = DO_UPCAST(AssignedDevice, dev, pci_dev); @@ -1499,6 +1510,9 @@ static int assigned_initfn(struct PCIDevice *pci_dev) if (r< 0) goto assigned_out; + /* register reset function for the device */ + qemu_register_reset(reset_assigned_device, pci_dev); + /* intercept MSI-X entry page in the MMIO */ if (dev->cap.available& ASSIGNED_DEVICE_CAP_MSIX) if (assigned_dev_register_msix_mmio(dev))Hmm, at a minimum, we need a qemu_unregister_reset() in the exitfn, but upon further inspection, we should probably just do it the qdev way. That would mean simply setting qdev.reset to reset_assigned_device() in assign_info, then we can leave the registration/de-registration to qdev. Does that work? Sorry I missed that the first time. Thanks, Alex
OK, we will rework the patch for qdev. This might take 2 weeks because of vacation. Thanks Bernhard -- 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
