| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent versions of wlroots (not yet in Spectrum's Nixpkgs) make it
impossible to use Wayfire as a Wayland client over Virtio Wayland,
because of an architectural change in wlroots that means dma-bufs are
now required to use the GLES2 renderer, which is the only one Wayfire
supports, with the Wayland backend. Sommelier as a compositor does
not (and cannot) support the zwp_linux_dmabuf_v1 Wayland protocol this
requires, because to do so it would have to be able to send dma-bufs
allocated by the guest client over Virtio Wayland. (This isn't
possible because of general difficulties with guest->host memory
sharing.)
The "comp" VM as it stands is designed to be used with spectrum-vm, as
a demo that people can run on their non-Spectrum systems, and see a
Wayland compositor appear as a Wayland window in their host
compositor. Since it's no longer possible to use Wayfire for this use
case, let's use tinywl here instead, since we have no requirements
that it doesn't fulfill as a minimum-viable compositor.
This doesn't change anything regarding non-demo uses of Spectrum.
Running a Wayland compositor itself as a Wayland client is not an
activity that really makes sense in an actual Spectrum system.
Realistic use cases for Wayland compositors in Spectrum (on a host
system, or in a VM with a GPU passed through, or possibly in a VM with
virtio-gpu) are not affected by this limitation, since in all cases
the compositor would render directly to a GPU, not to a Wayland window
to be displayed by another compositor.
Message-Id: <20210701155446.1306212-3-hi@alyssa.is>
|
| |
|
|
|
| |
Message-Id: <20210630092021.58387-3-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* chromiumOSPackages.linux: fix config
* chromiumOSPackages.common-mk: update patches
* chromiumOSPackages.vm_protos: drop GN patch
The missing dependency has been added upstream.
* chromiumOSPackages.common-mk: disable clang-only warnings
* chromiumOSPackages.sommelier: update patches
Support for stable xdg-shell was implemented in upstream Sommelier,
but then reverted because the GTK version that comes with the Debian
in the container Chromium OS uses was too old to support it.
That's not a problem for us, of course, but it does mean that we can
use an upstream implementation of xdg-shell. So here I switch from
using Puck's implementation, to reverting the revert of the upstream
one.
* crosvm: fix outdated Cargo.lock from upstream
* crosvm: update VIRTIO_NET_F_MAC patch (renamed to be less annoying)
* crosvm: add new dependencies
* crosvm: patch boot test so it doesn't fail because of no /dev/log.
* crosvm: disable boot test on x86_64 because it often hangs on the AMD
EPYC 7401P 24-Core Processor I was testing it on (but not my Intel(R)
Core(TM) i5-2520M CPU @ 2.50GHz).
* spectrumPackages.linux: drop evged patch
This has reached the Chromium OS kernel now, so we don't need to apply
it ourselves any more.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
Cc: Puck Meerburg <puck@puckipedia.com>
Reviewed-by: Alyssa Ross <hi@alyssa.is>
Tested-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20210529144117.571353-2-hi@alyssa.is>
Message-Id: <20210529144117.571353-3-hi@alyssa.is>
Message-Id: <20210529144117.571353-4-hi@alyssa.is>
Message-Id: <20210529144117.571353-5-hi@alyssa.is>
Message-Id: <20210529144117.571353-6-hi@alyssa.is>
Message-Id: <20210529144117.571353-7-hi@alyssa.is>
Message-Id: <20210529144117.571353-8-hi@alyssa.is>
Message-Id: <20210529144117.571353-9-hi@alyssa.is>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no need for every interface on a router to have it's own
unique IP. Using link-local addresses, we can assign every interface
on a single router the same IP, and save the effort of
adding/subtracting one all the time to infer the address of one side
of a link from the other.
This means that routers and clients are both only interested in what
the IP of the client should be, since that's the only thing that is
different between different links. So we change our MAC format to
communicate the client IP to both sides. If we just made the whole
NIC portion of the MAC the last three octets of an IP address like we
did before, then both ends of the link would have the same MAC, so we
still need to set a bit to encode whether a MAC is at the router side
of the link or the client side. I've decided to simplify the
implementation by using the most significant bit of the NIC part for
that, and just declaring the rest of that octet to be reserved. This
way, no calculation is required in the guests -- they just need to
look at the last two octets. And we can still identify 65536 links in
this scheme, which should be enough for anybody, right?
Message-Id: <20210513201323.2087344-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/etc/passwd set the messagebus user's primary group to 1, but there
was no group with that id in /etc/group. The messagebus group had id 4.
The 4 comes from NixOS. I think it's probably a good idea to use the
same user and group ids where possible -- there's no particular reason
to diverge -- so let's fix it in /etc/passwd instead of changing the
id in /etc/group to 1.
And while we're here, for consistency, let's change the user id of
messagebus to 4 as well, so that's consistent with NixOS as well.
I don't think the user ID is used anywhere else.
This fixes the DBus "Permission denied" errors that have been showing
up in vm-net since forever (but never seemed to cause any real harm...).
Fixes: 52e93c79d82 ("spectrumPackages.rootfs: add dbus configuration")
Message-Id: <20210422010105.415233-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following operations are available to us in /sys/bus/pci/drivers/vfio-pci:
bind, unbind, new_id, remove_id
bind and unbind control attachment of a device to a driver.
new_id and remove_id control whether a device should be considered
"supported" by a driver.
But when an unassigned device is newly supported by a driver, the
kernel will automatically bind it to that driver. We were relying on
the new_id operation binding the device to the driver in this way.
But if the driver is in the supported list, but not bound to anything,
this won't happen. new_id won't do anything, because it's already in
the supported list. So we can't rely on new_id binding for us, and
need to try bind as well (at least if new_id fails).
To reproduce:
echo 8086 1502 > /sys/bus/pci/drivers/vfio-pci/new_id
echo 0000:00:19.0 > /sys/bus/pci/drivers/vfio-pci/unbind
(Use lspci -nn to find the right values for your hardware.)
This will leave you with a device that is supported by vfio-pci but
not bound to it, which would previously cause vm-net to fail to start,
but should not after this change.
Message-Id: <20210421101605.20790-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This produces a shell script that sets up a host system for running
the VMs under sys-vms, and then starts an s6-rc service manager that
can run the VMs. This mirrors how I imagine things working on the
eventual Spectrum host system.
With s6-rc, we can express dependencies between services, so when
vm-app is started, vm-net will automatically be started too if it
isn't already running.
One thing I haven't implemented yet is readiness notification.
Ideally, the cloud-hypervisor instance running the router VM would be
able to tell s6 once its control socket was listening, and s6 wouldn't
consider it to be up until that point. But it can't do that at the
moment, so s6 considers it to be up immediately, and starts vm-app
right away. This means that vm-app will usually fail once due to
vm-net's socket not existing, and then immediately be restarted and
work the second time. I think that's fine for now.
The serial console for vm-app will be connected to the terminal. To
interact with vm-net instead, the serial console for vm-app can be
disconnected uncommenting the two commented out lines in its
definition, and the serial console for vm-net can be enabled by
commenting the redirfd that disables its stdin, and uncommenting the
--serial line.
We're using cloud-hypervisor instead of crosvm for vm-net because
cloud-hypervisor supports adding virtual ethernet devices at runtime
and crosvm doesn't, and it'll be important to be able to add
connections to new VMs as applications are started on a running
system.
The TODO about removing the device from cloud-hypervisor is going to
stay a TODO for now, because the solution is quite complicated: if we
tell cloud-hypervisor to remove the device from the VM using its API,
it'll still be trying to read from it for a short time after
returning, so we'll still get read errors in cloud-hypervisor after we
delete the TAP. I think the only good way to handle this will be to
use a non-persistent TAP device, so that it automatically gets cleaned
up by the kernel when cloud-hypervisor is done with it. But to do
that, cloud-hypervisor will have to be able to add TAPs from file
descriptors at runtime, which will probably be quite difficult to fit
into its HTTP API -- at least it's over a Unix socket.
Message-Id: <20210411115740.29615-17-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
Tested-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very barebones VM. It's purpose is just to be a
demonstration that other VMs can connect to the router and have their
packets reach the network. So all it does is infer its IPv4 address,
and the IPv4 address of the router, from the MAC address of its
virtual ethernet device, and configure the network interfaces and
routes appropriately.
vmID is an integer seed we can use to derive things for the VM like IP
and VSOCK addresses. I don't foresee this sitting around, because I
think it would make more sense for this to be assigned at runtime,
since starting arbitrary VMs at runtime is a goal. But we'll need
some way to ensure unique addresses.
Message-Id: <20210411115740.29615-16-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a VM that acts as a router. It handles talking to network
hardware, and other VMs can be connected to it by attaching virtual
ethernet devices.
It expects to get a physical ethernet device passed through to it
using VFIO. Wi-Fi should work too, but would need to be configured so
I've stuck with Ethernet for now. We use ConnMan[1] to configure
physical network interfaces, and it automatically takes care of DHCP
and stuff for us. I chose ConnMan over NetworkManager because it was
easier to get set up.
Virtual ethernet devices are identified by a specific OUI in their MAC
address. The NIC part of the MAC address is used to encode the last
three octets of the IPv4 address this VM should assign to the
interface. This way, the host can tell this VM what the address of
each virtual interface is without having to resort to a secondary
communication channel. The first octet will always be 100, as the
intention is to use the IPv4 shared address space (aka the CGNAT
space) for inter-VM networks to match the behaviour of Chromium OS[2].
Every networking client will be connected to a router VM with a /31,
where the low address is for the router, and the high address is for
the client. This way the host's job is as simple as possible -- it
just has to connect two TAPs together, without worrying about any
routing rules or anything -- that can all happen in the VM. This does
mean that the router has to have a virtio-net device for every client,
though. We may run into scaling limitations with this approach, in
which case we might have to revisit how this works on the host.
[1]: https://git.kernel.org/pub/scm/network/connman/connman.git/about/
[2]: https://chromium.googlesource.com/chromiumos/platform2/+/39e48f668a937d266638f3f7d31d3427a4966464/patchpanel/address_manager.cc#13
Message-Id: <20210411115740.29615-15-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
| |
There is no default rootfs any more, so we might as well repurpose the
blessed filename.
Message-Id: <20210411115740.29615-14-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the default rootfs, and creates a VM called "comp" that
runs all the Wayfire stuff the default rootfs did previously.
This is in a new namespace called sys-vms, which I have a very vague
intention of being a place to put VMs that run system services like a
Wayland compositor or hardware drivers. I don't think this will be
the final structure, but it's _a_ structure that supports more than
one VM, so it's an improvement over what we had before.
Message-Id: <20210411115740.29615-13-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
| |
At some point we'll want to make it so different VMs don't share this,
because only VMs that talk to network hardware will need connman.
But this'll do for now.
Message-Id: <20210411115740.29615-12-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
| |
This doesn't actually include dbus, just sets up its user, group and
configuration files. We'll need dbus for connman or NetworkManager.
Message-Id: <20210411115740.29615-11-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
| |
Needed by some programs. There's no persistance in /var/lib for
now (or anywhere else for that matter).
Message-Id: <20210411115740.29615-10-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows specifying s6-rc services (which can have dependencies,
and be taken up and down) in the same way that s6 services (which are
merely supervised) are declared.
This removes the spectrumcmd mechanism to clean up the boot process --
it could be reintroduced as an s6-rc service if required.
Message-Id: <20210411115740.29615-9-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
| |
We'll want service VMs to be able to call this themselves to construct
their own root filesystems.
Message-Id: <20210411115740.29615-8-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
| |
This way, linux_vm's configuration can be overridden further when it's
used, for example for VM-specific configuration.
Message-Id: <20210411115740.29615-6-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
| |
This patch (backported from Linux 5.5) fixes hotplugging with
cloud-hypervisor.
See <https://github.com/cloud-hypervisor/cloud-hypervisor/blob/8b7aafad16ee8a23d7178a7f7aa6d2c1ec509b5d/docs/hotplug.md#kernel-support>.
Message-Id: <20210411115740.29615-5-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
| |
The surrounding "set +e"/"set -e" was an earlier attempt to fix this,
but I mixed -e up with -u. But as Cole points out, it's nicer to use
parameter expansion here anyway.
Thanks-to: Cole Helbling <cole.e.helbling@outlook.com>
Message-Id: <20210316010910.ryhee36zgtoahdok@eve.qyliss.net>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Stage 1 was supposed to be able to take a list of PATH entries to
prepend to the default PATH, but it didn't do anything with them.
Now, it properly adds them to the PATH as early as possible during
boot.
This mechanism isn't currently used anywhere, but is very useful for
debugging.
Message-Id: <20210315135820.6375-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
| |
Programs assume this and it's useful to have.
Message-Id: <20200825164845.8850-1-hi@alyssa.is>
Message-Id: <20210315135540.4980-2-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
| |
This allows using 9p over virtio as well as over the network.
|
| |
|
|
|
|
|
|
|
| |
The "spectrumcmd" kernel parameter, which is used to pass custom
commands into the VM, uses base64 to get around the lack of solid
kernel command line quoting. By default, base64(1) wraps lines at 76
characters, so any command longer than 76 * 0.75 = 57 characters would
try to include a newline in the kernel command line, which doesn't
work.
|
| |
|
|
|
|
|
|
|
|
| |
This will be especially useful for testing crosvm cargo builds, which
only work at the moment with --disable-sandbox. Testing these builds
before was extremely annoying, but it can be done relatively easily as
follows:
cargo build
spectrum-vm -C target/debug/crosvm -- --disable-sandbox
|
| |
|
|
|
|
|
| |
wf-shell needs HOME to be set, which seems reasonable enough.
widgets_right is emptied because by default it contains a battery
meter and network status indicator, both of which deserve dbus.
|
| |
|
|
|
| |
We can abuse $@ to be a sort of array where we can put a number of
values, without losing quoting information or having to escape.
|
|
|
This is a modular version of what was previously start-vm.nix. It
introduces a program, spectrum-vm, that allows for customising the
crosvm, kernel, and rootfs paths. And, it can run a custom command
inside the VM! I think this is going to be a big improvement over
start-vm.nix.
|