runtime-rs: Enable static sandbox resource management on s390x

runtime-rs memory hotplug hard-codes the `pc-dimm` device driver, which
is an x86-only QEMU device model. On s390x, the `s390-ccw-virtio`
machine type does not support `pc-dimm` at all — the Go runtime handles
this by using `virtio-mem-ccw` instead (controlled by the
`enable_virtio_mem` config knob, defaulting to true on s390x).

runtime-rs has no virtio-mem support, so any attempt to dynamically
hotplug memory on s390x fails with:

  'pc-dimm' is not a valid device model name

This is a pre-existing limitation on main — it has never worked. It is
now visible because commit 45dfb6ff25 ("runtime-rs: Fix initial vCPU /
memory with static_sandbox_resource_mgmt") expanded runtime-rs test
coverage, causing k8s-memory.bats and k8s-oom.bats to actually exercise
this code path on s390x.

Let's enforce using static_sandbox_resources_mgmt also for s390x so the
VM is sized upfront at creation time, bypassing the broken dynamic
hotplug path entirely.

If someone decides to implement hotplug support for s390x, the work
would basically be an implemntation of virtio-mem-ccw support in the
runtime-rs QEMU backend (boot-time device creation, qom-set based
resize, and virtio-mem aware memory accounting), mirroring what the Go
runtime already does, but I'm not game for this (sorry).

Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor

src/runtime-rs/Makefile

@@ -384,6 +384,10 @@ ifneq (,$(QEMUCMD))
 ifeq ($(ARCH), s390x)
     VMROOTFSDRIVER_QEMU := virtio-blk-ccw
     DEFBLOCKSTORAGEDRIVER_QEMU := virtio-blk-ccw
+    # runtime-rs memory hotplug hard-codes pc-dimm, which is x86-only.
+    # s390x (s390-ccw-virtio) requires virtio-mem-ccw instead. Use static
+    # sandbox resource management to size the VM upfront and bypass hotplug.
+    DEFSTATICRESOURCEMGMT_QEMU := true
 else ifeq ($(ARCH), aarch64)
     # NVDIMM/virtio-pmem has issues on arm64 (cache coherency problems with DAX),
     # so we use virtio-blk-pci instead.