* [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-12 1:45 ` MingWang Li
0 siblings, 0 replies; 14+ messages in thread
From: MingWang Li @ 2021-10-12 1:45 UTC (permalink / raw)
To: palmer, alistair.francis, bin.meng
Cc: qemu-riscv, Mingwang Li, qemu-devel, jiangyifei, wanghaibin.wang,
fanliang, wu.wubin
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-12 1:45 ` MingWang Li
0 siblings, 0 replies; 14+ messages in thread
From: MingWang Li @ 2021-10-12 1:45 UTC (permalink / raw)
To: palmer, alistair.francis, bin.meng
Cc: qemu-riscv, qemu-devel, wanghaibin.wang, jiangyifei, fanliang,
wu.wubin, Mingwang Li
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
2021-10-12 1:45 ` MingWang Li
@ 2021-10-13 14:40 ` Bin Meng
-1 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-10-13 14:40 UTC (permalink / raw)
To: MingWang Li
Cc: open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Alistair Francis, wu.wubin, wanghaibin.wang, Palmer Dabbelt,
fanliang, jiangyifei
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-13 14:40 ` Bin Meng
0 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-10-13 14:40 UTC (permalink / raw)
To: MingWang Li
Cc: Palmer Dabbelt, Alistair Francis, Bin Meng, open list:RISC-V,
qemu-devel@nongnu.org Developers, jiangyifei, wanghaibin.wang,
fanliang, wu.wubin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
2021-10-13 14:40 ` Bin Meng
@ 2021-10-15 8:52 ` limingwang (A)
-1 siblings, 0 replies; 14+ messages in thread
From: limingwang (A) @ 2021-10-15 8:52 UTC (permalink / raw)
To: Bin Meng
Cc: open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Jiangyifei, Alistair Francis, Wanghaibin (D), Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-15 8:52 ` limingwang (A)
0 siblings, 0 replies; 14+ messages in thread
From: limingwang (A) @ 2021-10-15 8:52 UTC (permalink / raw)
To: Bin Meng
Cc: open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Alistair Francis, Wubin (H), Wanghaibin (D),
Palmer Dabbelt, Fanliang (EulerOS),
Jiangyifei
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
2021-10-15 8:52 ` limingwang (A)
@ 2021-10-15 9:25 ` Bin Meng
-1 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-10-15 9:25 UTC (permalink / raw)
To: limingwang (A)
Cc: open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Jiangyifei, Alistair Francis, Wanghaibin (D), Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-15 9:25 ` Bin Meng
0 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-10-15 9:25 UTC (permalink / raw)
To: limingwang (A)
Cc: open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Alistair Francis, Wubin (H), Wanghaibin (D),
Palmer Dabbelt, Fanliang (EulerOS),
Jiangyifei
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
2021-10-15 9:25 ` Bin Meng
@ 2021-10-15 12:59 ` Igor Mammedov
-1 siblings, 0 replies; 14+ messages in thread
From: Igor Mammedov @ 2021-10-15 12:59 UTC (permalink / raw)
To: Bin Meng
Cc: open list:RISC-V, limingwang (A),
Bin Meng, qemu-devel@nongnu.org Developers, Jiangyifei,
Wanghaibin (D), Alistair Francis, Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-15 12:59 ` Igor Mammedov
0 siblings, 0 replies; 14+ messages in thread
From: Igor Mammedov @ 2021-10-15 12:59 UTC (permalink / raw)
To: Bin Meng
Cc: limingwang (A),
open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Jiangyifei, Alistair Francis, Wanghaibin (D), Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
2021-10-15 12:59 ` Igor Mammedov
@ 2021-10-18 2:17 ` Bin Meng
-1 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-10-18 2:17 UTC (permalink / raw)
To: Igor Mammedov
Cc: open list:RISC-V, limingwang (A),
Bin Meng, qemu-devel@nongnu.org Developers, Jiangyifei,
Wanghaibin (D), Alistair Francis, Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-18 2:17 ` Bin Meng
0 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-10-18 2:17 UTC (permalink / raw)
To: Igor Mammedov
Cc: limingwang (A),
open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Jiangyifei, Alistair Francis, Wanghaibin (D), Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
2021-10-18 2:17 ` Bin Meng
@ 2021-10-18 6:42 ` Igor Mammedov
-1 siblings, 0 replies; 14+ messages in thread
From: Igor Mammedov @ 2021-10-18 6:42 UTC (permalink / raw)
To: Bin Meng
Cc: open list:RISC-V, limingwang (A),
Bin Meng, qemu-devel@nongnu.org Developers, Jiangyifei,
Wanghaibin (D), Alistair Francis, Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] hw/riscv: virt: bugfix the memory-backend-file command is invalid
@ 2021-10-18 6:42 ` Igor Mammedov
0 siblings, 0 replies; 14+ messages in thread
From: Igor Mammedov @ 2021-10-18 6:42 UTC (permalink / raw)
To: Bin Meng
Cc: limingwang (A),
open list:RISC-V, Bin Meng, qemu-devel@nongnu.org Developers,
Jiangyifei, Alistair Francis, Wanghaibin (D), Fanliang (EulerOS),
Palmer Dabbelt, Wubin (H)
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-10-18 6:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2021-10-18 6:42 ` Igor Mammedov
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.