Re: [Differential] D7185: Add virtio-console support to bhyve
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 to the guest, and in my view that means it should
be a tty to the host.
Well, it *can* be a tty to the host, but doesn't need to be.
that's madness. i'd like bhyve to remain for all time as clean as it is
now. so if you want a flat clean bidirectional channel for your "guest
additions" on the guest to talk to your "middleware" on the host, that's
fine by me, but don't let either end look like a tty to anybody. in
fact, it would be better for bhyve for you to implement both host and
guest drivers for virtio_vsock than to use the non-tty features of
virtio_console.
Driver supports multiple ports, and every port can be marked as a
"console" port. Linux guests create regular character devices for
"normal" virtio-console ports and ttys for "console" ports. My code
doesn't support "console" ports yet at all.
your initial mention of resize events up-thread gets harder and harder
for me to understand as we continue down-thread.
please don't implement "console" ports at all unless the host side of
such a port has to talk to a pts, pty, or nmdm. separately, let's work
together to get TIOC{S|G}WINSZ support working in nmdm. this means,
please don't let a guest tty talk to a host unix-domain socket that has
to have a second control channel for carrying tty events like window
size. just don't do that. make the guest tty talk to a host nmdm, pty,
or pts.
I agree that the console port should be a tty on the host. But there
are some things to consider: * There can be more than one - how do we
receive resize events from every pty? polling? fork per pty?
generally you let all the pts/pty/nmdm devices have the same pgrp and
when you get a SIGWINCH you poll all of your devices with TIOCGWINSZ.
the SIGWINCH event is rare enough and the number of devices is low
enough that this polling is not a performance problem.
* It doesn't necessarily need to be connected to bhyve process
stdin/stdout
bhyve should never connect its stdin/stdout to the guest. that's bad
design. let's work together to stamp it out, starting by never letting
any of your virtio_console ports (should you implement the kind that
appear to the guest as tty devices) to bhyve stdin/stdout.
* If bhyve opens pty(s), how would it communicate ptsname() back to
the user?
that would be a fine thing to send to stdout at bhyve initialization time.
if that pipe has resize events encoded in it, as you said earlier,
then it has to have a protocol, and it is not just a bidirectional
pipe.
Pipe itself doesn't have resize events. Resize events are transmitted
out of band, in a separate control queue. That out of band
communication is not visible to the unix domain socket consumer. It
could be made visible in two ways: a) by implementing multiplexing in
the unix domain socket protocol b) by using pseudo tty, connecting
pty data stream to the pipe and handing resizes separately.
if you say "we will never multiplex the unix domain socket" and you say
"pts, pty, or nmdm" rather than "pseudo tty", then we're in agreement.
We're using it in freenas-vm-tools, a "guest additions" package that
would allow host-guest interactions, such as automatic mounting of
the shared 9P storage when being added in the hypervisor GUI,
synchronizing time, potentially also suspending the I/O while
snapshotting the VM datasets, and so on. In the guest, virtio-console
is visible as a regular character device
(/dev/virtio-ports/org.freenas.vm-tools). On the host side, FreeNAS
10 middleware talks to it.
i would prefer to see this as a virtio_vsock.
thank you for explaining.
--
P Vixie
___
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"
[Bug 210425] [Hyper-V]"smartctl -i /dev/da0" on FreeBSD 10.3 on Windows 2010 & 2016 server caused disk detached
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210425 Hongjiang changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Hongjiang --- It has been fixed on head. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
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"
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, 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"
