| Age | Commit message (Collapse) | Author |
|---|
|
What was named bus earlier is called transport in qemu and we should
name it the same way when exposing it.
|
|
Depending on the machine type, devices reside on different buses. For
most vms, we use the pci bus, but m68k uses the virtio ("device") bus.
Also if we were to use an x86 microvm, we'd also use virtio. This is
common to all devices and we can abstract it into a $BUS.
|
|
|
|
When kvm works, passing "max" will get us "host" as before. When it does
not, "host" doesn't work at all, but "max" will somewhat.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
|
|
Since recent qemu, a non-lpae kernel cannot boot a highmem-enabled
virtual machine. A typical failure is:
pci-host-generic 4010000000.pcie: can't claim ECAM area [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem 0x10000000-0x3efeffff]
Since the default kernel image is non-lpae, we disable highmem by
default.
Link: https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg01444.html
Thanks: Michael Tokarev <mjt@tls.msk.ru>
|
|
Reported-by: Johannes Schauer Marin Rodrigues <josch@mister-muffin.de>
|
|
|
|
|
|
|
|
When issuing multiple --sshport options, the last one should win.
Fixes: a2db07766257 ("debvm-run: add a --netopt option to customize the -netdev")
|
|
|
|
|
|
|
|
|
|
As with debvm-create, this option allows skipping default configuration
to let a user override things in their way.
Link: https://bugs.debian.org/1036918
|
|
Should be using stderr.
Fixes: 7d0b160531d6 ("debvm-run: replace shell process with qemu process")
|
|
This way we loose unnecessary detail such as libc, kernel and abi. For
one thing this simplifies the arm* match. For another, this makes us
stop think about arm64ilp32 or x32.
|
|
Fixes: 1c98a5b3b36f ("bin/debvm-run: qemu (>> 1:8.0) provides symlinks for qemu-system-${debarch} as well as qemu-system-any")
|
|
as well as qemu-system-any
|
|
qemu makes heavy use of fd passing, so we better avoid user-passed fds.
|
|
We need the intermediate shell process to clean the temporary files with
the kernel and the initrd - unless we delete them before running qemu.
This method should help with killing a qemu e.g. using a timeout.
|
|
|
|
Unlike qemu's -append, it has append semantics both to repeated use and
to internal defaults.
|
|
I really should have tested this part, but CI did.
Fixes: 954ba600ffb7 ("debvm-run: massively speed up tcg emulation of arm cpus")
|
|
pauth emulation is very intensive on the CPU and thus there is a
non-cryptographic alternative that provides a speedup of 3 to 4.
https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html#tcg-vcpu-features
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Emanuele Rocca <ema@debian.org>
Tested-by: Emanuele Rocca <ema@debian.org>
Closes: #1033643
|
|
|
|
We now extend /etc/profile to invoke setterm -resize when detecting an
interactive login on a serial console. This should fix 90% of wrongly
sized serial consoles.
|
|
Reported-by: Fabian Gruenbichler
|
|
These clearly benefit the amd64 case as well. Experience with the
virtio gpu is not as clear cut as it may crash qemu.
|
|
Reported-by: Arnd Bergmann <arnd@arndb.de>
|
|
|
|
Reported-by: Gioele Barabucci <gioele@svario.it>
Closes: #1030255
|
|
|
|
install and use multiarch kernels for sibling architectures
See merge request helmutg/debvm!28
|
|
We already pass it in the kvm case where it should become host and all
should be fine. However in the non-kvm case, the default gic can only
support 8 cores. If we want to go beyond that, we need a higher
gic-version. We couldn't measure a performance difference between max
and unset, so we'll just always pass max.
Thanks: Arnd Bergmann <arnd@arndb.de>
Thanks: Johannes Schauer Marin Rodrigues <josch@debian.org>
|
|
Reported-by: Arnd Bergmann <arnd@arndb.de>
|
|
In a multiarch setting, VMARCH shall describe the contained userland and
KERNELARCH shall describe the architecture of the contained kernel.
|
|
Fixes: 66b9374cc19c ("debvm-run: extract kernel image before inspecting it")
|
|
elf-arch may report armel and armhf as arm.
|
|
Reported-by: Arnd Bergmann <arnd@arndb.de>
|
|
We completely treat all 32bit arm as armhf now. Booting the rpi kernel
installed by debvm-create for armel will not work at all. The only sane
way to boot armel is to enable a multiarch kernel.
Refine the VMARCH guess from /bin/true using the file output for the
kernel image for the common cases of i386+amd64 and armel/armhf+arm64.
|
|
|
|
|
|
This was never tried, but autopkgtests indicate that smp limits also
apply to the native case.
|
|
|
|
It's not as simple as disabling the rng when pci is unavailable. For
m68k, we can select -machine virt and then we can have a
virtio-rng-device. Thus make that part configurable.
|
|
While the host version only works on kvm, max means the same and also
works on tcg.
Signed-off-by: Johannes Schauer Marin Rodrigues <josch@debian.org>
Signed-off-by: Helmut Grohne <helmut@subdivi.de>
|
|
Fixes: aee1eb3d1c28 ("debvm-run: no need for true randomness -- use /dev/urandom to be faster")
|
|
|
|
Now that we pass accel=kvm:tcg, there is no difference anymore.
|
