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: Fri, 15 Oct 2021 14:59:22 +0200	[thread overview]
Message-ID: <20211015145922.5a82e31a@redhat.com> (raw)
In-Reply-To: <CAEUhbmVD1jyvGJrQLSZLJYfaz6E-m0b9SZA+DQA2YYK70oL7Lg@mail.gmail.com>

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
> 



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: Fri, 15 Oct 2021 14:59:22 +0200	[thread overview]
Message-ID: <20211015145922.5a82e31a@redhat.com> (raw)
In-Reply-To: <CAEUhbmVD1jyvGJrQLSZLJYfaz6E-m0b9SZA+DQA2YYK70oL7Lg@mail.gmail.com>

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	other threads:[~2021-10-15 13:02 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 [this message]
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
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=20211015145922.5a82e31a@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.