| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Fixes: 715033d ("lib/nixpkgs.default.nix: update")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
| |
128M was not enough to even get to init on aarch64. We can probably
optimise the kernel at some point, but I think that's something to do
once things are further along.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This didn't originally go to a file, because I still had to use the
serial console interactively for debugging sometimes. Now that things
have settled a bit and the serial console is write-only, having serial
go to a pty is just needlessly inconvenient.
I've updated the crosvm target to put its logs in the same place, so
the path to serial logs only has to be learned once.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
| |
This removes the need to do anything as root to make run with
VMM=cloud-hypervisor or VMM=crosvm.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5f556f806a70f3787fe725254ccf3d245bd5bebc.
This turns out to not really be workable on aarch64 at the moment,
without giving things up — both crosvm and Cloud Hypervisor inject
earlycon parameters onto the command line, which overrides the
built-in command line. We could use CONFIG_CMDLINE_FORCE, but then we
wouldn't know which serial console to use, because crosvm and Cloud
Hypervisor both use different ones.
There's discussion about making it possible to have the bootloader
command line append to the built-in command line, but it's moving
extremely slowly, so we can't count on it any time soon.
Link: https://lore.kernel.org/lkml/20231110013817.2378507-1-danielwa@cisco.com/
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
| |
The kernel command line is policy, and shouldn't be hardcoded in
start-vm. We could add a mechanism for customising it at some
point (this would probably be helpful for custom VMs), but we don't
need that at the moment, since for our built-in VMs we're using
custom-configured kernels anyway.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
| |
At the moment, only QEMU creates the GDB socket, so this only works
with QEMU. cloud-hypervisor isn't built with GDB support, and it
doesn't work very well anyway.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
| |
This is useful because it allows comparing how our patched
cloud-hypervisor behaves against crosvm's implementation.
Signed-off-by: Alyssa Ross <alyssa.ross@unikie.com>
Co-authored-by: Alyssa Ross <hi@alyssa.is>
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20230721180015.597099-5-hi@alyssa.is>
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
| |
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
| |
Both places this was used, there was a KERNEL variable with the same
value. On other architectures, we might not even use vmlinux, so
keeping KERNEL makes more sense.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
| |
cloud-hypervisor has changed the CLI, so we have to update every place
we invoke it.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
| |
This way, we don't have to worry about them confusing Nix, or the
lockfiles ending up in git.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
| |
Otherwise, cloud-hypervisor won't be able to bind to the path and will
fail to start.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our image Makefiles are either used for interactive development in a
nix-shell, or as part of a Nix build of Spectrum. In neither of these
cases is the two step "make; make install" process useful like it is
for packages, because one image from Spectrum somewhere on the
development system isn't something it ever makes sense to do.
By removing the separation between building and installing, and
creating the final output directly in its destination, we can save
some copies of very large files, which should save seconds in each
build, even for the smaller components.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can simplify our Makefiles a bit by moving some things into a
library file. So far, I've done this for non-component-specific
macros, and inference rules.
Some tar2ext4 rules used a temporary file for the tar2ext4 invocation,
and then moved the file into place when it was done, to prevent a
half-built image sticking around if tar2ext4 died. According to
POSIX, make should clean up any targets that didn't finish building if
it's interrupted, so we should only end up with a half-built image if
tar2ext4 crashes, e.g. due to running out of disk space. I think we
should just ignore that possibility, since otherwise we'd have to
write annoying make rules using temporary file names for every target,
and if it does happen recovery is just a make clean away.
With this, I've also made a small reorganisation. I got rid of the
"nix" directory and created a "lib" directory, where I put
eval-config.nix and the new common.mk file, since both are library
code. checks.nix isn't really a library though, so I moved it into
the "release" directory, since the only reference to it is in
release.nix.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
| |
This was getting very repetitive. Having a single copy of the sources
shared between builds will also save on store space, and means we
don't need to support overriding the path to the scripts directory in
Makefiles.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow booting reliably from multiple disk images, without
relying on order or requiring udev in an initramfs. (The only
deterministic way of doing boot order on Linux without special
userspace support is to set "root" on the kernel command line to
either a GPT partition UUID or label.)
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20221009114036.463071-4-hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step to being able to do things like having a static
base image for an application VM, and another image containing the
application to run.
When we actually use multiple images we'll need to change how we boot
so we know the kernel is booting from the right image — probably by
PARTUUID or PARTLABEL — because we can't guarantee how the kernel
orders disks inside the VM.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20221009114036.463071-2-hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't a license change — the code was always available under
potential future EUPL versions because of this language in the EUPL:
> Copyleft clause: If the Licensee distributes or communicates copies of the
> Original Works or Derivative Works, this Distribution or Communication will be
> done under the terms of this Licence or of a later version of this Licence
> unless the Original Work is expressly distributed only under this version of the
> Licence — for example by communicating ‘EUPL v. 1.2 only’. The Licensee
> (becoming Licensor) cannot offer or impose any additional terms or conditions on
> the Work or Derivative Work that alter or restrict the terms of the Licence.
But now that reuse 1.0.0 is out, and supports SPDX '+' expressions, we
can express this more clearly in SPDX.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
| |
When I set the virtio console to go to a new PTY by default, it was
because I was working on / testing patches for terminal emulators to
get them to attach to PTYs and send resize events. Now that I'm not
doing that so much, let's show the console intended for VM output by
default, rather than requiring running another process to connect to
it.
|
| |
|
|
|
|
| |
This is preparatory work before a switch to s6-linux-init.
|
|
|
|
|
| |
We don't need to create the etc/service directory, because we're
already including etc/service/getty-hvc0.
|
|
|
|
|
|
|
|
| |
It apparently doesn't on Ubuntu, and this way we also don't have to
hack around it being missing in the Nix sandbox.
Reported-by: Ville Ilvonen <ville.ilvonen@unikie.com>
Message-Id: <20220406082038.4012718-1-hi@alyssa.is>
|
| |
|
|
|
|
|
|
|
|
| |
This way, we don't allow arbitrary code from the ext partition to run
on the host system, which gives us better integrity guarantees when
paired with Secure Boot. This new scheme also makes it easy to
introspect VMs, since they're defined using a very limited
configuration language.
|
|
|