Date: Tue, 12 Jul 2016 20:21:02 -0400 From: Tycho Nightingale <tycho.nightingale@pluribusnetworks.com> To: Peter Grehan <grehan@freebsd.org> Cc: Andriy Gapon <avg@FreeBSD.org>, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@FreeBSD.org> Subject: Re: bhyve: disable msi and msix on virtio reset? Message-ID: <6D0C5EB5-0983-4D4C-A8EE-18254E56C557@pluribusnetworks.com> In-Reply-To: <22aa6570-6a2e-e5d6-1882-86b9ffcb15e7@freebsd.org> References: <011771a3-8424-7810-d9db-870ddcea2448@FreeBSD.org> <7D5D0A30-1ABA-49F6-83CC-6F398FC25B05@pluribusnetworks.com> <22aa6570-6a2e-e5d6-1882-86b9ffcb15e7@freebsd.org>
index | next in thread | previous in thread | raw e-mail
Hi, On Jul 12, 2016, at 7:38 PM, Peter Grehan <grehan@freebsd.org> wrote: >> Yes, writing 0 to the status resister should reset the device >> including all PCIE state. This implies that vi_reset_dev() needs to >> take the proper actions to bring the associated pci_devinst (which >> from the guest’s perspective isn’t a discrete element) back to it’s >> reset state too. > > I'm not sure if the reset also hits PCIe state, if you're counting config space as part of that (e.g. BAR contents). As an example, the FreeBSD guest virtio code doesn't do any config space saves/restores around a reset. This is one of those ambiguities in the virtio spec wherein the canonical implementation (qemu) becomes the de facto standard. I see in illumos driver that only a virtio-reset is performed in the quiesce entry point. On qemu Is this sufficient on qemu to support warm rest? If so then perhaps we should only clear the capabilities (MSIX) and not the BARs. Tychohelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D0C5EB5-0983-4D4C-A8EE-18254E56C557>