From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] device-assignment: register a reset function Date: Mon, 15 Nov 2010 22:58:11 +0100 Message-ID: <4CE1ACF3.3020104@web.de> References: <1284740181.14301.15.camel@x201> <1289820837-24254-1-git-send-email-bernhard.kohl@nsn.com> <4CE122CC.6050700@siemens.com> <1289853510.2805.233.camel@x201> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig31E92CACFBBA603D9E991228" Cc: Bernhard Kohl , Thomas Ostler , kvm , "Michael S. Tsirkin" To: Alex Williamson Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:35251 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755112Ab0KOV6Q (ORCPT ); Mon, 15 Nov 2010 16:58:16 -0500 In-Reply-To: <1289853510.2805.233.camel@x201> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig31E92CACFBBA603D9E991228 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 15.11.2010 21:38, Alex Williamson wrote: > On Mon, 2010-11-15 at 13:08 +0100, Jan Kiszka wrote: >> [Wrong list, it's not upstream yet. I'm migrating the thread to kvm.] >> >> Am 15.11.2010 12:33, 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 >>> Signed-off-by: Bernhard Kohl >>> --- >>> Sorry for for the long delay. Finally we added Alex' suggestions >>> and rebased the patch. >>> >>> Thanks >>> Bernhard >>> --- >>> hw/device-assignment.c | 12 ++++++++++++ >>> 1 files changed, 12 insertions(+), 0 deletions(-) >>> >>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c >>> index 5f5bde1..3f8de66 100644 >>> --- a/hw/device-assignment.c >>> +++ b/hw/device-assignment.c >>> @@ -1434,6 +1434,17 @@ static void assigned_dev_unregister_msix_mmio(= AssignedDevice *dev) >>> dev->msix_table_page =3D NULL; >>> } >>> =20 >>> +static void reset_assigned_device(DeviceState *dev) >>> +{ >>> + PCIDevice *d =3D DO_UPCAST(PCIDevice, qdev, dev); >>> + uint32_t conf; >>> + >>> + /* reset the bus master bit to avoid further DMA transfers */ >>> + conf =3D assigned_dev_pci_read_config(d, PCI_COMMAND, 2); >>> + conf &=3D ~PCI_COMMAND_MASTER; >>> + assigned_dev_pci_write_config(d, PCI_COMMAND, conf, 2); >> >> What about writing to /sys/bus/pci/devices/$DEVICE/reset? You probably= >> still need to put the command word into the reset state (ie. no RMW in= >> any case, just write 0), but the hardware should receive a reset as we= ll >> - if it is capable of doing a function-level reset, but we should at >> least try. >=20 > libvirt doesn't currently give us write access to that file, so it'd > require changes up the stack too. We could accomplish the same by > deassigning and reassigning the device through KVM, but that seems erro= r > prone. I'm not entirely convinced it's really necessary to go that far= , > I expect there's some physical systems out there that don't reset the > device on a warm reset. In any case, I think doing this much is at > least a good start. Thanks, OK, can be done on top of it - but should be done as most systems perform a reset that is even stronger than pci_reset_function (I've seen devices only recovering after warm reboot). Still, I would suggest assigned_dev_pci_write_config(d, PCI_COMMAND, 0, 2); i.e. reset command word to specified reset state. Jan --------------enig31E92CACFBBA603D9E991228 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzhrPUACgkQitSsb3rl5xSKbQCfdDNNm1YmZQToAX7AnkO3Jr/o qQQAoOM9uou6Fgw5G0qx2iAlOeZaF65Q =gTj9 -----END PGP SIGNATURE----- --------------enig31E92CACFBBA603D9E991228--