Is launching qemu with -cpu = "something else than host" possible ?

[aphecetche]

The use case is to be able to see, from within the VM, the architecture as x86_64_v3 and not just x86_64.

[jandubois]

This is not supported by Rancher Desktop. What would be the benefit of doing this?

[aphecetche]

@jandubois well, for my specific use case, I'm using the Spack package manager, which builds mainly from source (which is very flexible but of course very slow as well) but can also use some build caches. But to get the relevant binaries from the build caches one crucial point is the (micro)architecture that must match that of the build machine.

And on most (?) modern Intel machines that microarchitecture is x86_64_v3 (and even v4), not the baseline x86_64. If I understand correctly the qemu doc it seems qemu is indeed able to emulate those different versions. And some programs (Spack being one of those) can make (good) use of that.

[jandubois]

Ok, so this is not in any way supported, and if things break, you get to keep all the pieces:

I've been able to override the CPU for QEMU when I start Rancher Desktop from the shell (and assuming macOS; you don't specify which platform you are on):

QEMU_SYSTEM_X86_64="\"/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/lima/bin/qemu-system-x86_64\" -cpu Haswell-v4" "/Applications/Rancher Desktop.app/Contents/MacOS/Rancher Desktop"

Spaces and quoting must be exactly as shown above. This will let Rancher Desktop start QEMU with -cpu Haswell-v4 instead of the usual -cpu host,-pdpe1gb.

I don't know how your tool checks the microarchitecture though; lscpu doesn't seem to report it:

lima-rancher-desktop:~# lscpu
Architecture:           x86_64
  CPU op-mode(s):       32-bit, 64-bit
  Address sizes:        40 bits physical, 48 bits virtual
  Byte Order:           Little Endian
CPU(s):                 2
  On-line CPU(s) list:  0,1
Vendor ID:              GenuineIntel
  BIOS Vendor ID:       QEMU
  Model name:           Intel Core Processor (Haswell, no TSX, IBRS)
    BIOS Model name:    pc-q35-7.1  CPU @ 2.0GHz
    BIOS CPU family:    1
    CPU family:         6
    Model:              60
    Thread(s) per core: 1
    Core(s) per socket: 2
    Socket(s):          1
    Stepping:           1
    BogoMIPS:           8015.63
    Flags:              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_t
                        sc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor l
                        ahf_lm abm pti fsgsbase bmi1 avx2 smep bmi2 erms xsaveopt arat

And I would expect that -cpu host would already expose the architecture of the host chip. So if your host architecture doesn't actually support the microarchitecture that you are looking for, then the whole CPU will need to be emulated, which will give you a tremendous slowdown.

Anyways, feel free to experiment, and I hope this helps, but it is not something we will expose to the regular Rancher Desktop user.

[aphecetche]

Thanks for the tip. Yes, I'm on a macOS (M1) machine, with Rancher Desktop 1.12.0. Sorry, I should have mentioned that of course.

I'm trying it but I realize that when doing rdctl shell and doing lscpu I get :

lima-rancher-desktop:/Users/laurent$ lscpu
/bin/ash: lscpu: not found

I get this whether or not I start with the QEMU_SYSTEM_X86_64 env "trick" by the way. Is that to be expected ?

~$ rdctl version
rdctl client version: 1.1.0, targeting server version: v1

[jandubois]

You need to install the util-linux package for that:

rdctl shell sudo apk add util-linux

The package will be cached, but you need to reinstall it after each VM restart (because it runs from an ISO image).

I'm on a macOS (M1) machine

Oh, in that case you are not using the host CPU anyways, which would be aarch64 instead of x86_64. So overriding the CPU for the VM will no have any effect for you:

lima-rancher-desktop:~# lscpu
Architecture:            aarch64
  CPU op-mode(s):        64-bit
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               Apple
  BIOS Vendor ID:        Apple Inc.
...

When you are running x86_64 containers inside an aarch64 VM, then the processes are emulated by a binfmt_misc handler:

lima-rancher-desktop:~# cat /proc/sys/fs/binfmt_misc/qemu-x86_64
enabled
interpreter /usr/bin/qemu-x86_64
flags: POCF
offset 0
magic 7f454c4602010100000000000000000002003e00
mask fffffffffffefe00fffffffffffffffffeffffff

Using it shows somewhat curious information:

❯ docker run -it --platform linux/x86_64 alpine sh -c 'apk add util-linux; uname -a; lscpu'
[...]
Linux f310ead48440 6.1.64-0-virt #1-Alpine SMP Wed, 29 Nov 2023 18:56:40 +0000 x86_64 Linux
Architecture:           x86_64
  CPU op-mode(s):       32-bit
  Byte Order:           Little Endian
CPU(s):                 2
  On-line CPU(s) list:  0,1
Vendor ID:              Apple
[...]

It is both surprising that it reports only the 32-bit op-mode, and it claims the CPU Vendor is Apple. I suspect there is some leakage of the host information happening.

Anyways, I don't have time to further go down this rabbit-hole; you will need to do your own research.

Just in case you are not aware, on Apple Silicon you can also use VZ emulation and Rosetta to run x86_64 containers: https://docs.rancherdesktop.io/ui/preferences/virtual-machine/emulation#vz. Maybe this will give you the right (micro)architecture automatically. You probably should select virtiofs as the volume mounting mode if you switch to VZ.

Now the command above gave me the same output with Rosetta, so not sure what to make of it. But maybe it provides the right information to the tools you are using.

[aphecetche]

Thanks a lot for the help. Regards,