Re: This week in Spectrum

Amanjeev Sethi
2020-04-12T22:20:15Z

I find these emails a nice read when I have time. I am perhaps not on the devel list (not a devel).

On Sun, Apr 12, 2020, at 12:30 PM, Alyssa Ross wrote:
> Before we begin, **if you are subscribed only to the discuss mailing
> list**, I'd like to hear from you whether you'd like future weekly
> development updates to come to you or not, because I'm not really sure
> whether this sort of update belongs on the devel mailing list, or the
> discuss one. So for this initial edition, I'm sending to both, but I
> probably won't do that going forward.
>
> So, as I wrote in the recent status update on my blog, I'm going to try
> weekly(?) mailing updates instead of lengthy blog posts every few
> months. I was going to start last week, but I ended up taking most of
> the week off because I'd been working every day for a long time and was
> starting to find it difficult to concentrate. But I'm back now, and
> this week has been a good one.
>
>
> Spectrum Live
> -------------
>
> (This was actually last week, but I felt this deserved a mention.)
>
> A bit more than a week ago now, I did a live stream where I showed
> myself working on a fairly simple change to crosvm. Viewer numbers
> stabilised at around 11, and we had a lively IRC conversation, which I
> was pleasantly surprised by. I ended up spending most of the stream not
> working on that change, but instead explaining how various things in the
> system will work, and helping getting a couple of people started running
> the Spectrum code. By the end of the stream two people had succeeded in
> this, and that means two people who are set up to work on Spectrum. One
> was even starting work on trying to build a smaller kernel for Spectrum
> VMs!
>
> Overall I think this was extremely successful, and I'll try to do it
> again soon. I'll announce the stream a bit ahead of time in #spectrum
> on Freenode.
>
>
> crosvm
> ------
>
> Having previously split crosvm into two separate programs -- one to run
> a virtual device, and one to run a device VM -- I further split it into
> three programs. This might sound a bit silly, but here's the idea --
> one program is the crosvm that runs an application VM, the second will
> become part of the crosvm that runs a device VM, and the third will be
> the device implementation itself, that will run inside the device VM.
> As a reminder, the overall idea here is to put virtual devices into
> their own VMs, rather than being run directly on the host.
>
> I also pulled in the latest changes from Google. Of particular note is
> commit 146450b, which updates the msg_socket library to support
> dynamically sized messages. If you're paying attention, you'll recall
> that I just wrote my own serde-based replacement for msg_socket because
> I needed to do exactly this. That work might now have been superseded,
> but I'm not sure yet. msg_socket2 uses SOCK_STREAM sockets (which can
> be used between VMs or VM<->guest), while msg_socket uses
> SOCK_SEQPACKET, which can't. I haven't checked whether msg_socket's new
> implementation could work without SOCK_SEQPACKET-style preserved message
> boundaries -- if it can't, msg_socket2 will stick around. msg_socket2
> also properly handles file descriptor lifetimes using the borrow
> checker. This means that safe Rust code can't send closed or
> non-existent file descriptors over msg_socket2. msg_socket does not do
> this, because it just represents file descriptors as integers with no
> lifetime information. Whatever happens to msg_socket2, at some point
> I'll want to make msg_socket do file descriptor lifetimes properly. In
> general, it's not clear from existing documentation how to properly
> handle file descriptor lifetimes in Rust, and so I plan a blog post on
> this topic soon.
>
> The next problem is to figure out communication between the device VM
> and the device crosvm. The protocols currently in use rely on being
> able to share memory using file descriptors, which is not possible
> between a VM and the host. To avoid using file descriptors, I would
> have to change those protocols, possibly on a per-device basis, which
> would be a lot of work, and might have to be done again whenever crosvm
> adds a new device type. But, I think I might have a better, if
> surprising solution. Despite its name, the Virtio Wayland protocol has
> almost nothing to do with Wayland. Instead, it's a fairly generic
> socket-like protocol that allows sending "virtual file descriptors" of
> certain specific types between a VM and its host. So I think I should
> be able to send this sort of communication over "Virtio Wayland",
> without requiring any changes to the communications being channeled. I
> just had this idea, so it's entirely possible it won't work out, but I
> think it's a neat unexpected reuse of a cool technology.
>
>
> Infrastructure
> --------------
>
> The web interface for the Spectrum mailing lists has been upgraded from
> Django 1.11 (which is now EOL) to Django 2.2 (current LTS; Nixpkgs
> default). I sent this upstream as Nixpkgs PR #84896.
>
> Additionally, spectrum-os.org. now has an SPF header, which I thought
> was already there but apparently wasn't. This should help with mailing
> list deliverability.
>
>
> That's it for this week. Feel free to reply with any comments or
> insights, either on the content or the format. I'll try to be back with
> another development update next week.
>
> Attachments:
> * signature.asc