Re: [PATCH][RESEND v5 3/3] Add a Hyper-V Dynamic Memory Protocol driver (hv-balloon)

[Maciej S. Szmigiero]

On 22.06.2023 13:01, David Hildenbrand wrote:
> [...]
>
> > > > > We'd use a memory region container as device memory region (like [1]) and would 
> > > > > have to handle the !memdev case (I can help with that). > Into that, you can 
> > > > > map the RAM memory region on demand (and eventually even using multiple slots like 
> > > > > [1]).
> > > > >
> > > > > (2) Use a single virtual DIMM and (un)plug that on demand. Let the machine code 
> > > > > handle (un)plugging of the device.
> > > > >
> > > > >
> > > > > (1) feels cleanest to me, although it will require a bit more work.
> > > >
> > > > I also think approach (1) makes more sense as it avoids memslot metadata
> > > > overhead for not-yet-hot-added parts of the memory backing device.
> > > >
> > > > Not sure what you mean that the !memdev case would be problematic in this
> > > > case - it is working in the current driver shape so why would adding
> > > > potential memory subregions (used in the memdev case) change that?
> > >
> > > I'm thinking about the case where you have a hv-balloon device without a memdev.
> > >
> > > Without -m X,maxmem=y we don't currently expect to have memory devices around
> > > (and especially them getting (un)plugged. But why should we "force" to set the
> > > "maxmem" option
> >
> > I guess it's only a small change to QEMU to allow having hv-balloon
> > device (without a memdev) even in the case where there's no "maxmem"
> > option given on the QEMU command line.
> >
> > > I hope I'll find some time soonish to prototype what I have in mind, to see
> > > if it could be made working.
> >
> > Okay, so I'll wait for your prototype before commencing further work on
> > the next version of this driver.
>
> About to have something simplistic running -- I think. Want to test with a 
> Linux VM, but I don't seem to get it working (also without my changes).
>
>
> #!/bin/bash
>
> build/qemu-system-x86_64 \
>      --enable-kvm \
>      -m 4G,maxmem=36G \
>      -cpu host,hv-syndbg=on,hv-synic,hv-relaxed,hv-vpindex \
>      -smp 16 \
>      -nographic \
>      -nodefaults \
>      -net nic -net user \
>      -chardev stdio,nosignal,id=serial \
>      -hda Fedora-Cloud-Base-37-1.7.x86_64.qcow2 \
>      -cdrom /home/dhildenb/git/cloud-init/cloud-init.iso \
>      -device isa-serial,chardev=serial \
>      -chardev socket,id=monitor,path=/var/tmp/mon_src,server,nowait \
>      -mon chardev=monitor,mode=readline \
>      -device vmbus-bridge \
>      -object memory-backend-ram,size=2G,id=mem0 \
>      -device hv-balloon,id=hv1,memdev=mem0
>
>
>
> [root@vm-0 ~]# uname -r
> 6.3.5-100.fc37.x86_64
> [root@vm-0 ~]# modprobe hv_balloon
> modprobe: ERROR: could not insert 'hv_balloon': No such device
>
>
> Any magic flag I am missing? Or is there something preventing this to work with 
> Linux VMs?

Haven't tested the driver with Linux guests in a long time (as it is
targeting Windows), but I think you need to disable KVM PV interface for
the Hyper-V one to be detected by Linux.

Something like adding "kvm=off" to "-cpu" and seeing in the dmesg whether
the detected hypervisor is now Hyper-V.

Also, you need to disable S4 in the guest for hot-add capability to work
(I'm adding "-global ICH9-LPC.disable_s4=1" with q35 machine for this).

Would also suggest adding "--trace 'hv_balloon_*' --trace 'memory_device_*'"
to QEMU command line to see what's happening.

Thanks,
Maciej