qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is


From: Igor Mammedov
Subject: Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
Date: Fri, 15 Oct 2021 14:59:22 +0200

On Fri, 15 Oct 2021 17:25:01 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:

> On Fri, Oct 15, 2021 at 4:52 PM limingwang (A) <limingwang@huawei.com> wrote:
> >
> >
> > On Wed, Oct 13, 2021 at 22:41 PM Bin Meng <bin.meng@windriver.com> wrote:  
> > >
> > > On Tue, Oct 12, 2021 at 9:46 AM MingWang Li <limingwang@huawei.com> 
> > > wrote:  
> > > >
> > > > From: Mingwang Li <limingwang@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).


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).

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)


> > This patch can solve this bug.
> >  
> > > Should this message be altered to mention things like what this patch 
> > > does?  
> >
> > Thanks, I will rewrite the message in next version.  
> > >  
> > > > qemu-system-riscv64: vhost_set_mem_table failed: Interrupted system
> > > > call (4)
> > > > qemu-system-riscv64: unable to start vhost net: 4: falling back on
> > > > userspace virtio
> > > >
> > > > Note that, before starting the kvm-acceled QEMU VM, following
> > > > temporarily unaccepted QEMU patches should be used:
> > > > https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg02516.html
> > > >
> > > > This error was made bacause default main_mem is used to be registered  
> > >
> > > typo: because
> > >  
> > Thanks.
> >  
> > > > as the system memory, other memory cannot be initialized. Therefore,
> > > > the system memory should be initialized to the machine->ram, which
> > > > consists of the default main_mem and other possible memory required by
> > > > applications, such as shared hugepage memory in DPDK.
> > > > Also, the mc->defaul_ram_id should be set to the default main_mem,
> > > > such as "riscv_virt_board.ram" for the virt machine.
> > > >  
> > >
> > > How about changing the commit title to: "Use machine->ram as the system
> > > memory" ??
> > >  
> >
> > I think it is just a bugfix.
> >  
> 
> But the current codes run perfectly okay so far. This patch adds an
> additional use case for the KVM scenario where current codes cannot
> handle.
> 
> Regards,
> Bin
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]