# HG changeset patch # User Konrad Rzeszutek Wilk # Date 1427814949 14400 # Tue Mar 31 11:15:49 2015 -0400 # Node ID 2d24c59f9a4a079d127339d0c025d3e5b9914c0e # Parent afe2ac5137b8c247dea886c732d09791fe44ac91 xen/pciback: Don't disable PCI_COMMAND on PCI device reset. There is no need for this at all. Worst it means that if the guest tries to write to BARs it could lead (on certain platforms) to PCI SERR errors. Please note that with af6fc858a35b90e89ea7a7ee58e66628c55c776b "xen-pciback: limit guest control of command register" a guest is still allowed to enable those control bits (safely), but is not allowed to disable them and that therefore a well behaved frontend which enables things before using them will still function correctly. This is done via an write to the configuration register 0x4 which triggers on the backend side: command_write \- pci_enable_device \- pci_enable_device_flags \- do_pci_enable_device \- pcibios_enable_device \-pci_enable_resourcess [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO] However guests (and drivers) which don't do this could cause problems, including the security issues which XSA-120 sought to address. Reported-by: Jan Beulich Signed-off-by: Konrad Rzeszutek Wilk diff -r afe2ac5137b8 -r 2d24c59f9a4a drivers/xen/pciback/pciback_ops.c --- a/drivers/xen/pciback/pciback_ops.c Tue Mar 10 14:38:39 2015 +0100 +++ b/drivers/xen/pciback/pciback_ops.c Tue Mar 31 11:15:49 2015 -0400 @@ -32,8 +32,6 @@ #endif pci_disable_device(dev); - pci_write_config_word(dev, PCI_COMMAND, 0); - dev->is_enabled = 0; dev->is_busmaster = 0; } else {