hw/riscv/virt.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
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=on,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
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
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.
Signed-off-by: Mingwang Li <limingwang@huawei.com>
Signed-off-by: Yifei Jiang <jiangyifei@huawei.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
---
hw/riscv/virt.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index ec0cb69b8c..b3b431c847 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -771,7 +771,6 @@ static void virt_machine_init(MachineState *machine)
const MemMapEntry *memmap = virt_memmap;
RISCVVirtState *s = RISCV_VIRT_MACHINE(machine);
MemoryRegion *system_memory = get_system_memory();
- MemoryRegion *main_mem = g_new(MemoryRegion, 1);
MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
char *plic_hart_config, *soc_name;
target_ulong start_addr = memmap[VIRT_DRAM].base;
@@ -890,10 +889,8 @@ static void virt_machine_init(MachineState *machine)
}
/* register system main memory (actual RAM) */
- memory_region_init_ram(main_mem, NULL, "riscv_virt_board.ram",
- machine->ram_size, &error_fatal);
memory_region_add_subregion(system_memory, memmap[VIRT_DRAM].base,
- main_mem);
+ machine->ram);
/* create device tree */
create_fdt(s, memmap, machine->ram_size, machine->kernel_cmdline,
@@ -1032,6 +1029,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
mc->cpu_index_to_instance_props = riscv_numa_cpu_index_to_props;
mc->get_default_cpu_node_id = riscv_numa_get_default_cpu_node_id;
mc->numa_mem_supported = true;
+ mc->default_ram_id = "riscv_virt_board.ram";
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
--
2.19.1
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=on,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. Should this message be altered to mention things like what this patch does? > 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 > 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" ?? > Signed-off-by: Mingwang Li <limingwang@huawei.com> > Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com> > --- > hw/riscv/virt.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c > index ec0cb69b8c..b3b431c847 100644 > --- a/hw/riscv/virt.c > +++ b/hw/riscv/virt.c > @@ -771,7 +771,6 @@ static void virt_machine_init(MachineState *machine) > const MemMapEntry *memmap = virt_memmap; > RISCVVirtState *s = RISCV_VIRT_MACHINE(machine); > MemoryRegion *system_memory = get_system_memory(); > - MemoryRegion *main_mem = g_new(MemoryRegion, 1); > MemoryRegion *mask_rom = g_new(MemoryRegion, 1); > char *plic_hart_config, *soc_name; > target_ulong start_addr = memmap[VIRT_DRAM].base; > @@ -890,10 +889,8 @@ static void virt_machine_init(MachineState *machine) > } > > /* register system main memory (actual RAM) */ > - memory_region_init_ram(main_mem, NULL, "riscv_virt_board.ram", > - machine->ram_size, &error_fatal); > memory_region_add_subregion(system_memory, memmap[VIRT_DRAM].base, > - main_mem); > + machine->ram); > > /* create device tree */ > create_fdt(s, memmap, machine->ram_size, machine->kernel_cmdline, > @@ -1032,6 +1029,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data) > mc->cpu_index_to_instance_props = riscv_numa_cpu_index_to_props; > mc->get_default_cpu_node_id = riscv_numa_get_default_cpu_node_id; > mc->numa_mem_supported = true; > + mc->default_ram_id = "riscv_virt_board.ram"; > > machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE); > Regards, Bin
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. 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. > > Signed-off-by: Mingwang Li <limingwang@huawei.com> > > Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com> > > --- > > hw/riscv/virt.c | 6 ++---- > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index > > ec0cb69b8c..b3b431c847 100644 > > --- a/hw/riscv/virt.c > > +++ b/hw/riscv/virt.c > > @@ -771,7 +771,6 @@ static void virt_machine_init(MachineState *machine) > > const MemMapEntry *memmap = virt_memmap; > > RISCVVirtState *s = RISCV_VIRT_MACHINE(machine); > > MemoryRegion *system_memory = get_system_memory(); > > - MemoryRegion *main_mem = g_new(MemoryRegion, 1); > > MemoryRegion *mask_rom = g_new(MemoryRegion, 1); > > char *plic_hart_config, *soc_name; > > target_ulong start_addr = memmap[VIRT_DRAM].base; @@ -890,10 > > +889,8 @@ static void virt_machine_init(MachineState *machine) > > } > > > > /* register system main memory (actual RAM) */ > > - memory_region_init_ram(main_mem, NULL, "riscv_virt_board.ram", > > - machine->ram_size, &error_fatal); > > memory_region_add_subregion(system_memory, > memmap[VIRT_DRAM].base, > > - main_mem); > > + machine->ram); > > > > /* create device tree */ > > create_fdt(s, memmap, machine->ram_size, machine->kernel_cmdline, > > @@ -1032,6 +1029,7 @@ static void virt_machine_class_init(ObjectClass *oc, > void *data) > > mc->cpu_index_to_instance_props = riscv_numa_cpu_index_to_props; > > mc->get_default_cpu_node_id = riscv_numa_get_default_cpu_node_id; > > mc->numa_mem_supported = true; > > + mc->default_ram_id = "riscv_virt_board.ram"; > > > > machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE); > > > > Regards, > Bin
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. > 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
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 >
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? > > > 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
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 >
© 2016 - 2024 Red Hat, Inc.