From: Igor Mammedov <imammedo@redhat.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
"limingwang \(A\)" <limingwang@huawei.com>,
Bin Meng <bin.meng@windriver.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Jiangyifei <jiangyifei@huawei.com>,
"Wanghaibin \(D\)" <wanghaibin.wang@huawei.com>,
Alistair Francis <alistair.francis@wdc.com>,
"Fanliang \(EulerOS\)" <fanliang@huawei.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
"Wubin \(H\)" <wu.wubin@huawei.com>
Subject: Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
Date: Mon, 18 Oct 2021 08:42:21 +0200 [thread overview]
Message-ID: <20211018084221.622ae711@redhat.com> (raw)
In-Reply-To: <CAEUhbmVTs109MLog+wjnayJY++SvEPhuCKcG3xXotqySkpGAaA@mail.gmail.com>
On Mon, 18 Oct 2021 10:17:45 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Igor,
>
> On Fri, Oct 15, 2021 at 8:59 PM Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > 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).
>
> 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?
It would only make sense in context of this thread and
give a hint to a developer how to fix bug in machine code
but won't give a clue to the end user what's wrong with
configuration.
Maybe following would be better:
"Failed initializing vhost-user memory map, vhost requires shared system memory."
"See 'System Emulation::Device Emulation::Emulated Devices::vhost-user back ends'
chapter in QEMU manual."
the chapter gives an example how to correctly configure vhost-user
(albeit using old style)
> >
> >
> > 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
>
prev parent reply other threads:[~2021-10-18 6:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 1:45 [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid MingWang Li
2021-10-13 14:40 ` Bin Meng
2021-10-15 8:52 ` limingwang (A)
2021-10-15 9:25 ` Bin Meng
2021-10-15 12:59 ` Igor Mammedov
2021-10-18 2:17 ` Bin Meng
2021-10-18 6:42 ` Igor Mammedov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211018084221.622ae711@redhat.com \
--to=imammedo@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=bmeng.cn@gmail.com \
--cc=fanliang@huawei.com \
--cc=jiangyifei@huawei.com \
--cc=limingwang@huawei.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=wanghaibin.wang@huawei.com \
--cc=wu.wubin@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).