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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210425
Hongjiang changed:
What|Removed |Added
Resolution|--- |FIXED
Jakub Klama wrote:
if it's never going to appear as /dev/console or any other
tty-like device to the guest, then i won't care what it looks like
on the host. however, you said it could carry resize events, which
leads me to believe that the name (vertio-console) is not wrong,
and it is a tty
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.
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
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