When executing runsc spec -- /hello, I get an error:
panic: Only 4K page size is supported on arm64!goroutine 1 [running]:
gvisor.dev/gvisor/pkg/hostarch.init.0()
pkg/hostarch/hostarch_arm64.go:53 +0x54
Can you help me to change the page size?
jeyaprabhuj-tts
@jeyaprabhuj-tts
We have mapped usb camera in gofer as device with mknod and now also available in sentry as charector device .
But have issue with OpenCV recognizing it as camera
inside container
Bhasker Hariharan
@hbhasker
It probably issues some ioctls to detect the device. Those will need to be implemented in gvisor. If you have an strace we can see what ioctls it issues. Also if the source for the linux driver is available then that should give you an idea of the control interface for the device.
jeyaprabhuj-tts
@jeyaprabhuj-tts
We saw it is mapped as charector device but with major and minor as 0,0 .
after mapping into gofer as device using mknod , we added an enrty into mapping file shared between sentry and gofer (also unix socket pair fd for communication between sentry and gofer)
Bhasker Hariharan
@hbhasker
@jeyaprabhuj-tts mapping it as a device is only one step of the process. I am not sure of what setup you are attempting, could you open a bug with detailed step by step of what you are attempting. Having it exposed as a character device is probably not sufficient for the software to use it as it probably opens the device and then issues some control commands which need to be serviced by sentry (usually some sort of ioctl).
Now we are not using mount type bind instead took code from runc and added to runsc , to mount device using mknod in gofer
Sayan J. Das
@theseyan
Can anyone help me with the issue I posted above please
Bhasker Hariharan
@hbhasker
@theseyan you probably need to rebuild the kernel with the page size set to 4k
Specifically this configuration CONFIG_ARM64_64K_PAGES=y should be set to n and CONFIG_ARM64_4K_PAGES=y
Sayan J. Das
@theseyan
@hbhasker yeah that does it, thanks
jeyaprabhuj-tts
@jeyaprabhuj-tts
@hbhasker Is there a way to only use sentry and not gofer ? Directly mount volumes and devices inside sentry's namespace from host .
Bhasker Hariharan
@hbhasker
@jeyaprabhuj-tts Lets keep the discussion on the github issues. I believe fvoznika@ already responded to some of these on github. To answer the part about using sentry vs gofer no not out of the box. As to answer your question I am not sure I follow what you are asking.
@alephman9898:matrix.org This is not a trivial task so I am not sure there is an easy answer, because accessing a TPU/GPU in a container would require exposing it as a device inside the sandbox as well as implement GPU specific features in the gVisor sentry. Further there maybe questions on how is a GPU shared when there are multiple containers trying to use it etc.
There is something wrong with the hashes of runsc. I am looking at more 5 different hashes. It's a bit worrying. The hash check of the binary from the site also does not match when I run sha512sum -c.
:point_up: Edit: There is something wrong with the hashes of runsc. I am looking at more than 5 different hashes. It's a bit worrying. The hash check of the binary from the site also does not match when I run sha512sum -c.
Richard Stephens
@richard_st_twitter
hi. i'm trying to use gvisor with docker, mostly following this guide. when running containers in a custom network, they don't seem to get DNS reslotuion, either for containers running in the same network or to the internet.
Bhasker Hariharan
@hbhasker
could you provide more details on how the containers are connected to the network?
or maybe open a bug with more details
Richard Stephens
@richard_st_twitter
while writing up the issue i realised that it actually works, but that it doesn't start working immediately
will still file an issue
argh, no, scratch that, just realised that test was without the --runtime runsc flag
will take a look. Most likely it fails because runsc does not copy over whatever docker is doing to setup DNS for containers (either sticking in a custom /etc/resolv.conf or setting up some custom DNS server reached by remapping 127.0.0.1:53 to a custom docker dns resolver) See: google/gvisor#7469 for a similar bug with docker compose
hey, gvisor has own netstack, but I wonder why don't use LWIP, and is there a comparison for them?
Richard Stephens
@richard_st_twitter
@hbhasker thanks for that. for now i've worked around it by importing my own resolv.conf into the container with 8.8.8.8, and using the ip addresses from docker network inspect for the inter-container communications.
Bhasker Hariharan
@hbhasker
@alephman9898:matrix.org gVisor is a security sandbox and as a result we made an early decision to write it in a memory safe language which means it pretty much ruled out all existing network stacks.
At this point I would say gvisor Netstack is more mature than LWIP and implements more TCP/UDP features and IP capabilites than LWIP.
I believe gvisor netstack will perform better under various network condtions. Over a lossless low latency link lwip might work fine. But performanxe is just one aspect and a network stack for gvisor has to do a lot more.
At Ant Group, we mainly use gVsior in east-west lossless communication (LB/firewall in responsible for north-south networking). Three year ago, we integrated TLDK into gVisor as we care performance more by sacrificing a little on security; that saves us 2%~8% CPU utils and brings better latency (with a passthrough VF net device).
Bhasker Hariharan
@hbhasker
@tanjianfeng since then gvisor has improved quite a bit. We implemented RACK and socket buffer auto tuning which should help with long fat pipes. Cpu we are working on and i think we will be able reduce cpu usage significantly as the buffer pooling canges land in the next 2-3 months
Is it a known/accepted issue that go test ./... completely fails on the master branch due to all sorts of problems with build tags?
I have been trying to figure out how to write tests for google/gvisor#7281 but seemingly the tests are broken with native Go tooling and Bazel builds don't work on macOS either