Hi Igor,
On Fri, Oct 15, 2021 at 8:59 PM Igor Mammedov <imamm...@redhat.com> wrote:
>
> On Fri, 15 Oct 2021 17:25:01 +0800
> Bin Meng <bmeng...@gmail.com> wrote:
>
> > On Fri, Oct 15, 2021 at 4:52 PM limingwang (A) <limingw...@huawei.com>
> > wrote:
> > >
> > >
> > > On Wed, Oct 13, 2021 at 22:41 PM Bin Meng <bin.m...@windriver.com> wrote:
> > > >
> > > > On Tue, Oct 12, 2021 at 9:46 AM MingWang Li <limingw...@huawei.com>
> > > > wrote:
> > > > >
> > > > > From: Mingwang Li <limingw...@huawei.com>
> > > > >
> > > > > When I start the VM with the following command:
> > > > > $ ./qemu-system-riscv64 -M virt,accel=kvm -m 4096M -cpu host
> > > > > -nographic \
> > > > > -name guest=riscv-guset \
> > > > > -smp 2 \
> > > > > -bios none \
> > > > > -kernel ./Image \
> > > > > -drive file=./guest.img,format=raw,id=hd0 \
> > > > > -device virtio-blk-device,drive=hd0 \
> > > > > -append "root=/dev/vda rw console=ttyS0 earlycon=sbi" \
> > > > > -object
> > > > memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \
> > > > > -numa node,memdev=mem -mem-prealloc \
> > > > > -chardev socket,id=char0,path=/mnt/vhost-net0 \
> > > > > -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
> > > > > -device
> > > > > virtio-net-pci,mac=52:54:00:00:00:01,netdev=mynet1,mrg_rxbuf=on,csum=o
> > > > > n,guest_csum=on,guest_ecn=on \
> > > > >
> > > > > Then, QEMU displays the following error information:
> > > > > qemu-system-riscv64: Failed initializing vhost-user memory map,
> > > > > consider using -object memory-backend-file share=on
> > > >
> > > > I see your command line parameters already contain "-object
> > > > memory-backend-file
> > > > share=on", so this error message is not accurate.
> > >
> > > QEMU uses this command to alloc fd in the
> > > "memory_region_init_ram_from_file" function
> > > and assigns the value of fd to mr->ram_block-fd. If the QEMU uses the
> > > default memory to
> > > initialize the system, the QEMU cannot obtain the fd in the
> > > "vhost_user_mem_section_filter"
> > > function when initializing the vhost-user. As a result, an error is
> > > reported in the "vhost_user_fill_set_mem_table_msg"
> > > function.
> > >
> > > Because of the above bug, even if "-object memory-backend-file share=on"
> > > is added to the command line,
> > > the QEMU still reports an error.
> >
> > Yes, what I meant is that QEMU should not report such inaccurate
> > messages because of some random codes elsewhere.
> >
> > With current message, it suggested user use "-object
> > memory-backend-file share=on" in the command line, but it is already
> > used. So this is a false alarm. The "bug" is somewhere else.
>
> bug is in using memory_region_init_ram(),
> which can't possibly handle vhost-user, and can't work as expected with
> '-numa node,memdev' options.
> Before main ram infrastructure was converted to memdev,
> one should have used memory_region_allocate_system_memory() for
> allocating main RAM, so numa usecase was broken from the start.
> Later it old API was dropped in favor of more flexible/generic
> MachineState::ram approach (see commits 68a86dc15ccd..f0530f14c7c35d).
Thanks for the detailed pointers.
I wonder if it is possible to make the error message to be clearer, so
instead of having
"qemu-system-riscv64: Failed initializing vhost-user memory map,
consider using -object memory-backend-file share=on"
can we do:
"qemu-system-riscv64: Failed initializing vhost-user memory map,
considering using MachineState::ram instead of manually initializing
RAM memory region."
which is more straightforward?
>
>
> Modulo commit message, patch looks good to me and does what
> every machine should do. (I though that I've converted every
> existing to generalized MachineState::ram but it looks like
> riscv was missed).
Indeed all riscv boards are doing the same thing.
>
> So we can model commit message after bd457782b3b0a,
> and also add that the patch fixes broken -numa node,memdev case,
> which never properly worked. It also opens possibility to
> use vhost-user/virtiosf with main RAM if main RAM is
> provided explicitly via machine.memory-backend option
> with shared memory backend.
>
> Btw: is there other riscv machines that allocate RAM directly?
> (if yes, those should be fixed as well, a patch per machine)
>
I will see if I can get some patches to fix other riscv machines.
Regards,
Bin
