| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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 will be important for host-based networking in Spectrum.
Message-Id: <20210411115740.29615-7-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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By cherry-picking this for Spectrum, we're actually building mdevd in
an unsupported configuration, because it is documented as requiring a
newer version of skalibs than we have. But it seems to work fine, and
I think we'll be updating soon anyway.
(cherry picked from commit 441f0c894aae2846190724828054e4bad9284579)
Message-Id: <20210411115740.29615-4-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't think there's any reason to have a seperate kernel variant
because of this, with all the maintenance burden that imposes. Debian
and Fedora both enable all these options on their normal kernels.
Alias the Linux Xen attributes, so this change should be seemless for
people who were using the Xen kernels up to now.
All the Xen options are marked as optional anyway, so it should be
fine to try to enable them on non-x86 platforms as well.
Cherry-picking this for Spectrum because PVH is cloud-hypervisor's
preferred boot entry point on x86, and it'll complain if our kernel
doesn't support it.
Fixes: https://github.com/NixOS/nixpkgs/issues/115182
(cherry picked from commit 5f24024de6f6405bb9ae9fc4c960b3fba84613b9)
Message-Id: <20210411115740.29615-2-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>
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |\
| | |
| | | |
rfkill: remove
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
rfkill was subsumed by util-linux in 2017 [1], and the upstream has not
been updated in over 5 years [2]. This package shadows the rfkill from
util-linux, so it can be completely removed with no breaking changes,
because util-linux is in the base package set in nixos/system-path.
[1] https://github.com/karelzak/util-linux/commit/d17fb726b562a69e8f174d46fa6cf794abc129cd
[2] https://git.sipsolutions.net/rfkill.git/log/
|
| | | | |
|
| | |\| |
|
| | | | |
|
| | |\| |
|
| | | | |
|
| | | |\
| | | |
| | | | |
iputils: 20190709 -> 20200821
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|