vhost-user-vsock implements vsocks as uds on the host.

i wonder what it takes to implement that in this package.
there appears to be a rust impl

https://github.com/rust-vmm/vhost-device/pull/7/files

but i'm not sure if thats the correct layer

We should basically mimic what net's TCP sockets do, rather than returning random bare syscall errors.

I search source code of golang net/http package, and found the keepAlive feature depends on linux syscall.

// this is golang net/http source code in src/net/sockopt_posix.go: 118
func setKeepAlive(fd *netFD, keepalive bool) error {
err := fd.pfd.SetsockoptInt(syscall.SOL_SOCKET, syscall.SO_KEEPALIVE, boolint(keepalive))
runtime.KeepAlive(fd)
return wrapSyscallError("setsockopt", err)
}

I am develop a new package like net/http, depend on this vsock package instead of socket.
But I dont now how to add keepAlive with linux syscall.

Hi, I am using vsock to listen requests for a grpc Server, but on client-side, I use a namd pipe to connect to the vsock. Could this be ok?

There's a lot going on here that could easily break, so we should work out a way to do integration tests with qemu and ensure messages can be passed back and forth appropriately.

In prep for a v1.0.0 (long overdue) I would like to rework this library to use https://github.com/mdlayher/socket and to have a more robust integration testing story. In the meantime I will ping the outstanding PRs to note this intent.

I should show folks how to get up and running with VM sockets, so they don't need to do a bunch of Googling like I did.

for example, i wanna to run a golang process listen on the vsock port in windows guest.

Hi,
I was using go get -u github.com/u-root/cpu/... command, it cloned this repo, then showed the error message as below:

chiao@Ubuntu2204VM:~/git/linuxboot/mainboards/ampere/jade$ go get -u github.com/u-root/cpu/...
# github.com/mdlayher/vsock
/home/chiao/go/src/github.com/mdlayher/vsock/listener_linux.go:32:28: not enough arguments in call to l.c.Accept
        have (number)
        want (context.Context, int)

I've changed my golang version to 1.18.7 as the same as this repo's CI, but the error occurred again.
I cd into the repo dir and go test. Failed with same error.

chiao@Ubuntu2204VM:~/go/src/github.com/mdlayher/vsock$ go test
# github.com/mdlayher/vsock [github.com/mdlayher/vsock.test]
./listener_linux.go:32:28: not enough arguments in call to l.c.Accept
        have (number)
        want (context.Context, int)
FAIL    github.com/mdlayher/vsock [build failed]

Here's my env:

chiao@Ubuntu2204VM:~/git/linuxboot/mainboards/ampere/jade$ uname -a
Linux Ubuntu2204VM 5.15.0-52-generic #58-Ubuntu SMP Thu Oct 13 08:03:55 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

chiao@Ubuntu2204VM:~/Downloads$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/chiao/.cache/go-build"
GOENV="/home/chiao/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/chiao/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/chiao/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.7"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1116994110=/tmp/go-build -gno-record-gcc-switches"

Thanks for this great package - it does exactly what it says on the tin!

I need to pass the file descriptor to a vsock connection to a child process. Is there a straightforward way to get the fd (or an os.File) from the Conn retured from Accept?

I know my type, and am willing to type assert.

Add the connectionless counterparts alongside the existing connection-oriented API.

Turns out, developing this on my machine with an old kernel lead me to believe that /dev/vsock was the only device available for querying. I was incorrect!

It isn't clear to me how close we are to having this already done, but as of Go 1.12, we should be able to create:

• net.Listener that can accept and wait indefinitely without EAGAIN, but also be closed while blocking
• net.Conn that can have timeouts set and be closed concurrently (already done?)

For the gist of how to do this, see: mdlayher/raw@f434146. I don't currently have an easy way to test this package, but perhaps I can get my hypervisor setup back up and running to do some verification of any required changes in a few days.

Or perhaps, everything will just work! We'll see.

I don't immediately have time to work on this, but I suspect folks who are using this in their projects will take a great interest in making timeouts work and providing added efficiency to their applications. :)

/cc @aybabtme @mxpv @pmorjan

I use the example codes in https://mdlayher.com/blog/linux-vm-sockets-in-go/ and change the message "hello world" to a string with length 7000+, then i find the vsock client&server hang, does anyone have some ideas?

Maybe you know this or not but when you have a single attribute object, if you take out the name of the attribute it becomes easier to interact with and makes the code quite a bit more expressive.

For Example:

type Listener struct {  
      *listener           
 }      

You can see I removed the "l" name to the listener attribute, but its because it makes the rest of the code capable of being simpler to interact with and a bit less redundant.

func (listener *Listener) Accept() (net.Conn, error) {
      c, err := listener.Accept()  
      if err != nil {     
          return nil, self.opError(opAccept, err)
      }                   
                          
       return c, nil       
   }         

So as you can see here, now I can just do listner.Accept() and it works just the same as before, this is opposed to your version where it is l.l.Accept(), or if you used the full variable name it would have been listener.l.Accept().

It is not a massive difference but this type of simplicity can be used throughout the codebase and make everything a bit easier to use.

If you are interested in making this change I can issue a pull request as I'm rebuilding the library, adding more functionality, including memory FD for faster connections.

You are a great coder, love reading your work, and you have done a lot of useful projects for me. Like your fibre library made it easy for me to build my own modem and get rid of my proprietary fiber optic modem :D Thanks

I cannot seem to ever to get past the resource temporarily unavailable error. It seems to retry a bunch, but never succeeds in a connection. This may not even pertain to this library, but any clue to why this is occurring would be great!

Right now when the library returns "closed" errors (which many users need to test against), it is not returning net.ErrClosed like the standard net libraries since Go 1.16. Instead of returning a local error that requires us to inspect the message text, can you return net.ErrClosed instead? It won't break existing code that checks the message, as the message inside of net.ErrClosed is identical. On the plus side, it will make the vsock library more compatible with code that was written to the built-in net library APIs. Thanks!

See https://github.com/lxc/lxd/pull/9894 for details.

This is likely due to the added use of nonblocking connect(2), but there should be some way to add error reporting. This will likely get plumbed into the socket package.

It seems that fda437e changed the behavior of the Accept method of vsock listeners. Accept is no longer a blocking operation. You can no longer simply loop on Accept() like in the example below. Accept always fails with EWOULDBLOCK. The demo in cmd/vcsp also fails. Is this intended? Thanks.

for {
	c, err := l.Accept()
	if err != nil {
		panic(err) // resource temporarily unavailable
	}
	go func() { doSomething(c) }()
}

Hello. I suspect that there is a bug in vsock package (or could be I'm missing some thing).
It looks like Accept remains blocked after listener is closed (and should immediately return an error instead).
Here is an example:

package main

import (
	"log"
	"sync"
	"time"

	"github.com/mdlayher/vsock"
)

func main() {
	listener, err := vsock.Listen(1024)
	if err != nil {
		panic(err)
	}

	var wg sync.WaitGroup

	wg.Add(1)

	go func() {
		defer wg.Done()

		log.Print("before accept")
		_, err := listener.Accept()
		log.Printf("accept error: %v", err)
	}()

	time.Sleep(1*time.Second)

	log.Print("closing listener")
	err = listener.Close()
	if err != nil {
		log.Printf("close error: %v", err)
	}

	log.Print("waiting")
	wg.Wait()

	// Never happens because Accept never unblocks
	log.Print("exiting")
}

And the output is:

./vsock
2018/11/08 22:38:37 before accept
2018/11/08 22:38:38 closing listener
2018/11/08 22:38:38 waiting

...

I was able to reproduce this on 2 machines:

• Ubuntu 16.04, 4.15.0-38-generic
• EC2, Amazon Linux 2, 4.14.70-72.55.amzn2.x86_64

There is similar issue #13 but the fix is not working on go1.11.1.

Thanks!

CC @samuelkarp

See #16.

This is a pretty big and unexpected departure from the net.Conn contract, which explicitly states:

// Close closes the connection.
// Any blocked Read or Write operations will be unblocked and return errors.
Close() error

The reason it happens is that in current versions of Go, os.NewFile() assumes that the provided file descriptor points to a file and doesn't support polling. As a consequence, it uses straight syscalls to handle Read and Write, and it is a well known weirdness of Linux that close() doesn't unblock recv*() from other threads. From the close(2) manpage:

When dealing with sockets, you have to be sure that there is no recv(2) still blocking on it on another
thread, otherwise it might block forever, since no more messages will be send via the socket. Be sure to use shutdown(2) to shut down all parts the connection before closing the socket.

From there, there are two options:

1. Extend the current Close() to call shutdown(), which will unblock the blocked recv();
2. Wait for Go 1.11, which now has support (since golang/go@ea5825b) for creating pollable os.File objects from os.NewFile(). For that, all you have to do is to set the file descriptor to non-blocking mode before passing it to os.NewFile()

If we expose Conn, we can still implement net.Conn, but also add more methods that can shut down the read or write ends of the socket, configure socket options, etc.

Since go vet didn't like my unsafe.Pointer magic, I'll have to rework things in the way that zeebo suggested on Slack.

This will simplify the internals a lot and fix some annoying behaviors in caller code. We should only support versions of Go that are also supported by the upstream project.