Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome OS KVM - A component written in Rust

chromium.googlesource.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Chrome OS KVM - A component written in Rust

#81

Post by steveklabnik »

zaxcellent wrote: post #77
steveklabnik wrote: post #53

Earlier quoted context omitted.

I am super excited to see this! Glad we've already been helpful, but I'd like to reaffirm that if you need anything, we'd like to continue being helpful in the future :)

Thanks! I've really appreciated your Rust guides over the years. It's been so handy that we pre-ordered 5 copies of your Rust Programming Language book a few months back. I can't wait to get my hard copy. :)

Wonderful; we had some delays but it's back to full-steam ahead. I can't wait to get a hard copy too :)

Re: Chrome OS KVM - A component written in Rust

#82

Post by zaxcellent »

tmzt wrote: post #59
zaxcellent wrote: post #47

Earlier quoted context omitted.

Author here: Rust is not officially sanctioned at Google, but there are pockets of folks using it here. The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance. That being said, there was a ton of work getting Rust to play nice within the Chrome OS build environment. The Rust folks have been super helpful in answ…

Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS. Also, the Wayland stuff looks cool but I'm not sure how you are managing the buffers with just the wl protocol. There is a Wayland crate for Rust that also has support for generating protocol from the xml…

>Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS.

Sadly, not many of the components within crosvm would make good crates in crates.io. The crates in crosvm tend to be laser focused on solving a specific use case within crosvm. There are more general versions of lots of the functionality we have in crosvm that exist in crates.io (e.g. eventfd or memory maps) that we skipped to avoid excessive external dependencies.

>Also, the Wayland stuff looks cool but I'm not sure how you are managing the buffers with just the wl protocol.

The virtio wayland I designed is intended to be somewhat agnostic of the underlying wayland protocol for simplicity. It just passes along the protocol bytes to the host's wayland compositor. In order to share FDs with the host (to support e.g. buffers and keymaps), crosvm has a mapping of virtual file descriptor IDs known to the guest kernel to host FDs that get passed along to the wayland compositor.

>though it would be cool to support the virtio p9fs as a root filesystem.

We considered it, but for our application, 9pfs was not going to be optimal. That being said, we'd welcome patches that added support for it. :)

>And, I know you can't say anything about this, but I'm happy to see the arm support in there

The ARM support is rather preliminary. crosvm will compile for ARM but it has yet to succesfully boot a VM.

Re: Chrome OS KVM - A component written in Rust

#83

Post by bluetech »

zaxcellent wrote: post #48
petertodd wrote: post #37

Earlier quoted context omitted.

That's low-level code implementing a wrapper around the underlying libc socket API; there's no alternative to unsafe blocks there as it wraps a legacy API written in C. The "this is safe" comment is just a (very verbose) explanation as to why the wrapper code is doing the correct thing. Notably, there's another similar comment just above it. In fact, looking through the file if anything I'm quite impressed at how car…

Author here: one of the policies we tried to stick to when writing unsafe code was to document each case. It can be tedious but it encourages having less unsafe code and makes the author really think about if this unsafe code is really meeting the same guarantees as safe Rust according to https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

The line above has this:

    // This is safe since we check the return value.
    let sock = unsafe { libc::socket(libc::AF_INET, libc::SOCK_DGRAM, 0) };
    if sock
I think in this case it would be better to put the return value check within the unsafe block, this way the unsafety does not "leak out" of the block, so to speak, so it is easier to audit. Of course in such a trivial case it does not matter much.

Re: Chrome OS KVM - A component written in Rust

#84

Post by pjmlp »

kibwen wrote: post #74
indy wrote: post #7

Is Rust an officially sanctioned language at Google?

Offtopic, but I've always been a bit confused by the notion of "officially sanctioned" at Google... famously it's "Java, C++, Python, Go", but I've never heard anyone mention Javascript, which they obviously must use... or TypeScript (via Angular), or Dart (AdWords and Fuchsia), or C (Google does tons of Linux work), or ObjC/Swift (all their iOS apps). And these are only for projects we know about (if there's no Perl…

I would say any language on the official Google style guide web site.

https://google.github.io/styleguide/

All the languages you mention are there.

Re: Chrome OS KVM - A component written in Rust

#85

Post by tmzt »

zaxcellent wrote: post #82
tmzt wrote: post #59

Earlier quoted context omitted.

Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS. Also, the Wayland stuff looks cool but I'm not sure how you are managing the buffers with just the wl protocol. There is a Wayland crate for Rust that also has support for generating protocol from the xml…

>Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS. Sadly, not many of the components within crosvm would make good crates in crates.io. The crates in crosvm tend to be laser focused on solving a specific use case within crosvm. There are more general ver…

Oh, okay.

I was actually referring to your kvm and kvm-sys crates, through it seems that some of the memory management stuff is closely tied to that. I ask because I tried to build a kvmd daemon using the kvm-rs crate that's out there, but ran into some issues. At the time bindgen was not quite up to the task of handling the kernel headers itself as well.

> The virtio wayland I designed is intended to be somewhat agnostic of the underlying wayland protocol for simplicity. It just passes along the protocol bytes to the host's wayland compositor. In order to share FDs with the host (to support e.g. buffers and keymaps), crosvm has a mapping of virtual file descriptor IDs known to the guest kernel to host FDs that get passed along to the wayland compositor.

Okay, I guess I'm more asking how software running on the VMs are accessing buffers on the GPU which are managed by the Wayland server, as I don't see anything in the virtio folders referring to this. I guess this is just using some kind of shared memory region then? I'll have to look at it more later.

Also, this low-level Wayland really seems like it could be a standard way to access GPUs through a hypervisor, maybe something that could be implemented by (k)qemu or others.

> We considered it, but for our application, 9pfs was not going to be optimal. That being said, we'd welcome patches that added support for it. :)

Yes, and I might try to get to that sometime. I really like the approach starting with vmlinux and not a BIOS implementation, anything to make the OS boot faster in the VM is good.

> The ARM support is rather preliminary. crosvm will compile for ARM but it has yet to succesfully boot a VM.

Understood.

Re: Chrome OS KVM - A component written in Rust

#86

Post by pjmlp »

dikaiosune wrote: post #80
colemickens wrote: post #78

Earlier quoted context omitted.

Sorry, I didn't mean to put words in your mouth or anything. I am quite curious which parts you think would better benefit from a rewrite in a safer language if you might elaborate. Thanks!

Oh no worries, I might have come off a bit defensive there. I think one of the clearest examples would be drivers -- they might be properly sandboxed by a good microkernel, but they are notoriously buggy/crashy/incorrect. If I remember correctly one of the Fuchsia team members told me that they were going to support drivers written in Rust, but I could be completely wrong. Filesystems, the network stack, whatever hor…

Some filesystems and the network stack from Fuchsia are written in Go.

Re: Chrome OS KVM - A component written in Rust

#87

Post by dikaiosune »

pjmlp wrote: post #86
dikaiosune wrote: post #80

Earlier quoted context omitted.

Oh no worries, I might have come off a bit defensive there. I think one of the clearest examples would be drivers -- they might be properly sandboxed by a good microkernel, but they are notoriously buggy/crashy/incorrect. If I remember correctly one of the Fuchsia team members told me that they were going to support drivers written in Rust, but I could be completely wrong. Filesystems, the network stack, whatever hor…

Some filesystems and the network stack from Fuchsia are written in Go.

Cool! Accomplishes many of the same goals that doing it in Rust would, arguably. I would be curious to hear about what sort of latency-management techniques they've used to build an FS in a GC'd environment.

Re: Chrome OS KVM - A component written in Rust

#88

Post by sangnoir »

How does this square with rumors from a few days ago that the Pixelbook will be able to run virtualized Windows (or Linux)? I do not understand the implication of "No actual hardware is emulated."

If the Pixelbook can run Window or Linux in a VM, then its price slides a little closer towards justifiable.

Re: Chrome OS KVM - A component written in Rust

#89

Post by pjmlp »

dikaiosune wrote: post #87
pjmlp wrote: post #86

Earlier quoted context omitted.

Some filesystems and the network stack from Fuchsia are written in Go.

Cool! Accomplishes many of the same goals that doing it in Rust would, arguably. I would be curious to hear about what sort of latency-management techniques they've used to build an FS in a GC'd environment.

Here is some more information

https://github.com/fuchsia-mirror?language=go

https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1P...

Regarding your specific latency issue with a GC systems language, here is a Mesa/Cedar example about a network file server.

http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-6.pdf

Re: Chrome OS KVM - A component written in Rust

#90

Post by bonzini »

zaxcellent wrote: post #47
indy wrote: post #7

Is Rust an officially sanctioned language at Google?

Author here: Rust is not officially sanctioned at Google, but there are pockets of folks using it here. The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance. That being said, there was a ton of work getting Rust to play nice within the Chrome OS build environment. The Rust folks have been super helpful in answ…

KVM maintainer here. I agree that this makes a lot of sense to write in Rust. Some time ago there was even a demo of a qcow2 format driver for QEMU written in Rust.

I also find your Rust style extremely readable. Great job!

Post reply on HN