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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=92s perspective isn=92t a discrete element) back to = it=92s >> reset state too. >=20 > 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. Tycho=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D0C5EB5-0983-4D4C-A8EE-18254E56C557>