All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 



WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: "limingwang (A)" <limingwang@huawei.com>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	Bin Meng <bin.meng@windriver.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Jiangyifei <jiangyifei@huawei.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	"Wanghaibin (D)" <wanghaibin.wang@huawei.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
> 



  reply	other threads:[~2021-10-18  6:43 UTC|newest]

Thread overview: 14+ 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-12  1:45 ` MingWang Li
2021-10-13 14:40 ` Bin Meng
2021-10-13 14:40   ` Bin Meng
2021-10-15  8:52   ` limingwang (A)
2021-10-15  8:52     ` limingwang (A)
2021-10-15  9:25     ` Bin Meng
2021-10-15  9:25       ` Bin Meng
2021-10-15 12:59       ` Igor Mammedov
2021-10-15 12:59         ` Igor Mammedov
2021-10-18  2:17         ` Bin Meng
2021-10-18  2:17           ` Bin Meng
2021-10-18  6:42           ` Igor Mammedov [this message]
2021-10-18  6:42             ` Igor Mammedov

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.