Re: bhyve: disable msi and msix on virtio reset?
Hi, On Jul 12, 2016, at 7:38 PM, Peter Grehan 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. Tycho ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: disable msi and msix on virtio reset?
Hi Tycho, 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. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: disable msi and msix on virtio reset?
Hi, 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. Tycho On Jul 12, 2016, at 8:27 AM, Andriy Gapon wrote: > > A write of a zero to VTCFG_R_STATUS initiates a virtio device reset via > vc_reset. Typically this means a call to vi_reset_dev() which resets a > bunch of fields in virtio_softc, but does not touch a corresponding > pci_devinst (hanging off vs_pi) at all. Among other things this means > that PCI MSI and MSI-X states remain unchanged. One of the consequences > is that we keep using virtio_config_size of 24 if MSI-X is enabled. > > Should the virtio status reset also reset the PCI state? > > One practical problem that I see is with illumos fast reboot where the > illumos virtio driver assumes that the status reset is sufficient to > return a device to a state like after a clean (full) reboot. > > Thank you. > -- > Andriy Gapon > ___ > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscr...@freebsd.org" ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
bhyve: disable msi and msix on virtio reset?
A write of a zero to VTCFG_R_STATUS initiates a virtio device reset via vc_reset. Typically this means a call to vi_reset_dev() which resets a bunch of fields in virtio_softc, but does not touch a corresponding pci_devinst (hanging off vs_pi) at all. Among other things this means that PCI MSI and MSI-X states remain unchanged. One of the consequences is that we keep using virtio_config_size of 24 if MSI-X is enabled. Should the virtio status reset also reset the PCI state? One practical problem that I see is with illumos fast reboot where the illumos virtio driver assumes that the status reset is sufficient to return a device to a state like after a clean (full) reboot. Thank you. -- Andriy Gapon ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
