Re: [PATCH v2 1/3] misc: use QEMU_IS_ALIGNED
On Fri, Jan 3, 2020 at 11:43 AM Philippe Mathieu-Daudé
wrote:
>
> On 1/3/20 8:39 AM, Marc-André Lureau wrote:
> > Signed-off-by: Marc-André Lureau
> > ---
> > exec.c| 4 ++--
> > roms/SLOF | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/exec.c b/exec.c
> > index d4b769d0d4..1feda49ca1 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -3895,7 +3895,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t
> > start, size_t length)
> >
> > uint8_t *host_startaddr = rb->host + start;
> >
> > -if ((uintptr_t)host_startaddr & (rb->page_size - 1)) {
> > +if (!QEMU_PTR_IS_ALIGNED(host_startaddr, rb->page_size)) {
> > error_report("ram_block_discard_range: Unaligned start address:
> > %p",
> >host_startaddr);
> > goto err;
> > @@ -3903,7 +3903,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t
> > start, size_t length)
> >
> > if ((start + length) <= rb->used_length) {
> > bool need_madvise, need_fallocate;
> > -if (length & (rb->page_size - 1)) {
> > +if (!QEMU_IS_ALIGNED(length, rb->page_size)) {
> > error_report("ram_block_discard_range: Unaligned length: %zx",
> >length);
> > goto err;
> > diff --git a/roms/SLOF b/roms/SLOF
> > index 9546892a80..8ebf2f55e1 16
> > --- a/roms/SLOF
> > +++ b/roms/SLOF
> > @@ -1 +1 @@
> > -Subproject commit 9546892a80d5a4c73deea6719de46372f007f4a6
> > +Subproject commit 8ebf2f55e1ba1492b942ba4b682160e644fc0f98
>
> Without the SLOF submodule update:
> Reviewed-by: Philippe Mathieu-Daudé
oops, I think I should submit a git config proposal, for git commit -a
to exclude submodules, or warn loudly...
Or perhaps I should stop using -a.
[RFC PATCH qemu] spapr: Kill SLOF
The Petitboot bootloader is way more advanced than SLOF is ever going to
be as Petitboot comes with the full-featured Linux kernel with all
the drivers, and initramdisk with quite user friendly interface.
The problem with ditching SLOF is that an unmodified pseries kernel can
either start via:
1. kexec, this requires presence of RTAS and skips
ibm,client-architecture-support entirely;
2. normal boot, this heavily relies on the OF1275 client interface to
fetch the device tree and do early setup (claim memory).
This adds a new bios-less mode to the pseries machine: "bios=on|off".
When enabled, QEMU does not load SLOF and jumps to the kernel from
"-kernel".
The client interface is implemented exactly as RTAS - a 20 bytes blob,
right next after the RTAS blob. The entry point is passed to the kernel
via GPR5.
This implements a handful of client interface methods just to get going.
In particular, this implements the device tree fetching,
ibm,client-architecture-support and instantiate-rtas.
This does not implement changing properties, i.e. "setprop".
This assigns "phandles" to device tree nodes as there is no more SLOF
and OF nodes addresses of which served as phandle values.
This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
phandles are regenerated at every FDT rebuild.
When bios=off, this adds "/chosen" every time QEMU builds a tree.
This implements "claim" which the client (Linux) uses for memory
allocation; this is also used by QEMU for claiming kernel/initrd images
and the initial stack.
While at this, add a "kernel-addr" machine parameter to allow moving
the kernel in memory. This is useful for debugging if the kernel is
loaded at @0, although not necessary.
This does not implement instances properly but in order to boot a VM,
we only really need a stdout instance and the "/" instance for
"call-method", we fake these.
Sadly Petitboot still does not boot the selected system:
"Must be root to change default boot option" (the message is likely
to be misleading), debugging.
The test command line:
qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline \
-nographic \
-vga none \
-kernel vmldbg \
-machine pseries,bios=off \
-m 4G \
-enable-kvm \
-initrd pb/rootfs.cpio.xz \
img/u1804-64le.qcow2 \
-snapshot \
-smp 8,threads=8 \
-L /home/aik/t/qemu-ppc64-bios/ \
-trace events=qemu_trace_events \
-d guest_errors \
-chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
-mon chardev=SOCKET0,mode=control
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Michael Roth
Cc: Fabiano Rosas
Cc: Leonardo Bras
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/Makefile.objs | 1 +
include/hw/loader.h| 1 +
include/hw/ppc/spapr.h | 25 ++-
hw/ppc/spapr.c | 207 +---
hw/ppc/spapr_client.c | 423 +
hw/ppc/spapr_hcall.c | 47 +++--
hw/ppc/trace-events| 7 +
7 files changed, 676 insertions(+), 35 deletions(-)
create mode 100644 hw/ppc/spapr_client.c
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 101e9fc59185..ce31c0acd2fb 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o
spapr_rtas.o
obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
+obj-$(CONFIG_PSERIES) += spapr_client.o
obj-$(CONFIG_SPAPR_RNG) += spapr_rng.o
# IBM PowerNV
obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o
pnv_occ.o pnv_bmc.o
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 48a96cd55904..a2f58077a47e 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void
*blob, size_t len,
int rom_add_elf_program(const char *name, GMappedFile *mapped_file, void *data,
size_t datasize, size_t romsize, hwaddr addr,
AddressSpace *as);
+bool rom_intersect(uint64_t start, uint64_t size);
int rom_check_and_register_reset(void);
void rom_set_fw(FWCfgState *f);
void rom_set_order_override(int order);
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 61f005c6f686..876879d12029 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -105,6 +105,11 @@ struct SpaprCapabilities {
uint8_t caps[SPAPR_CAP_NUM];
};
+typedef struct {
+uint64_t start;
+uint64_t size;
+} spapr_of_claimed;
+
/**
* SpaprMachineClass:
*/
@@ -158,8 +163,13 @@ struct SpaprMachineState {
uint32_t fdt_size;
uint32_t fdt_initial_size;
void *fdt_blob;
+uint32_t rtas_base;
long kernel_size;
bool kernel_le;
+uint64_t kernel_addr;
+bool bios_enabled;
+GArray *claimed; /* array of spapr_of
Re: [PATCH v2 3/3] savevm: check RAM is pagesize aligned
On 1/3/20 8:40 AM, Marc-André Lureau wrote:
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..bbb7e89682 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2910,6 +2910,11 @@ err_drain:
void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev)
{
+RAMBlock *rb = mr->ram_block;
+
+assert(QEMU_PTR_IS_ALIGNED(qemu_ram_get_host_addr(rb),
+ qemu_ram_pagesize(rb)));
+
qemu_ram_set_idstr(mr->ram_block,
memory_region_name(mr), dev);
qemu_ram_set_migratable(mr->ram_block);
Re: [PATCH v2 1/3] misc: use QEMU_IS_ALIGNED
On 1/3/20 8:39 AM, Marc-André Lureau wrote:
Signed-off-by: Marc-André Lureau
---
exec.c| 4 ++--
roms/SLOF | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index d4b769d0d4..1feda49ca1 100644
--- a/exec.c
+++ b/exec.c
@@ -3895,7 +3895,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t start,
size_t length)
uint8_t *host_startaddr = rb->host + start;
-if ((uintptr_t)host_startaddr & (rb->page_size - 1)) {
+if (!QEMU_PTR_IS_ALIGNED(host_startaddr, rb->page_size)) {
error_report("ram_block_discard_range: Unaligned start address: %p",
host_startaddr);
goto err;
@@ -3903,7 +3903,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t start,
size_t length)
if ((start + length) <= rb->used_length) {
bool need_madvise, need_fallocate;
-if (length & (rb->page_size - 1)) {
+if (!QEMU_IS_ALIGNED(length, rb->page_size)) {
error_report("ram_block_discard_range: Unaligned length: %zx",
length);
goto err;
diff --git a/roms/SLOF b/roms/SLOF
index 9546892a80..8ebf2f55e1 16
--- a/roms/SLOF
+++ b/roms/SLOF
@@ -1 +1 @@
-Subproject commit 9546892a80d5a4c73deea6719de46372f007f4a6
+Subproject commit 8ebf2f55e1ba1492b942ba4b682160e644fc0f98
Without the SLOF submodule update:
Reviewed-by: Philippe Mathieu-Daudé
[PATCH v2 3/3] savevm: check RAM is pagesize aligned
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..bbb7e89682 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2910,6 +2910,11 @@ err_drain:
void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev)
{
+RAMBlock *rb = mr->ram_block;
+
+assert(QEMU_PTR_IS_ALIGNED(qemu_ram_get_host_addr(rb),
+ qemu_ram_pagesize(rb)));
+
qemu_ram_set_idstr(mr->ram_block,
memory_region_name(mr), dev);
qemu_ram_set_migratable(mr->ram_block);
--
2.24.0.308.g228f53135a
[PATCH v2 2/3] tpm-ppi: page-align PPI RAM
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
---
hw/tpm/tpm_ppi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/tpm/tpm_ppi.c b/hw/tpm/tpm_ppi.c
index ff314592b4..6d9c1a3e40 100644
--- a/hw/tpm/tpm_ppi.c
+++ b/hw/tpm/tpm_ppi.c
@@ -43,7 +43,8 @@ void tpm_ppi_reset(TPMPPI *tpmppi)
void tpm_ppi_init(TPMPPI *tpmppi, struct MemoryRegion *m,
hwaddr addr, Object *obj)
{
-tpmppi->buf = g_malloc0(HOST_PAGE_ALIGN(TPM_PPI_ADDR_SIZE));
+tpmppi->buf = qemu_memalign(qemu_real_host_page_size,
+HOST_PAGE_ALIGN(TPM_PPI_ADDR_SIZE));
memory_region_init_ram_device_ptr(&tpmppi->ram, obj, "tpm-ppi",
TPM_PPI_ADDR_SIZE, tpmppi->buf);
vmstate_register_ram(&tpmppi->ram, DEVICE(obj));
--
2.24.0.308.g228f53135a
[PATCH v2 1/3] misc: use QEMU_IS_ALIGNED
Signed-off-by: Marc-André Lureau
---
exec.c| 4 ++--
roms/SLOF | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index d4b769d0d4..1feda49ca1 100644
--- a/exec.c
+++ b/exec.c
@@ -3895,7 +3895,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t start,
size_t length)
uint8_t *host_startaddr = rb->host + start;
-if ((uintptr_t)host_startaddr & (rb->page_size - 1)) {
+if (!QEMU_PTR_IS_ALIGNED(host_startaddr, rb->page_size)) {
error_report("ram_block_discard_range: Unaligned start address: %p",
host_startaddr);
goto err;
@@ -3903,7 +3903,7 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t start,
size_t length)
if ((start + length) <= rb->used_length) {
bool need_madvise, need_fallocate;
-if (length & (rb->page_size - 1)) {
+if (!QEMU_IS_ALIGNED(length, rb->page_size)) {
error_report("ram_block_discard_range: Unaligned length: %zx",
length);
goto err;
diff --git a/roms/SLOF b/roms/SLOF
index 9546892a80..8ebf2f55e1 16
--- a/roms/SLOF
+++ b/roms/SLOF
@@ -1 +1 @@
-Subproject commit 9546892a80d5a4c73deea6719de46372f007f4a6
+Subproject commit 8ebf2f55e1ba1492b942ba4b682160e644fc0f98
--
2.24.0.308.g228f53135a
[PATCH v2 0/3] tpm: fix PPI RAM migration
Hi, The following series fixes a migration issue with the TPM PPI code due to unaligned host RAM pointer. v2: - use QEMU_IS_ALIGNED macros - remove RFC status from "savevm: check RAM is pagesize aligned" Marc-André Lureau (3): misc: use QEMU_IS_ALIGNED tpm-ppi: page-align PPI RAM savevm: check RAM is pagesize aligned exec.c | 4 ++-- hw/tpm/tpm_ppi.c | 3 ++- migration/savevm.c | 5 + roms/SLOF | 2 +- 4 files changed, 10 insertions(+), 4 deletions(-) -- 2.24.0.308.g228f53135a
Re: [PATCH qemu] spapr: Kill SLOF
Ignore this please, v2 is coming soon. And this one is missing "RFC"
anyway. Thanks,
On 03/01/2020 17:12, Alexey Kardashevskiy wrote:
> The Petitboot bootloader is way more advanced than SLOF is ever going to
> be as Petitboot comes with the full-featured Linux kernel with all
> the drivers, and initramdisk with quite user friendly interface.
> The problem with ditching SLOF is that an unmodified pseries kernel can
> either start via:
> 1. kexec, this requires presence of RTAS and skips
> ibm,client-architecture-support entirely;
> 2. normal boot, this heavily relies on the OF1275 client interface to
> fetch the device tree and do early setup (claim memory).
>
> This adds a new bios-less mode to the pseries machine: "bios=on|off".
> When enabled, QEMU does not load SLOF and jumps to the kernel from
> "-kernel".
>
> This picks a page for the initial stack at 0xf000.
>
> This implements a handful of client interface methods just to get going.
> In particular, this implements the device tree fetching,
> ibm,client-architecture-support and instantiate-rtas.
> This does not implement changing properties, i.e. "setprop".
>
> The client interface is implemented exactly as RTAS - a 20 bytes blob,
> right next after the RTAS blob.
>
> This assigns "phandles" to device tree nodes as there is no more SLOF
> and OF nodes addresses of which served as phandle values.
> This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
> phandles are regenerated at every FDT rebuild.
>
> When bios=off, this adds "/chosen" every time QEMU builds a tree.
>
> This implements "claim" which the client (Linux) uses for memory
> allocation; at the moment it only checks not to overwrite kernel or
> initramdisk (the only two "roms" loaded); this requires proper fixing.
>
> While at this, add a "kernel-addr" machine parameter to allow moving
> the kernel in memory. This is useful for debugging if the kernel is
> loaded at @0, although not necessary.
>
> Limitations:
> 1. stack allocation is wrong;
> 2. petitboot does not boot the selected system:
> "Must be root to change default boot option" (the message is likely
> to be misleading).
>
> The test command line:
>
> qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline \
> -nographic \
> -vga none \
> -kernel vmldbg \
> -machine pseries,bios=off \
> -m 4G \
> -enable-kvm \
> -initrd pb/rootfs.cpio.xz \
> img/u1804-64le.qcow2 \
> -snapshot \
> -smp 8,threads=8 \
> -L /home/aik/t/qemu-ppc64-bios/ \
> -trace events=qemu_trace_events \
> -d guest_errors \
> -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
> -mon chardev=SOCKET0,mode=control
>
> Cc: Paul Mackerras
> Cc: Nicholas Piggin
> Cc: Michael Ellerman
> Cc: Michael Roth
> Cc: Fabiano Rosas
> Cc: Leonardo Bras
> Signed-off-by: Alexey Kardashevskiy
> ---
> hw/ppc/Makefile.objs | 1 +
> include/hw/loader.h| 1 +
> include/hw/ppc/spapr.h | 16 +-
> hw/core/loader.c | 20 +++
> hw/ppc/spapr.c | 185 +---
> hw/ppc/spapr_client.c | 371 +
> hw/ppc/spapr_hcall.c | 47 --
> hw/ppc/trace-events| 7 +
> 8 files changed, 613 insertions(+), 35 deletions(-)
> create mode 100644 hw/ppc/spapr_client.c
>
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 101e9fc59185..ce31c0acd2fb 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o
> spapr_rtas.o
> obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
> obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
> obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
> +obj-$(CONFIG_PSERIES) += spapr_client.o
> obj-$(CONFIG_SPAPR_RNG) += spapr_rng.o
> # IBM PowerNV
> obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o
> pnv_occ.o pnv_bmc.o
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 48a96cd55904..a2f58077a47e 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void
> *blob, size_t len,
> int rom_add_elf_program(const char *name, GMappedFile *mapped_file, void
> *data,
> size_t datasize, size_t romsize, hwaddr addr,
> AddressSpace *as);
> +bool rom_intersect(uint64_t start, uint64_t size);
> int rom_check_and_register_reset(void);
> void rom_set_fw(FWCfgState *f);
> void rom_set_order_override(int order);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 61f005c6f686..a922b19fa6d3 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -158,8 +158,11 @@ struct SpaprMachineState {
> uint32_t fdt_size;
> uint32_t fdt_initial_size;
> void *fdt_blob;
> +uint32_t rtas_base;
> long
Re: [PATCH v3 0/3] Update capstone module
Hi Richard, On 10/15/19 7:51 PM, Richard Henderson wrote: Tested vs centos7, fedora30, and bionic (with and without system capstone installed). Change noted while testing: * Raw byte dumped as hexa before: no after: dumped by 16-bit OK * Address format before: "0x" TARGET_FMT_lx (16 chars) after: "0x%08" PRIx64 (8 chars) Shorten this might be OK because we now also dump the raw bytes previous to the mnemonic/arguments -0x00010014: mvi 163,1 -0x00010018: slr %r0,%r0 -0x0001001a: lhi %r1,2 +0x00010014: 9201 00a3 mvi 0xa3, 1 +0x00010018: 1f00slr %r0, %r0 +0x0001001a: a718 0002 lhi %r1, 2 * Number argument format before: decimal after: hexa -0x00010014: mvi 163,1 +0x00010014: mvi 0xa3, 1 OK * (Priviledged) Instruction missing -0x0001001e: sigp %r1,%r0,18 +0x0001001e: .byte0xae, 0x10, 0x00, 0x12 -0x00010066: lmh %r0,%r15,0(%r13) +0x00010066: .byte0xeb, 0x0f, 0xd0, 0x00, 0x00, 0x96 -0x0001006c: sam64 +0x0001006c: .byte0x01, 0x0e -0x00010088: lctlg %c0,%c15,512 +0x00010088: .byte0xeb, 0x0f, 0x02, 0x00, 0x00, 0x2f -0x0001008e: stcke 808 +0x0001008e: .byte0xb2, 0x78, 0x03, 0x28 -0x00010098: spt 80(%r13) +0x00010098: .byte0xb2, 0x08, 0xd0, 0x50 -0x000149b6: stfl 0 +0x000149b6: .byte0xb2, 0xb1, 0x00, 0x00 -0x000149da: stfle 0(%r1) +0x000149da: .byte0xb2, 0xb0, 0x10, 0x00 -0x00011a34: icm %r5,3,0(%r1) +0x00011a34: .byte0xbf, 0x53, 0x10, 0x00 -0x0010e8f6: lpswe 160(%r15) +0x0010e8f6: .byte0xb2, 0xb2, 0xf0, 0xa0 Is it possible to fallback to the older disassembler on a per-instruction basis if Capstone doesn't know about an instruction? Changes for v3: * Work around the various include directory nonsense. * Re-add the s390 skipdata callback, as a separate patch. Changes for v2: * Drop the installed directory change. This does force a different include change when building from git. * Drop the s390 skipdata callback for now.
Re: [PATCH qemu] spapr: Kill SLOF
Patchew URL: https://patchew.org/QEMU/20200103061217.16396-1-...@ozlabs.ru/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === The full log is available at http://patchew.org/logs/20200103061217.16396-1-...@ozlabs.ru/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
[RFC 4/4] target/ppc: Introduce ppc_hash64_use_vrma() helper
When running guests under a hypervisor, the hypervisor obviously needs to
be protected from guest accesses even if those are in what the guest
considers real mode (translation off). The POWER hardware provides two
ways of doing that: The old way has guest real mode accesses simply offset
and bounds checked into host addresses. It works, but requires that a
significant chunk of the guest's memory - the RMA - be physically
contiguous in the host, which is pretty inconvenient. The new way, known
as VRMA, has guest real mode accesses translated in roughly the normal way
but with some special parameters.
In POWER7 and POWER8 the LPCR[VPM0] bit selected between the two modes, but
in POWER9 only VRMA mode is supported and LPCR[VPM0] no longer exists. We
handle that difference in behaviour in ppc_hash64_set_isi().. but not in
other places that we blindly check LPCR[VPM0].
Correct those instances with a new helper to tell if we should be in VRMA
mode.
Signed-off-by: David Gibson
---
target/ppc/mmu-hash64.c | 41 +++--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
index 5fabd93c92..d878180df5 100644
--- a/target/ppc/mmu-hash64.c
+++ b/target/ppc/mmu-hash64.c
@@ -668,6 +668,19 @@ unsigned ppc_hash64_hpte_page_shift_noslb(PowerPCCPU *cpu,
return 0;
}
+static bool ppc_hash64_use_vrma(CPUPPCState *env)
+{
+switch (env->mmu_model) {
+case POWERPC_MMU_3_00:
+/* ISAv3.0 (POWER9) always uses VRMA, the VPM0 field and RMOR
+ * register no longer exist */
+return true;
+
+default:
+return !!(env->spr[SPR_LPCR] & LPCR_VPM0);
+}
+}
+
static void ppc_hash64_set_isi(CPUState *cs, uint64_t error_code)
{
CPUPPCState *env = &POWERPC_CPU(cs)->env;
@@ -676,15 +689,7 @@ static void ppc_hash64_set_isi(CPUState *cs, uint64_t
error_code)
if (msr_ir) {
vpm = !!(env->spr[SPR_LPCR] & LPCR_VPM1);
} else {
-switch (env->mmu_model) {
-case POWERPC_MMU_3_00:
-/* Field deprecated in ISAv3.00 - interrupts always go to hyperv */
-vpm = true;
-break;
-default:
-vpm = !!(env->spr[SPR_LPCR] & LPCR_VPM0);
-break;
-}
+vpm = ppc_hash64_use_vrma(env);
}
if (vpm && !msr_hv) {
cs->exception_index = POWERPC_EXCP_HISI;
@@ -702,15 +707,7 @@ static void ppc_hash64_set_dsi(CPUState *cs, uint64_t dar,
uint64_t dsisr)
if (msr_dr) {
vpm = !!(env->spr[SPR_LPCR] & LPCR_VPM1);
} else {
-switch (env->mmu_model) {
-case POWERPC_MMU_3_00:
-/* Field deprecated in ISAv3.00 - interrupts always go to hyperv */
-vpm = true;
-break;
-default:
-vpm = !!(env->spr[SPR_LPCR] & LPCR_VPM0);
-break;
-}
+vpm = ppc_hash64_use_vrma(env);
}
if (vpm && !msr_hv) {
cs->exception_index = POWERPC_EXCP_HDSI;
@@ -799,7 +796,7 @@ int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr
eaddr,
if (!(eaddr >> 63)) {
raddr |= env->spr[SPR_HRMOR];
}
-} else if (env->spr[SPR_LPCR] & LPCR_VPM0) {
+} else if (ppc_hash64_use_vrma(env)) {
/* Emulated VRMA mode */
slb = &env->vrma_slb;
if (!slb->sps) {
@@ -967,7 +964,7 @@ hwaddr ppc_hash64_get_phys_page_debug(PowerPCCPU *cpu,
target_ulong addr)
} else if ((msr_hv || !env->has_hv_mode) && !(addr >> 63)) {
/* In HV mode, add HRMOR if top EA bit is clear */
return raddr | env->spr[SPR_HRMOR];
-} else if (env->spr[SPR_LPCR] & LPCR_VPM0) {
+} else if (ppc_hash64_use_vrma(env)) {
/* Emulated VRMA mode */
slb = &env->vrma_slb;
if (!slb->sps) {
@@ -1056,8 +1053,7 @@ static void ppc_hash64_update_vrma(PowerPCCPU *cpu)
slb->sps = NULL;
/* Is VRMA enabled ? */
-lpcr = env->spr[SPR_LPCR];
-if (!(lpcr & LPCR_VPM0)) {
+if (ppc_hash64_use_vrma(env)) {
return;
}
@@ -1065,6 +1061,7 @@ static void ppc_hash64_update_vrma(PowerPCCPU *cpu)
* Make one up. Mostly ignore the ESID which will not be needed
* for translation
*/
+lpcr = env->spr[SPR_LPCR];
vsid = SLB_VSID_VRMA;
vrmasd = (lpcr & LPCR_VRMASD) >> LPCR_VRMASD_SHIFT;
vsid |= (vrmasd << 4) & (SLB_VSID_L | SLB_VSID_LP);
--
2.24.1
[RFC 1/4] ppc: Drop PPC_EMULATE_32BITS_HYPV stub
The only effect of the PPC_EMULATE_32BITS_HYPV define is to change how
MSR_HVB is defined. This appears to be something to handle hypervisor mode
for 32-bit CPUs, but there's really no other code to handle this. The
MSR_THV bit, which it uses is implemented for no cpus we model.
It's unlikely anyone is going to implement this any time soon, so just drop
it.
Signed-off-by: David Gibson
---
target/ppc/cpu.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 103bfe9dc2..2de9e2fa2b 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -26,8 +26,6 @@
#include "exec/cpu-defs.h"
#include "cpu-qom.h"
-/* #define PPC_EMULATE_32BITS_HYPV */
-
#define TCG_GUEST_DEFAULT_MO 0
#define TARGET_PAGE_BITS_64K 16
@@ -450,14 +448,9 @@ typedef struct ppc_v3_pate_t {
#define MSR_HVB (1ULL << MSR_SHV)
#define msr_hv msr_shv
#else
-#if defined(PPC_EMULATE_32BITS_HYPV)
-#define MSR_HVB (1ULL << MSR_THV)
-#define msr_hv msr_thv
-#else
#define MSR_HVB (0ULL)
#define msr_hv (0)
#endif
-#endif
/* DSISR */
#define DSISR_NOPTE 0x4000
--
2.24.1
[RFC 3/4] target/ppc: Correct handling of real mode accesses with vhyp on hash MMU
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qemu's notion of target physical address is
a guest physical address from the vcpu's point of view. So accesses in
guest real mode don't require translation. If we were modelling the
hypervisor mode, we'd need to translate the guest physical address into
a host physical address.
Currently, we handle this sloppily: we rely on setting up the virtual LPCR
and RMOR registers so that GPAs are simply HPAs plus an offset, which we
set to zero. This is already conceptually dubious, since the LPCR and RMOR
registers don't exist in the non-hypervisor portion of the CPU. It gets
worse with POWER9, where RMOR and LPCR[VPM0] no longer exist at all.
Clean this up by explicitly handling the vhyp case. While we're there,
remove some unnecessary nesting of if statements that made the logic to
select the correct real mode behaviour a bit less clear than it could be.
Signed-off-by: David Gibson
---
target/ppc/mmu-hash64.c | 60 -
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
index a881876647..5fabd93c92 100644
--- a/target/ppc/mmu-hash64.c
+++ b/target/ppc/mmu-hash64.c
@@ -789,27 +789,30 @@ int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr
eaddr,
*/
raddr = eaddr & 0x0FFFULL;
-/* In HV mode, add HRMOR if top EA bit is clear */
-if (msr_hv || !env->has_hv_mode) {
+if (cpu->vhyp) {
+/*
+ * In virtual hypervisor mode, there's nothing to do:
+ * EA == GPA == qemu guest address
+ */
+} else if (msr_hv || !env->has_hv_mode) {
+/* In HV mode, add HRMOR if top EA bit is clear */
if (!(eaddr >> 63)) {
raddr |= env->spr[SPR_HRMOR];
}
-} else {
-/* Otherwise, check VPM for RMA vs VRMA */
-if (env->spr[SPR_LPCR] & LPCR_VPM0) {
-slb = &env->vrma_slb;
-if (slb->sps) {
-goto skip_slb_search;
-}
-/* Not much else to do here */
+} else if (env->spr[SPR_LPCR] & LPCR_VPM0) {
+/* Emulated VRMA mode */
+slb = &env->vrma_slb;
+if (!slb->sps) {
+/* Invalid VRMA setup, machine check */
cs->exception_index = POWERPC_EXCP_MCHECK;
env->error_code = 0;
return 1;
-} else if (raddr < env->rmls) {
-/* RMA. Check bounds in RMLS */
-raddr |= env->spr[SPR_RMOR];
-} else {
-/* The access failed, generate the approriate interrupt */
+}
+
+goto skip_slb_search;
+} else {
+/* Emulated old-style RMO mode, bounds check against RMLS */
+if (raddr >= env->rmls) {
if (rwx == 2) {
ppc_hash64_set_isi(cs, SRR1_PROTFAULT);
} else {
@@ -821,6 +824,8 @@ int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr
eaddr,
}
return 1;
}
+
+raddr |= env->spr[SPR_RMOR];
}
tlb_set_page(cs, eaddr & TARGET_PAGE_MASK, raddr & TARGET_PAGE_MASK,
PAGE_READ | PAGE_WRITE | PAGE_EXEC, mmu_idx,
@@ -953,22 +958,27 @@ hwaddr ppc_hash64_get_phys_page_debug(PowerPCCPU *cpu,
target_ulong addr)
/* In real mode the top 4 effective address bits are ignored */
raddr = addr & 0x0FFFULL;
-/* In HV mode, add HRMOR if top EA bit is clear */
-if ((msr_hv || !env->has_hv_mode) && !(addr >> 63)) {
+if (cpu->vhyp) {
+/*
+ * In virtual hypervisor mode, there's nothing to do:
+ * EA == GPA == qemu guest address
+ */
+return raddr;
+} else if ((msr_hv || !env->has_hv_mode) && !(addr >> 63)) {
+/* In HV mode, add HRMOR if top EA bit is clear */
return raddr | env->spr[SPR_HRMOR];
-}
-
-/* Otherwise, check VPM for RMA vs VRMA */
-if (env->spr[SPR_LPCR] & LPCR_VPM0) {
+} else if (env->spr[SPR_LPCR] & LPCR_VPM0) {
+/* Emulated VRMA mode */
slb = &env->vrma_slb;
if (!slb->sps) {
return -1;
}
-} else if (raddr < env->rmls) {
-/* RMA. Check bounds in RMLS */
-return raddr | env->spr[SPR_RMOR];
} else {
-return -1;
+/* Emulated old-style RMO mode, bounds check against RMLS */
+if (raddr >= env->rmls) {
+r
[RFC 2/4] ppc: Remove stub of PPC970 HID4 implementation
The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability.
However, it can be (and often was) strapped into "Apple mode", where the
hypervisor capabilities were disabled (essentially putting it always in
hypervisor mode).
That's actually the only mode of the 970 we support in qemu, and we're
unlikely to change that any time soon. However, we do have a partial
implementation of the 970's HID4 register which affects things only
relevant for hypervisor mode.
That stub is also really ugly, since it attempts to duplicate the effects
of HID4 by re-encoding it into the LPCR register used in newer CPUs, but
in a really confusing way.
Just get rid of it.
Signed-off-by: David Gibson
---
target/ppc/mmu-hash64.c | 28 +---
target/ppc/translate_init.inc.c | 17 ++---
2 files changed, 7 insertions(+), 38 deletions(-)
diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
index da8966ccf5..a881876647 100644
--- a/target/ppc/mmu-hash64.c
+++ b/target/ppc/mmu-hash64.c
@@ -1091,33 +1091,6 @@ void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val)
/* Filter out bits */
switch (env->mmu_model) {
-case POWERPC_MMU_64B: /* 970 */
-if (val & 0x40) {
-lpcr |= LPCR_LPES0;
-}
-if (val & 0x8000ull) {
-lpcr |= LPCR_LPES1;
-}
-if (val & 0x20) {
-lpcr |= (0x4ull << LPCR_RMLS_SHIFT);
-}
-if (val & 0x4000ull) {
-lpcr |= (0x2ull << LPCR_RMLS_SHIFT);
-}
-if (val & 0x2000ull) {
-lpcr |= (0x1ull << LPCR_RMLS_SHIFT);
-}
-env->spr[SPR_RMOR] = ((lpcr >> 41) & 0xull) << 26;
-
-/*
- * XXX We could also write LPID from HID4 here
- * but since we don't tag any translation on it
- * it doesn't actually matter
- *
- * XXX For proper emulation of 970 we also need
- * to dig HRMOR out of HID5
- */
-break;
case POWERPC_MMU_2_03: /* P5p */
lpcr = val & (LPCR_RMLS | LPCR_ILE |
LPCR_LPES0 | LPCR_LPES1 |
@@ -1154,6 +1127,7 @@ void ppc_store_lpcr(PowerPCCPU *cpu, target_ulong val)
}
break;
default:
+g_assert_not_reached();
;
}
env->spr[SPR_LPCR] = lpcr;
diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c
index d33d65dff7..436d0d5a51 100644
--- a/target/ppc/translate_init.inc.c
+++ b/target/ppc/translate_init.inc.c
@@ -7884,25 +7884,20 @@ static void spr_write_lpcr(DisasContext *ctx, int sprn,
int gprn)
{
gen_helper_store_lpcr(cpu_env, cpu_gpr[gprn]);
}
-
-static void spr_write_970_hid4(DisasContext *ctx, int sprn, int gprn)
-{
-#if defined(TARGET_PPC64)
-spr_write_generic(ctx, sprn, gprn);
-gen_helper_store_lpcr(cpu_env, cpu_gpr[gprn]);
-#endif
-}
-
#endif /* !defined(CONFIG_USER_ONLY) */
static void gen_spr_970_lpar(CPUPPCState *env)
{
#if !defined(CONFIG_USER_ONLY)
/* Logical partitionning */
-/* PPC970: HID4 is effectively the LPCR */
+/* PPC970: HID4 covers things later controlled by the LPCR and
+ * RMOR in later CPUs, but with a different encoding. We only
+ * support the 970 in "Apple mode" which has all hypervisor
+ * facilities disabled by strapping, so we can basically just
+ * ignore it */
spr_register(env, SPR_970_HID4, "HID4",
SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_970_hid4,
+ &spr_read_generic, &spr_write_generic,
0x);
#endif
}
--
2.24.1
[RFC 0/4] target/ppc: Correct some errors with real mode handling
POWER "book S" (server class) cpus have a concept of "real mode" where MMU translation is disabled... sort of. In fact this can mean a bunch of slightly different things when hypervisor mode and other considerations are present. We had some errors in edge cases here, so clean some things up and correct them. David Gibson (4): ppc: Drop PPC_EMULATE_32BITS_HYPV stub ppc: Remove stub of PPC970 HID4 implementation target/ppc: Correct handling of real mode accesses with vhyp on hash MMU target/ppc: Introduce ppc_hash64_use_vrma() helper target/ppc/cpu.h| 7 -- target/ppc/mmu-hash64.c | 125 ++-- target/ppc/translate_init.inc.c | 17 ++--- 3 files changed, 59 insertions(+), 90 deletions(-) -- 2.24.1
Re: [PATCH 1/2] RFC: savevm: check RAM is page_size aligned
Hi
On Fri, Jan 3, 2020 at 9:06 AM Philippe Mathieu-Daudé wrote:
>
> Hi Marc-André,
>
> On 1/2/20 10:01 PM, Marc-André Lureau wrote:
> > Check the host pointer is correctly aligned, otherwise we may fail
> > during migration in ram_block_discard_range().
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > migration/savevm.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/migration/savevm.c b/migration/savevm.c
> > index a71b930b91..ab6e02011f 100644
> > --- a/migration/savevm.c
> > +++ b/migration/savevm.c
> > @@ -2910,6 +2910,11 @@ err_drain:
> >
> > void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev)
> > {
> > +RAMBlock *rb = mr->ram_block;
> > +uintptr_t hostaddr = (uintptr_t)qemu_ram_get_host_addr(rb);
> > +
> > +assert((hostaddr & (qemu_ram_pagesize(rb) - 1)) == 0);
>
> Can we use the QEMU_PTR_IS_ALIGNED() macro instead?
>
> assert(QEMU_PTR_IS_ALIGNED(qemu_ram_get_host_addr(rb),
>qemu_ram_pagesize(rb)));
>
nice, good idea
> > qemu_ram_set_idstr(mr->ram_block,
> > memory_region_name(mr), dev);
> > qemu_ram_set_migratable(mr->ram_block);
> >
>
Re: [PATCH v3 09/29] plugins: Include trace/mem.h in api.c
Hi Richard, On 12/29/19 12:11 AM, Richard Henderson wrote: Code movement in an upcoming patch will show that this file was implicitly depending on trace/mem.h being included beforehand. Ah, it uses the TRACE_MEM_* macros from "trace/mem-internal.h", which is include by "trace/mem.h". OK. Which part requires "trace-root.h"? Isn't it "trace/mem-internal.h" that should include "trace-root.h"? Reported-by: Alex Bennée Signed-off-by: Richard Henderson --- plugins/api.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/plugins/api.c b/plugins/api.c index fa1d9f276d..cb7098ce79 100644 --- a/plugins/api.c +++ b/plugins/api.c @@ -46,6 +46,8 @@ #include "qemu/plugin-memory.h" #include "hw/boards.h" #endif +#include "trace-root.h" +#include "trace/mem.h" /* Uninstall and Reset handlers */
Re: [PATCH v5 4/6] hppa: add emulation of LASI PS2 controllers
Hi Sven,
On 12/20/19 10:15 PM, Sven Schnelle wrote:
Signed-off-by: Sven Schnelle
---
hw/hppa/Kconfig| 1 +
hw/hppa/lasi.c | 10 +-
hw/input/Kconfig | 3 +
hw/input/Makefile.objs | 1 +
hw/input/lasips2.c | 289 +
hw/input/ps2.c | 5 +
hw/input/trace-events | 5 +
include/hw/input/lasips2.h | 16 ++
include/hw/input/ps2.h | 1 +
9 files changed, 330 insertions(+), 1 deletion(-)
create mode 100644 hw/input/lasips2.c
create mode 100644 include/hw/input/lasips2.h
diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index 2a7b38d6d6..7f9be7f25c 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -11,3 +11,4 @@ config DINO
select MC146818RTC
select LSI_SCSI_PCI
select LASI_82596
+select LASIPS2
If these components are part of the LASI chipset, you don't need an
specific Kconfig entry for each, you can simply use the LASI one.
Add a LASI entry in hw/hppa/Kconfig such:
config LASI
bool
select I82596_COMMON
select PS2
If you disagree, can you rename LASIPS2 -> LASI_PS2?
diff --git a/hw/hppa/lasi.c b/hw/hppa/lasi.c
index 51752589f3..d8d03f95c0 100644
--- a/hw/hppa/lasi.c
+++ b/hw/hppa/lasi.c
@@ -22,6 +22,7 @@
#include "hw/net/lasi_82596.h"
#include "hw/char/parallel.h"
#include "hw/char/serial.h"
+#include "hw/input/lasips2.h"
#include "exec/address-spaces.h"
#include "migration/vmstate.h"
@@ -324,6 +325,7 @@ DeviceState *lasi_init(MemoryRegion *address_space)
lpt_irq, parallel_hds[0]);
/* Real time clock (RTC), it's only one 32-bit counter @9000 */
+
s->rtc = time(NULL);
s->rtc_ref = 0;
@@ -333,8 +335,14 @@ DeviceState *lasi_init(MemoryRegion *address_space)
lasi_get_irq(LASI_UART_HPA));
serial_mm_init(address_space, LASI_UART_HPA + 0x800, 0,
serial_irq, 800 / 16,
-serial_hd(1), DEVICE_NATIVE_ENDIAN);
+serial_hd(0), DEVICE_NATIVE_ENDIAN);
}
+
+/* PS/2 Keyboard/Mouse */
+qemu_irq ps2kbd_irq = qemu_allocate_irq(lasi_set_irq, s,
+lasi_get_irq(LASI_PS2KBD_HPA));
+lasips2_init(address_space, LASI_PS2KBD_HPA, ps2kbd_irq);
+
return dev;
}
diff --git a/hw/input/Kconfig b/hw/input/Kconfig
index 287f08887b..25c77a1b87 100644
--- a/hw/input/Kconfig
+++ b/hw/input/Kconfig
@@ -41,3 +41,6 @@ config VHOST_USER_INPUT
config TSC210X
bool
+
+config LASIPS2
+select PS2
diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
index a1bc502ed0..f98f635685 100644
--- a/hw/input/Makefile.objs
+++ b/hw/input/Makefile.objs
@@ -15,3 +15,4 @@ common-obj-$(CONFIG_VHOST_USER_INPUT) += vhost-user-input.o
obj-$(CONFIG_MILKYMIST) += milkymist-softusb.o
obj-$(CONFIG_PXA2XX) += pxa2xx_keypad.o
obj-$(CONFIG_TSC210X) += tsc210x.o
+obj-$(CONFIG_LASIPS2) += lasips2.o
diff --git a/hw/input/lasips2.c b/hw/input/lasips2.c
new file mode 100644
index 00..1943671d1e
--- /dev/null
+++ b/hw/input/lasips2.c
@@ -0,0 +1,289 @@
+/*
+ * QEMU HP Lasi PS/2 interface emulation
+ *
+ * Copyright (c) 2019 Sven Schnelle
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/qdev-properties.h"
+#include "hw/hw.h"
+#include "hw/input/ps2.h"
+#include "hw/input/lasips2.h"
+#include "hw/sysbus.h"
+#include "exec/hwaddr.h"
+#include "sysemu/sysemu.h"
+#include "trace.h"
+#include "exec/address-spaces.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+struct LASIPS2State;
+typedef struct LASIPS2Port {
+struct LASIPS2State *parent;
+MemoryRegion reg;
+void *dev;
+uint8_t id;
+uint8_t control;
+uint8_t buf;
+bool loopback_rbne;
+bool irq;
+} LASIPS2Port;
[...]
[PATCH qemu] spapr: Kill SLOF
The Petitboot bootloader is way more advanced than SLOF is ever going to
be as Petitboot comes with the full-featured Linux kernel with all
the drivers, and initramdisk with quite user friendly interface.
The problem with ditching SLOF is that an unmodified pseries kernel can
either start via:
1. kexec, this requires presence of RTAS and skips
ibm,client-architecture-support entirely;
2. normal boot, this heavily relies on the OF1275 client interface to
fetch the device tree and do early setup (claim memory).
This adds a new bios-less mode to the pseries machine: "bios=on|off".
When enabled, QEMU does not load SLOF and jumps to the kernel from
"-kernel".
This picks a page for the initial stack at 0xf000.
This implements a handful of client interface methods just to get going.
In particular, this implements the device tree fetching,
ibm,client-architecture-support and instantiate-rtas.
This does not implement changing properties, i.e. "setprop".
The client interface is implemented exactly as RTAS - a 20 bytes blob,
right next after the RTAS blob.
This assigns "phandles" to device tree nodes as there is no more SLOF
and OF nodes addresses of which served as phandle values.
This keeps predefined nodes (such as XICS/NVLINK/...) unchanged.
phandles are regenerated at every FDT rebuild.
When bios=off, this adds "/chosen" every time QEMU builds a tree.
This implements "claim" which the client (Linux) uses for memory
allocation; at the moment it only checks not to overwrite kernel or
initramdisk (the only two "roms" loaded); this requires proper fixing.
While at this, add a "kernel-addr" machine parameter to allow moving
the kernel in memory. This is useful for debugging if the kernel is
loaded at @0, although not necessary.
Limitations:
1. stack allocation is wrong;
2. petitboot does not boot the selected system:
"Must be root to change default boot option" (the message is likely
to be misleading).
The test command line:
qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline \
-nographic \
-vga none \
-kernel vmldbg \
-machine pseries,bios=off \
-m 4G \
-enable-kvm \
-initrd pb/rootfs.cpio.xz \
img/u1804-64le.qcow2 \
-snapshot \
-smp 8,threads=8 \
-L /home/aik/t/qemu-ppc64-bios/ \
-trace events=qemu_trace_events \
-d guest_errors \
-chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.ssh37874 \
-mon chardev=SOCKET0,mode=control
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Michael Ellerman
Cc: Michael Roth
Cc: Fabiano Rosas
Cc: Leonardo Bras
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/Makefile.objs | 1 +
include/hw/loader.h| 1 +
include/hw/ppc/spapr.h | 16 +-
hw/core/loader.c | 20 +++
hw/ppc/spapr.c | 185 +---
hw/ppc/spapr_client.c | 371 +
hw/ppc/spapr_hcall.c | 47 --
hw/ppc/trace-events| 7 +
8 files changed, 613 insertions(+), 35 deletions(-)
create mode 100644 hw/ppc/spapr_client.c
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 101e9fc59185..ce31c0acd2fb 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -6,6 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o
spapr_rtas.o
obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
+obj-$(CONFIG_PSERIES) += spapr_client.o
obj-$(CONFIG_SPAPR_RNG) += spapr_rng.o
# IBM PowerNV
obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o
pnv_occ.o pnv_bmc.o
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 48a96cd55904..a2f58077a47e 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -262,6 +262,7 @@ MemoryRegion *rom_add_blob(const char *name, const void
*blob, size_t len,
int rom_add_elf_program(const char *name, GMappedFile *mapped_file, void *data,
size_t datasize, size_t romsize, hwaddr addr,
AddressSpace *as);
+bool rom_intersect(uint64_t start, uint64_t size);
int rom_check_and_register_reset(void);
void rom_set_fw(FWCfgState *f);
void rom_set_order_override(int order);
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 61f005c6f686..a922b19fa6d3 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -158,8 +158,11 @@ struct SpaprMachineState {
uint32_t fdt_size;
uint32_t fdt_initial_size;
void *fdt_blob;
+uint32_t rtas_base;
long kernel_size;
bool kernel_le;
+uint64_t kernel_addr;
+bool bios_enabled;
uint32_t initrd_base;
long initrd_size;
uint64_t rtc_offset; /* Now used only during incoming migration */
@@ -510,7 +513,8 @@ struct SpaprMachineState {
/* Client Architecture support */
#define KVMPPC_H_CAS(KVMPPC_HCALL_BASE + 0x2)
#define KVMPPC_H_UPDATE_DT (KVMPPC
[Bug 1856834] Re: Virtio broken in qemu ppc in 4.2.0 and other versions
Hope you enjoyed the Holidays, Happy 2020! I would really appreciate if you could confirm for me if virtio works fine for you with ppc -M mpc8544ds with older Linux guest kernels like 2.6.32 thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1856834 Title: Virtio broken in qemu ppc in 4.2.0 and other versions Status in QEMU: New Bug description: The same qemu -M mpc... command that works on qemu-system-ppc version 2.8.0 freezes guest on bootup and shows error for qemu-system-ppc version 4.2.0release and 4.19dirtygit: qemu-system-ppc: virtio-blk failed to set guest notifier (-24), ensure -accel kvm is set. qemu-system-ppc: virtio_bus_start_ioeventfd: failed. Fallback to userspace (slower). ends/freezes at: nbd: registered device at major 43 vda: I'm using -drive file=/home/me/rawimage.dd,if=virtio and works fine in version 2.8.0 installed with apt-get install (Ubuntu 17.04) and also with 2.8.0 official release from git/github that I compiled/built myself. But both of the newer releases fail on the same exact machine same config. I also noticed that qemu-2.8.0 was fine with mtd but the newer ones I tried weren't, ie gave qemu-system-ppc: -drive if=mtd: machine type does not support if=mtd,bus=0,unit=0 (but I removed -drive if=mtd since wasn't using it anyway) I also tried on windows but I think virtio doesn't work on windows hosts at all? On windows host it fails the same way, even version 2.12 as well as 4.1.10... used: ./configure --prefix=/opt/... --enable-fdt --enable-kvm --enable-debug (basically all steps the same on same exact system same config, yet 2.8.0 works fine whether apt-get installed or built from source while the others I built, 4.19/4.2.0 or 2.12/4.1.10(win) don't.) In case newer qemu versions act weird on various kernels, I did try with both vmlinuz-4.10.0-19-generic and vmlinuz-4.13.12-041312-generic (I didn't compile them but I can provide config-..files. This is on Ubuntu 17.04 x86_64 host emulating e500v2 cpm guest, ie -M mpc... GUEST kernel 2.6.32.44 which is why I can't use -M ppce500 instead..) tx ecs To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1856834/+subscriptions
Re: [PATCH 2/2] tpm-ppi: page-align PPI RAM
On 1/2/20 10:01 PM, Marc-André Lureau wrote:
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
---
hw/tpm/tpm_ppi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/tpm/tpm_ppi.c b/hw/tpm/tpm_ppi.c
index ff314592b4..6d9c1a3e40 100644
--- a/hw/tpm/tpm_ppi.c
+++ b/hw/tpm/tpm_ppi.c
@@ -43,7 +43,8 @@ void tpm_ppi_reset(TPMPPI *tpmppi)
void tpm_ppi_init(TPMPPI *tpmppi, struct MemoryRegion *m,
hwaddr addr, Object *obj)
{
-tpmppi->buf = g_malloc0(HOST_PAGE_ALIGN(TPM_PPI_ADDR_SIZE));
+tpmppi->buf = qemu_memalign(qemu_real_host_page_size,
+HOST_PAGE_ALIGN(TPM_PPI_ADDR_SIZE));
memory_region_init_ram_device_ptr(&tpmppi->ram, obj, "tpm-ppi",
TPM_PPI_ADDR_SIZE, tpmppi->buf);
vmstate_register_ram(&tpmppi->ram, DEVICE(obj));
RE: sysbus usb xhci
Thanks Philippe & Gred. I would start with the below pointers. Regards, Sai Pavan > -Original Message- > From: Philippe Mathieu-Daudé > Sent: Thursday, January 2, 2020 4:56 PM > To: kra...@redhat.com; Sai Pavan Boddu > Cc: peter.mayd...@linaro.org; qemu-devel@nongnu.org > Subject: Re: sysbus usb xhci > > On 1/2/20 10:45 AM, kra...@redhat.com wrote: > > On Thu, Jan 02, 2020 at 07:13:25AM +, Sai Pavan Boddu wrote: > >> Hi Gred, > >> > >> We are seeing of options to reuse the hcd-xhci model and use it over > >> system bus interface rather than pci. (for Xilinx ZynqMP SOC, usb > emulation) Are there any plans of implementing a sysbus device ? if none it > would be good if provided few pointers to start. > > > > There have been some discussions about this for a (IIRC) sbsa machine, > > but I'm not sure whenever that where just ideas or some code exists. > > > >> Im looking at hcd-ehci/ochi as a reference, let me know if there are any > know limitations for this usecase. > > > > Yep, the path for xhci would be quite simliar: Create a new > > XHCIPciState struct, move over all pci-specific bits from XHCIState, > > leaving the generic stuff in XHCIState for sharing with sysbus. > > Possibly move all pci-specific code bits into a new source file (for > > cleanup, will also allow to build qemu with CONFIG_PCI=n and still > > have XHCI enabled). > > > > Once this separation is done you should be able to create a sysbus > > device, reusing the generic xhci code and adding sysbus plumbing > > (mmio, irq, ...) > > The SDHCI commits b635d98cf32..8b7455c75e seem similar to what you > want to achieve (see also commit ce8646034).
Re: [PATCH 1/2] RFC: savevm: check RAM is page_size aligned
Hi Marc-André,
On 1/2/20 10:01 PM, Marc-André Lureau wrote:
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..ab6e02011f 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2910,6 +2910,11 @@ err_drain:
void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev)
{
+RAMBlock *rb = mr->ram_block;
+uintptr_t hostaddr = (uintptr_t)qemu_ram_get_host_addr(rb);
+
+assert((hostaddr & (qemu_ram_pagesize(rb) - 1)) == 0);
Can we use the QEMU_PTR_IS_ALIGNED() macro instead?
assert(QEMU_PTR_IS_ALIGNED(qemu_ram_get_host_addr(rb),
qemu_ram_pagesize(rb)));
qemu_ram_set_idstr(mr->ram_block,
memory_region_name(mr), dev);
qemu_ram_set_migratable(mr->ram_block);
[PATCH v3 3/4] RISC-V: support vector extension csr
Until v0.7.1 specification, vector status is still not defined for
mstatus.
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu_bits.h | 15 +++
target/riscv/csr.c | 92 +
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 11f971ad5d..9eb43ecc1e 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -29,6 +29,14 @@
#define FSR_NXA (FPEXC_NX << FSR_AEXC_SHIFT)
#define FSR_AEXC(FSR_NVA | FSR_OFA | FSR_UFA | FSR_DZA | FSR_NXA)
+/* Vector Fixed-Point round model */
+#define FSR_VXRM_SHIFT 9
+#define FSR_VXRM(0x3 << FSR_VXRM_SHIFT)
+
+/* Vector Fixed-Point saturation flag */
+#define FSR_VXSAT_SHIFT 8
+#define FSR_VXSAT (0x1 << FSR_VXSAT_SHIFT)
+
/* Control and Status Registers */
/* User Trap Setup */
@@ -48,6 +56,13 @@
#define CSR_FRM 0x002
#define CSR_FCSR0x003
+/* User Vector CSRs */
+#define CSR_VSTART 0x008
+#define CSR_VXSAT 0x009
+#define CSR_VXRM0x00a
+#define CSR_VL 0xc20
+#define CSR_VTYPE 0xc21
+
/* User Timers and Counters */
#define CSR_CYCLE 0xc00
#define CSR_TIME0xc01
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index e0d4586760..506ad7b590 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -53,6 +53,11 @@ static int fs(CPURISCVState *env, int csrno)
return 0;
}
+static int vs(CPURISCVState *env, int csrno)
+{
+return 0;
+}
+
static int ctr(CPURISCVState *env, int csrno)
{
#if !defined(CONFIG_USER_ONLY)
@@ -107,11 +112,6 @@ static int pmp(CPURISCVState *env, int csrno)
/* User Floating-Point CSRs */
static int read_fflags(CPURISCVState *env, int csrno, target_ulong *val)
{
-#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
-return -1;
-}
-#endif
*val = riscv_cpu_get_fflags(env);
return 0;
}
@@ -119,9 +119,6 @@ static int read_fflags(CPURISCVState *env, int csrno,
target_ulong *val)
static int write_fflags(CPURISCVState *env, int csrno, target_ulong val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
-return -1;
-}
env->mstatus |= MSTATUS_FS;
#endif
riscv_cpu_set_fflags(env, val & (FSR_AEXC >> FSR_AEXC_SHIFT));
@@ -130,11 +127,6 @@ static int write_fflags(CPURISCVState *env, int csrno,
target_ulong val)
static int read_frm(CPURISCVState *env, int csrno, target_ulong *val)
{
-#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
-return -1;
-}
-#endif
*val = env->frm;
return 0;
}
@@ -142,9 +134,6 @@ static int read_frm(CPURISCVState *env, int csrno,
target_ulong *val)
static int write_frm(CPURISCVState *env, int csrno, target_ulong val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
-return -1;
-}
env->mstatus |= MSTATUS_FS;
#endif
env->frm = val & (FSR_RD >> FSR_RD_SHIFT);
@@ -153,29 +142,73 @@ static int write_frm(CPURISCVState *env, int csrno,
target_ulong val)
static int read_fcsr(CPURISCVState *env, int csrno, target_ulong *val)
{
-#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
-return -1;
-}
-#endif
-*val = (riscv_cpu_get_fflags(env) << FSR_AEXC_SHIFT)
-| (env->frm << FSR_RD_SHIFT);
+*val = (env->vext.vxrm << FSR_VXRM_SHIFT)
+| (env->vext.vxsat << FSR_VXSAT_SHIFT)
+| (riscv_cpu_get_fflags(env) << FSR_AEXC_SHIFT)
+| (env->frm << FSR_RD_SHIFT);
return 0;
}
static int write_fcsr(CPURISCVState *env, int csrno, target_ulong val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
-return -1;
-}
env->mstatus |= MSTATUS_FS;
#endif
env->frm = (val & FSR_RD) >> FSR_RD_SHIFT;
+env->vext.vxrm = (val & FSR_VXRM) >> FSR_VXRM_SHIFT;
+env->vext.vxsat = (val & FSR_VXSAT) >> FSR_VXSAT_SHIFT;
riscv_cpu_set_fflags(env, (val & FSR_AEXC) >> FSR_AEXC_SHIFT);
return 0;
}
+static int read_vtype(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vext.vtype;
+return 0;
+}
+
+static int read_vl(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vext.vl;
+return 0;
+}
+
+static int read_vxrm(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vext.vxrm;
+return 0;
+}
+
+static int read_vxsat(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vext.vxsat;
+return 0;
+}
+
+static int read_vstart(CPURISCVState *env, int csrno, target_ulong *val)
+{
+*val = env->vext.vstart;
+return 0;
+}
+
+static int write_vxrm(CPURISCVState *env, int csrno, target_ulong val)
+{
+env->vext.vxrm = val;
+return 0;
+}
+
+static int write
[PATCH v3 2/4] RISC-V: configure and turn on vector extension from command line
Vector extension is default on only for "any" cpu. It can be turned
on by command line "-cpu rv64,vlen=128,elen=64,vext_spec=v0.7.1".
vlen is the vector register length, default value is 128 bit.
elen is the max operator size in bits, default value is 64 bit.
vext_spec is the vector specification version, default value is v0.7.1.
Thest properties and cpu can be specified with other values.
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu.c | 42 --
target/riscv/cpu.h | 8
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index f8d07bd20a..c2370a0a57 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -94,6 +94,11 @@ static void set_priv_version(CPURISCVState *env, int
priv_ver)
env->priv_ver = priv_ver;
}
+static void set_vext_version(CPURISCVState *env, int vext_ver)
+{
+env->vext_ver = vext_ver;
+}
+
static void set_feature(CPURISCVState *env, int feature)
{
env->features |= (1ULL << feature);
@@ -109,7 +114,7 @@ static void set_resetvec(CPURISCVState *env, int resetvec)
static void riscv_any_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
-set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
+set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVU | RVV);
set_priv_version(env, PRIV_VERSION_1_11_0);
set_resetvec(env, DEFAULT_RSTVEC);
}
@@ -317,6 +322,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error
**errp)
CPURISCVState *env = &cpu->env;
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(dev);
int priv_version = PRIV_VERSION_1_11_0;
+int vext_version = VEXT_VERSION_0_07_1;
target_ulong target_misa = 0;
Error *local_err = NULL;
@@ -340,8 +346,18 @@ static void riscv_cpu_realize(DeviceState *dev, Error
**errp)
return;
}
}
-
+if (cpu->cfg.vext_spec) {
+if (!g_strcmp0(cpu->cfg.vext_spec, "v0.7.1")) {
+vext_version = VEXT_VERSION_0_07_1;
+} else {
+error_setg(errp,
+ "Unsupported vector spec version '%s'",
+ cpu->cfg.vext_spec);
+return;
+}
+}
set_priv_version(env, priv_version);
+set_vext_version(env, vext_version);
set_resetvec(env, DEFAULT_RSTVEC);
if (cpu->cfg.mmu) {
@@ -406,6 +422,24 @@ static void riscv_cpu_realize(DeviceState *dev, Error
**errp)
if (cpu->cfg.ext_u) {
target_misa |= RVU;
}
+if (cpu->cfg.ext_v) {
+target_misa |= RVV;
+if (!is_power_of_2(cpu->cfg.vlen)) {
+error_setg(errp,
+ "Vector extension VLEN must be power of 2");
+return;
+}
+if (cpu->cfg.vlen > RV_VLEN_MAX) {
+error_setg(errp,
+ "Vector extension VLEN must <= %d", RV_VLEN_MAX);
+return;
+}
+if (!is_power_of_2(cpu->cfg.elen)) {
+error_setg(errp,
+ "Vector extension ELEN must be power of 2");
+return;
+}
+}
set_misa(env, RVXLEN | target_misa);
}
@@ -441,10 +475,14 @@ static Property riscv_cpu_properties[] = {
DEFINE_PROP_BOOL("c", RISCVCPU, cfg.ext_c, true),
DEFINE_PROP_BOOL("s", RISCVCPU, cfg.ext_s, true),
DEFINE_PROP_BOOL("u", RISCVCPU, cfg.ext_u, true),
+DEFINE_PROP_BOOL("v", RISCVCPU, cfg.ext_v, false),
DEFINE_PROP_BOOL("Counters", RISCVCPU, cfg.ext_counters, true),
DEFINE_PROP_BOOL("Zifencei", RISCVCPU, cfg.ext_ifencei, true),
DEFINE_PROP_BOOL("Zicsr", RISCVCPU, cfg.ext_icsr, true),
DEFINE_PROP_STRING("priv_spec", RISCVCPU, cfg.priv_spec),
+DEFINE_PROP_STRING("vext_spec", RISCVCPU, cfg.vext_spec),
+DEFINE_PROP_UINT16("vlen", RISCVCPU, cfg.vlen, 128),
+DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
DEFINE_PROP_END_OF_LIST(),
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index af66674461..d0b106583a 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -64,6 +64,7 @@
#define RVA RV('A')
#define RVF RV('F')
#define RVD RV('D')
+#define RVV RV('V')
#define RVC RV('C')
#define RVS RV('S')
#define RVU RV('U')
@@ -82,6 +83,8 @@ enum {
#define PRIV_VERSION_1_10_0 0x00011000
#define PRIV_VERSION_1_11_0 0x00011100
+#define VEXT_VERSION_0_07_1 0x0071
+
#define TRANSLATE_PMP_FAIL 2
#define TRANSLATE_FAIL 1
#define TRANSLATE_SUCCESS 0
@@ -119,6 +122,7 @@ struct CPURISCVState {
target_ulong badaddr;
target_ulong priv_ver;
+target_ulong vext_ver;
target_ulong misa;
target_ulong misa_mask;
@@ -236,12 +240,16 @@ typedef struct RISCVCPU {
bool ext_c;
bool ext_s;
bool ext_u;
+bool ext_v;
bool
[PATCH v3 1/4] RISC-V: add vector extension field in CPURISCVState
The 32 vector registers will be viewed as a continuous memory block.
It avoids the convension between element index and (regno,offset).
Thus elements can be directly accessed by offset from the first vector
base address.
Signed-off-by: LIU Zhiwei
---
target/riscv/cpu.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0adb307f32..af66674461 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -93,9 +93,23 @@ typedef struct CPURISCVState CPURISCVState;
#include "pmp.h"
+#define RV_VLEN_MAX 4096
+
struct CPURISCVState {
target_ulong gpr[32];
uint64_t fpr[32]; /* assume both F and D extensions */
+
+/* vector coprocessor state. */
+struct {
+ uint64_t vreg[32 * RV_VLEN_MAX / 64];
+ target_ulong vxrm;
+ target_ulong vxsat;
+ target_ulong vl;
+ target_ulong vstart;
+ target_ulong vtype;
+} vext;
+
+bool foflag;
target_ulong pc;
target_ulong load_res;
target_ulong load_val;
--
2.23.0
[PATCH v3 0/4] RISC-V: support vector extension part 1
This is the first part of v3 patchset. The changelog of v3 is only coverd
the part1.
Features:
* support specification riscv-v-spec-0.7.1.
* support basic vector extension.
* support Zvlsseg.
* support Zvamo.
* not support Zvediv as it is changing.
* fixed SLEN 128bit.
* element width support 8bit, 16bit, 32bit, 64bit.
Changelog:
v3
* support VLEN configure from qemu command line.
* support ELEN configure from qemu command line.
* support vector specification version configure from qemu command line.
* only default on for "any" cpu, others turn on from command line.
* use a continous memory block for vector register description.
V2
* use float16_compare{_quiet}
* only use GETPC() in outer most helper
* add ctx.ext_v Property
LIU Zhiwei (4):
RISC-V: add vector extension field in CPURISCVState
RISC-V: configure and turn on vector extension from command line
RISC-V: support vector extension csr
RISC-V: add vector extension configure instruction
target/riscv/Makefile.objs | 2 +-
target/riscv/cpu.c | 43 +++-
target/riscv/cpu.h | 77 ++---
target/riscv/cpu_bits.h | 15
target/riscv/csr.c | 92 +
target/riscv/helper.h | 2 +
target/riscv/insn32.decode | 5 ++
target/riscv/insn_trans/trans_rvv.inc.c | 52 ++
target/riscv/translate.c| 17 -
target/riscv/vector_helper.c| 51 ++
10 files changed, 314 insertions(+), 42 deletions(-)
create mode 100644 target/riscv/insn_trans/trans_rvv.inc.c
create mode 100644 target/riscv/vector_helper.c
--
2.23.0
[PATCH v3 4/4] RISC-V: add vector extension configure instruction
vsetvl and vsetvli are two configure instructions for vl, vtype. TB flags
should update after configure instructions. The (ill, lmul, sew ) of vtype
and the bit of (VSTART == 0 && VL == VLMAX) will be placed within tb_flags.
Signed-off-by: LIU Zhiwei
---
target/riscv/Makefile.objs | 2 +-
target/riscv/cpu.c | 1 +
target/riscv/cpu.h | 55 -
target/riscv/helper.h | 2 +
target/riscv/insn32.decode | 5 +++
target/riscv/insn_trans/trans_rvv.inc.c | 52 +++
target/riscv/translate.c| 17 +++-
target/riscv/vector_helper.c| 51 +++
8 files changed, 172 insertions(+), 13 deletions(-)
create mode 100644 target/riscv/insn_trans/trans_rvv.inc.c
create mode 100644 target/riscv/vector_helper.c
diff --git a/target/riscv/Makefile.objs b/target/riscv/Makefile.objs
index b1c79bc1d1..d577cef9e0 100644
--- a/target/riscv/Makefile.objs
+++ b/target/riscv/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o
gdbstub.o pmp.o
+obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o
vector_helper.o gdbstub.o pmp.o
DECODETREE = $(SRC_PATH)/scripts/decodetree.py
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index c2370a0a57..3ff7b50bff 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -347,6 +347,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error
**errp)
}
}
if (cpu->cfg.vext_spec) {
+env->vext.vtype = ~((target_ulong)-1 >> 1);
if (!g_strcmp0(cpu->cfg.vext_spec, "v0.7.1")) {
vext_version = VEXT_VERSION_0_07_1;
} else {
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index d0b106583a..152a96f1fa 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -23,6 +23,7 @@
#include "qom/cpu.h"
#include "exec/cpu-defs.h"
#include "fpu/softfloat.h"
+#include "hw/registerfields.h"
#define TCG_GUEST_DEFAULT_MO 0
@@ -98,6 +99,20 @@ typedef struct CPURISCVState CPURISCVState;
#define RV_VLEN_MAX 4096
+struct VTYPE {
+#ifdef HOST_WORDS_BIGENDIAN
+target_ulong vill:1;
+target_ulong reserved:sizeof(target_ulong) * 8 - 7;
+target_ulong sew:3;
+target_ulong lmul:2;
+#else
+target_ulong lmul:2;
+target_ulong sew:3;
+target_ulong reserved:sizeof(target_ulong) * 8 - 7;
+target_ulong vill:1;
+#endif
+};
+
struct CPURISCVState {
target_ulong gpr[32];
uint64_t fpr[32]; /* assume both F and D extensions */
@@ -309,19 +324,44 @@ void QEMU_NORETURN riscv_raise_exception(CPURISCVState
*env,
target_ulong riscv_cpu_get_fflags(CPURISCVState *env);
void riscv_cpu_set_fflags(CPURISCVState *env, target_ulong);
-#define TB_FLAGS_MMU_MASK 3
-#define TB_FLAGS_MSTATUS_FS MSTATUS_FS
+typedef CPURISCVState CPUArchState;
+typedef RISCVCPU ArchCPU;
+#include "exec/cpu-all.h"
+
+FIELD(TB_FLAGS, MMU, 0, 2)
+FIELD(TB_FLAGS, FS, 13, 2)
+FIELD(TB_FLAGS, VL_EQ_VLMAX, 16, 1)
+FIELD(TB_FLAGS, LMUL, 17, 2)
+FIELD(TB_FLAGS, SEW, 19, 3)
+FIELD(TB_FLAGS, VILL, 22, 1)
static inline void cpu_get_tb_cpu_state(CPURISCVState *env, target_ulong *pc,
-target_ulong *cs_base, uint32_t *flags)
+target_ulong *cs_base, uint32_t
*pflags)
{
+RISCVCPU *cpu = env_archcpu(env);
+struct VTYPE *vtype = (struct VTYPE *)&env->vext.vtype;
+uint32_t vlmax;
+uint8_t vl_eq_vlmax;
+uint32_t flags = 0;
+
*pc = env->pc;
*cs_base = 0;
+vlmax = (1 << vtype->lmul) * cpu->cfg.vlen / (8 * (1 << vtype->sew));
+vl_eq_vlmax = (env->vext.vstart == 0) && (vlmax == env->vext.vl);
+
+flags = FIELD_DP32(flags, TB_FLAGS, VILL, vtype->vill);
+flags = FIELD_DP32(flags, TB_FLAGS, SEW, vtype->sew);
+flags = FIELD_DP32(flags, TB_FLAGS, LMUL, vtype->lmul);
+flags = FIELD_DP32(flags, TB_FLAGS, VL_EQ_VLMAX, vl_eq_vlmax);
+
#ifdef CONFIG_USER_ONLY
-*flags = TB_FLAGS_MSTATUS_FS;
+flags = FIELD_DP32(flags, TB_FLAGS, FS, MSTATUS_FS);
#else
-*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
+flags = FIELD_DP32(flags, TB_FLAGS, MMU, cpu_mmu_index(env, 0));
+flags = FIELD_DP32(flags, TB_FLAGS, FS, (env->mstatus & MSTATUS_FS));
#endif
+*pflags = flags;
+*cs_base = 0;
}
int riscv_csrrw(CPURISCVState *env, int csrno, target_ulong *ret_value,
@@ -362,9 +402,4 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations
*ops);
void riscv_cpu_register_gdb_regs_for_features(CPUState *cs);
-typedef CPURISCVState CPUArchState;
-typedef RISCVCPU ArchCPU;
-
-#include "exec/cpu-all.h"
-
#endif /* RISCV_CPU_H */
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index debb22a480..000b5aa3d1 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -76,3 +76,5 @@ DEF_HELPER_2(mret, tl, env, tl)
DEF_HELPER_1(wfi, void, env)
DEF_HELPER_1(tlb_fl
Re: [PATCH v2 4/4] configure: Remove tcg/ from the preprocessor include search list
On Wed, Jan 1, 2020 at 3:25 AM Philippe Mathieu-Daudé wrote: > > All tcg includes are relative to the repository root directory, > we can safely remove the tcg/ directory from the include search > path list. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alistair Francis Alistair > --- > configure | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configure b/configure > index 940bf9e87a..74dad08580 100755 > --- a/configure > +++ b/configure > @@ -7436,7 +7436,6 @@ elif test "$ARCH" = "riscv32" || test "$ARCH" = > "riscv64" ; then > else >QEMU_INCLUDES="-iquote \$(SRC_PATH)/tcg/\$(ARCH) $QEMU_INCLUDES" > fi > -QEMU_INCLUDES="-iquote \$(SRC_PATH)/tcg $QEMU_INCLUDES" > > echo "TOOLS=$tools" >> $config_host_mak > echo "ROMS=$roms" >> $config_host_mak > -- > 2.21.0 > >
Re: [PATCH v2 2/4] tcg: Search includes in the parent source directory
On Wed, Jan 1, 2020 at 3:24 AM Philippe Mathieu-Daudé wrote:
>
> All the *.inc.c files included by tcg/$TARGET/tcg-target.inc.c
> are in tcg/, their parent directory. To simplify the preprocessor
> search path, include the relative parent path: '..'.
>
> Patch created mechanically by running:
>
> $ for x in tcg-pool.inc.c tcg-ldst.inc.c; do \
> sed -i "s,#include \"$x\",#include \"../$x\"," \
> $(git grep -l "#include \"$x\""); \
> done
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> tcg/aarch64/tcg-target.inc.c | 4 ++--
> tcg/arm/tcg-target.inc.c | 4 ++--
> tcg/i386/tcg-target.inc.c| 4 ++--
> tcg/mips/tcg-target.inc.c| 2 +-
> tcg/ppc/tcg-target.inc.c | 4 ++--
> tcg/riscv/tcg-target.inc.c | 4 ++--
> tcg/s390/tcg-target.inc.c| 4 ++--
> tcg/sparc/tcg-target.inc.c | 2 +-
> 8 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/tcg/aarch64/tcg-target.inc.c b/tcg/aarch64/tcg-target.inc.c
> index 3f921015d3..843fd0ca69 100644
> --- a/tcg/aarch64/tcg-target.inc.c
> +++ b/tcg/aarch64/tcg-target.inc.c
> @@ -10,7 +10,7 @@
> * See the COPYING file in the top-level directory for details.
> */
>
> -#include "tcg-pool.inc.c"
> +#include "../tcg-pool.inc.c"
> #include "qemu/bitops.h"
>
> /* We're going to re-use TCGType in setting of the SF bit, which controls
> @@ -1541,7 +1541,7 @@ static void tcg_out_cltz(TCGContext *s, TCGType ext,
> TCGReg d,
> }
>
> #ifdef CONFIG_SOFTMMU
> -#include "tcg-ldst.inc.c"
> +#include "../tcg-ldst.inc.c"
>
> /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
> * TCGMemOpIdx oi, uintptr_t ra)
> diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
> index 94d80d79d1..fffb6611e2 100644
> --- a/tcg/arm/tcg-target.inc.c
> +++ b/tcg/arm/tcg-target.inc.c
> @@ -23,7 +23,7 @@
> */
>
> #include "elf.h"
> -#include "tcg-pool.inc.c"
> +#include "../tcg-pool.inc.c"
>
> int arm_arch = __ARM_ARCH;
>
> @@ -1131,7 +1131,7 @@ static TCGCond tcg_out_cmp2(TCGContext *s, const TCGArg
> *args,
> }
>
> #ifdef CONFIG_SOFTMMU
> -#include "tcg-ldst.inc.c"
> +#include "../tcg-ldst.inc.c"
>
> /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
> * int mmu_idx, uintptr_t ra)
> diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
> index 9d8ed974e0..cdedcb2b25 100644
> --- a/tcg/i386/tcg-target.inc.c
> +++ b/tcg/i386/tcg-target.inc.c
> @@ -22,7 +22,7 @@
> * THE SOFTWARE.
> */
>
> -#include "tcg-pool.inc.c"
> +#include "../tcg-pool.inc.c"
>
> #ifdef CONFIG_DEBUG_TCG
> static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
> @@ -1647,7 +1647,7 @@ static void tcg_out_nopn(TCGContext *s, int n)
> }
>
> #if defined(CONFIG_SOFTMMU)
> -#include "tcg-ldst.inc.c"
> +#include "../tcg-ldst.inc.c"
>
> /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
> * int mmu_idx, uintptr_t ra)
> diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
> index 5442167045..1da663ce84 100644
> --- a/tcg/mips/tcg-target.inc.c
> +++ b/tcg/mips/tcg-target.inc.c
> @@ -1107,7 +1107,7 @@ static void tcg_out_call(TCGContext *s, tcg_insn_unit
> *arg)
> }
>
> #if defined(CONFIG_SOFTMMU)
> -#include "tcg-ldst.inc.c"
> +#include "../tcg-ldst.inc.c"
>
> static void * const qemu_ld_helpers[16] = {
> [MO_UB] = helper_ret_ldub_mmu,
> diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
> index d308d69aba..ee1f9227c1 100644
> --- a/tcg/ppc/tcg-target.inc.c
> +++ b/tcg/ppc/tcg-target.inc.c
> @@ -23,7 +23,7 @@
> */
>
> #include "elf.h"
> -#include "tcg-pool.inc.c"
> +#include "../tcg-pool.inc.c"
>
> #if defined _CALL_DARWIN || defined __APPLE__
> #define TCG_TARGET_CALL_DARWIN
> @@ -1845,7 +1845,7 @@ static const uint32_t qemu_exts_opc[4] = {
> };
>
> #if defined (CONFIG_SOFTMMU)
> -#include "tcg-ldst.inc.c"
> +#include "../tcg-ldst.inc.c"
>
> /* helper signature: helper_ld_mmu(CPUState *env, target_ulong addr,
> * int mmu_idx, uintptr_t ra)
> diff --git a/tcg/riscv/tcg-target.inc.c b/tcg/riscv/tcg-target.inc.c
> index 7018509693..2bc0ba71f2 100644
> --- a/tcg/riscv/tcg-target.inc.c
> +++ b/tcg/riscv/tcg-target.inc.c
> @@ -27,7 +27,7 @@
> * THE SOFTWARE.
> */
>
> -#include "tcg-pool.inc.c"
> +#include "../tcg-pool.inc.c"
>
> #ifdef CONFIG_DEBUG_TCG
> static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
> @@ -921,7 +921,7 @@ static void tcg_out_mb(TCGContext *s, TCGArg a0)
> */
>
> #if defined(CONFIG_SOFTMMU)
> -#include "tcg-ldst.inc.c"
> +#include "../tcg-ldst.inc.c"
>
> /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
> * TCGMemOpIdx oi, uintptr_t ra)
> diff --git a/tcg/s390/tcg-target.inc.c b/tcg/s390/tcg-target.inc.c
> index 8aaa4cebe8..b07e9ff7d
Re: [PATCH v2 3/4] tcg: Move TCG headers to include/tcg/
On Wed, Jan 1, 2020 at 3:27 AM Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> {tcg => include/tcg}/tcg-gvec-desc.h | 0
> {tcg => include/tcg}/tcg-mo.h| 0
> {tcg => include/tcg}/tcg-op-gvec.h | 0
> {tcg => include/tcg}/tcg-op.h| 0
> {tcg => include/tcg}/tcg-opc.h | 0
> {tcg => include/tcg}/tcg.h | 0
> MAINTAINERS | 1 +
> 7 files changed, 1 insertion(+)
> rename {tcg => include/tcg}/tcg-gvec-desc.h (100%)
> rename {tcg => include/tcg}/tcg-mo.h (100%)
> rename {tcg => include/tcg}/tcg-op-gvec.h (100%)
> rename {tcg => include/tcg}/tcg-op.h (100%)
> rename {tcg => include/tcg}/tcg-opc.h (100%)
> rename {tcg => include/tcg}/tcg.h (100%)
>
> diff --git a/tcg/tcg-gvec-desc.h b/include/tcg/tcg-gvec-desc.h
> similarity index 100%
> rename from tcg/tcg-gvec-desc.h
> rename to include/tcg/tcg-gvec-desc.h
> diff --git a/tcg/tcg-mo.h b/include/tcg/tcg-mo.h
> similarity index 100%
> rename from tcg/tcg-mo.h
> rename to include/tcg/tcg-mo.h
> diff --git a/tcg/tcg-op-gvec.h b/include/tcg/tcg-op-gvec.h
> similarity index 100%
> rename from tcg/tcg-op-gvec.h
> rename to include/tcg/tcg-op-gvec.h
> diff --git a/tcg/tcg-op.h b/include/tcg/tcg-op.h
> similarity index 100%
> rename from tcg/tcg-op.h
> rename to include/tcg/tcg-op.h
> diff --git a/tcg/tcg-opc.h b/include/tcg/tcg-opc.h
> similarity index 100%
> rename from tcg/tcg-opc.h
> rename to include/tcg/tcg-opc.h
> diff --git a/tcg/tcg.h b/include/tcg/tcg.h
> similarity index 100%
> rename from tcg/tcg.h
> rename to include/tcg/tcg.h
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 387879aebc..02e1490895 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2374,6 +2374,7 @@ Common TCG code
> M: Richard Henderson
> S: Maintained
> F: tcg/
> +F: include/tcg/
>
> TCG Plugins
> M: Alex Bennée
> --
> 2.21.0
>
>
Re: [PATCH v2 1/4] tcg: Search includes from the project root source directory
On Wed, Jan 1, 2020 at 3:24 AM Philippe Mathieu-Daudé wrote:
>
> We currently search both the root and the tcg/ directories for tcg
> files:
>
> $ git grep '#include "tcg/' | wc -l
> 28
>
> $ git grep '#include "tcg[^/]' | wc -l
> 94
>
> To simplify the preprocessor search path, unify by expliciting the
> tcg/ directory.
>
> Patch created mechanically by running:
>
> $ for x in \
> tcg.h tcg-mo.h tcg-op.h tcg-opc.h \
> tcg-op-gvec.h tcg-gvec-desc.h; do \
> sed -i "s,#include \"$x\",#include \"tcg/$x\"," \
> $(git grep -l "#include \"$x\""); \
> done
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> ---
> include/exec/cpu_ldst.h | 2 +-
> tcg/i386/tcg-target.h | 2 +-
> tcg/tcg-op.h | 2 +-
> tcg/tcg.h | 4 ++--
> accel/tcg/cpu-exec.c | 2 +-
> accel/tcg/tcg-runtime-gvec.c | 2 +-
> accel/tcg/translate-all.c | 2 +-
> accel/tcg/user-exec.c | 2 +-
> bsd-user/main.c | 2 +-
> cpus.c| 2 +-
> exec.c| 2 +-
> linux-user/main.c | 2 +-
> target/alpha/translate.c | 2 +-
> target/arm/helper-a64.c | 2 +-
> target/arm/translate-a64.c| 4 ++--
> target/arm/translate-sve.c| 6 +++---
> target/arm/translate.c| 4 ++--
> target/cris/translate.c | 2 +-
> target/hppa/translate.c | 2 +-
> target/i386/mem_helper.c | 2 +-
> target/i386/translate.c | 2 +-
> target/lm32/translate.c | 2 +-
> target/m68k/translate.c | 2 +-
> target/microblaze/translate.c | 2 +-
> target/mips/translate.c | 2 +-
> target/moxie/translate.c | 2 +-
> target/nios2/translate.c | 2 +-
> target/openrisc/translate.c | 2 +-
> target/ppc/mem_helper.c | 2 +-
> target/ppc/translate.c| 4 ++--
> target/riscv/cpu_helper.c | 2 +-
> target/riscv/translate.c | 2 +-
> target/s390x/translate.c | 4 ++--
> target/sh4/translate.c| 2 +-
> target/sparc/ldst_helper.c| 2 +-
> target/sparc/translate.c | 2 +-
> target/tilegx/translate.c | 2 +-
> target/tricore/translate.c| 2 +-
> target/unicore32/translate.c | 2 +-
> target/xtensa/translate.c | 2 +-
> tcg/optimize.c| 2 +-
> tcg/tcg-common.c | 2 +-
> tcg/tcg-op-gvec.c | 8
> tcg/tcg-op-vec.c | 6 +++---
> tcg/tcg-op.c | 6 +++---
> tcg/tcg.c | 2 +-
> tcg/tci.c | 2 +-
> 47 files changed, 61 insertions(+), 61 deletions(-)
>
> diff --git a/include/exec/cpu_ldst.h b/include/exec/cpu_ldst.h
> index fd499f7e2f..9c637f6e89 100644
> --- a/include/exec/cpu_ldst.h
> +++ b/include/exec/cpu_ldst.h
> @@ -153,7 +153,7 @@ static inline void clear_helper_retaddr(void)
> #else
>
> /* The memory helpers for tcg-generated code need tcg_target_long etc. */
> -#include "tcg.h"
> +#include "tcg/tcg.h"
>
> static inline target_ulong tlb_addr_write(const CPUTLBEntry *entry)
> {
> diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
> index 928e8b87bb..bfb3f5f6e9 100644
> --- a/tcg/i386/tcg-target.h
> +++ b/tcg/i386/tcg-target.h
> @@ -223,7 +223,7 @@ static inline void tb_target_set_jmp_target(uintptr_t
> tc_ptr,
> * The x86 has a pretty strong memory ordering which only really
> * allows for some stores to be re-ordered after loads.
> */
> -#include "tcg-mo.h"
> +#include "tcg/tcg-mo.h"
>
> #define TCG_TARGET_DEFAULT_MO (TCG_MO_ALL & ~TCG_MO_ST_LD)
>
> diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
> index 4af272daa5..230db6e022 100644
> --- a/tcg/tcg-op.h
> +++ b/tcg/tcg-op.h
> @@ -25,7 +25,7 @@
> #ifndef TCG_TCG_OP_H
> #define TCG_TCG_OP_H
>
> -#include "tcg.h"
> +#include "tcg/tcg.h"
> #include "exec/helper-proto.h"
> #include "exec/helper-gen.h"
>
> diff --git a/tcg/tcg.h b/tcg/tcg.h
> index 92ca10dffc..bb59027240 100644
> --- a/tcg/tcg.h
> +++ b/tcg/tcg.h
> @@ -31,7 +31,7 @@
> #include "qemu/bitops.h"
> #include "qemu/plugin.h"
> #include "qemu/queue.h"
> -#include "tcg-mo.h"
> +#include "tcg/tcg-mo.h"
> #include "tcg-target.h"
> #include "qemu/int128.h"
>
> @@ -211,7 +211,7 @@ typedef uint64_t TCGRegSet;
>
> typedef enum TCGOpcode {
> #define DEF(name, oargs, iargs, cargs, flags) INDEX_op_ ## name,
> -#include "tcg-opc.h"
> +#include "tcg/tcg-opc.h"
> #undef DEF
> NB_OPS,
> } TCGOpcode;
> diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
> index 62068d10c3..2560c90eec 100644
> --- a/accel/tcg/cpu-exec.c
> +++ b/accel/tcg/cpu-exec.c
> @@ -23,7 +23,7 @@
> #include "trace.h"
> #include "disas/disas.h"
> #include "exec/exec-all.h"
> -#include "tcg.h"
> +#include "tcg/tcg.h"
> #include "qemu/atomic.h"
> #include "sysemu/qtest.h"
> #include "qemu/timer.h"
> diff --git a/accel/tcg/tcg-runtime-gvec.c b/accel/tcg/tcg-runtime-gvec.c
> index 51cb29ca79..5b1902d591 100644
> --- a/accel/tcg/tcg-runtime-gvec.c
> +
Re: [PATCH v18 6/7] migration: Include migration support for machine check handling
On Thu, Jan 02, 2020 at 01:21:10PM +0530, Ganesh Goudar wrote:
> From: Aravinda Prasad
>
> This patch includes migration support for machine check
> handling. Especially this patch blocks VM migration
> requests until the machine check error handling is
> complete as these errors are specific to the source
> hardware and is irrelevant on the target hardware.
>
> [Do not set FWNMI cap in post_load, now its done in .apply hook]
> Signed-off-by: Ganesh Goudar
> Signed-off-by: Aravinda Prasad
> ---
> hw/ppc/spapr.c | 41 +
> hw/ppc/spapr_events.c | 20 +++-
> hw/ppc/spapr_rtas.c| 4
> include/hw/ppc/spapr.h | 1 +
> 4 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 975d7da734..4acdc30100 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -46,6 +46,7 @@
> #include "migration/qemu-file-types.h"
> #include "migration/global_state.h"
> #include "migration/register.h"
> +#include "migration/blocker.h"
> #include "mmu-hash64.h"
> #include "mmu-book3s-v3.h"
> #include "cpu-models.h"
> @@ -1685,6 +1686,8 @@ static void spapr_machine_reset(MachineState *machine)
>
> /* Signal all vCPUs waiting on this condition */
> qemu_cond_broadcast(&spapr->mc_delivery_cond);
> +
> +migrate_del_blocker(spapr->fwnmi_migration_blocker);
> }
>
> static void spapr_create_nvram(SpaprMachineState *spapr)
> @@ -1967,6 +1970,43 @@ static const VMStateDescription vmstate_spapr_dtb = {
> },
> };
>
> +static bool spapr_fwnmi_needed(void *opaque)
> +{
> +SpaprMachineState *spapr = (SpaprMachineState *)opaque;
> +
> +return spapr->fwnmi_calls_registered;
I think it would be better to base this directly on the cap, rather
than a variable set later.
> +}
> +
> +static int spapr_fwnmi_pre_save(void *opaque)
> +{
> +SpaprMachineState *spapr = (SpaprMachineState *)opaque;
> +
> +/*
> + * Check if machine check handling is in progress and print a
> + * warning message.
> + */
> +if (spapr->mc_status != -1) {
> +warn_report("A machine check is being handled during migration. The"
> +"handler may run and log hardware error on the destination");
> +}
> +
> +return 0;
> +}
> +
> +static const VMStateDescription vmstate_spapr_machine_check = {
> +.name = "spapr_machine_check",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = spapr_fwnmi_needed,
> +.pre_save = spapr_fwnmi_pre_save,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT64(guest_machine_check_addr, SpaprMachineState),
> +VMSTATE_INT32(mc_status, SpaprMachineState),
> +VMSTATE_BOOL(fwnmi_calls_registered, SpaprMachineState),
This doesn't make sense to migrate - it will always have its final
value by the time the guest is running in a migratable state.
> +VMSTATE_END_OF_LIST()
> +},
> +};
> +
> static const VMStateDescription vmstate_spapr = {
> .name = "spapr",
> .version_id = 3,
> @@ -2001,6 +2041,7 @@ static const VMStateDescription vmstate_spapr = {
> &vmstate_spapr_cap_large_decr,
> &vmstate_spapr_cap_ccf_assist,
> &vmstate_spapr_cap_fwnmi,
> +&vmstate_spapr_machine_check,
> NULL
> }
> };
> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> index 54eaf28a9e..7092687fa0 100644
> --- a/hw/ppc/spapr_events.c
> +++ b/hw/ppc/spapr_events.c
> @@ -43,6 +43,7 @@
> #include "qemu/main-loop.h"
> #include "hw/ppc/spapr_ovec.h"
> #include
> +#include "migration/blocker.h"
>
> #define RTAS_LOG_VERSION_MASK 0xff00
> #define RTAS_LOG_VERSION_60x0600
> @@ -843,6 +844,8 @@ void spapr_mce_req_event(PowerPCCPU *cpu, bool recovered)
> {
> SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> CPUState *cs = CPU(cpu);
> +int ret;
> +Error *local_err = NULL;
>
> if (spapr->guest_machine_check_addr == -1) {
> /*
> @@ -872,8 +875,23 @@ void spapr_mce_req_event(PowerPCCPU *cpu, bool recovered)
> return;
> }
> }
> -spapr->mc_status = cpu->vcpu_id;
>
> +error_setg(&spapr->fwnmi_migration_blocker,
> + "Live migration not supported during machine check handling");
> +ret = migrate_add_blocker(spapr->fwnmi_migration_blocker, &local_err);
> +if (ret == -EBUSY) {
> +/*
> + * We don't want to abort so we let the migration to continue.
> + * In a rare case, the machine check handler will run on the target.
> + * Though this is not preferable, it is better than aborting
> + * the migration or killing the VM.
> + */
> +error_free(spapr->fwnmi_migration_blocker);
> +spapr->fwnmi_migration_blocker = NULL;
> +warn_report("Received a fwnmi while migration was in progress");
Didn't we change from initializing the blocker Erro
Re: [PATCH v4 4/4] spapr: Add Hcalls to support PAPR NVDIMM device
On Tue, Dec 17, 2019 at 02:49:36AM -0600, Shivaprasad G Bhat wrote:
> This patch implements few of the necessary hcalls for the nvdimm support.
>
> PAPR semantics is such that each NVDIMM device is comprising of multiple
> SCM(Storage Class Memory) blocks. The guest requests the hypervisor to
> bind each of the SCM blocks of the NVDIMM device using hcalls. There can
> be SCM block unbind requests in case of driver errors or unplug(not
> supported now) use cases. The NVDIMM label read/writes are done through
> hcalls.
>
> Since each virtual NVDIMM device is divided into multiple SCM blocks,
> the bind, unbind, and queries using hcalls on those blocks can come
> independently. This doesn't fit well into the qemu device semantics,
> where the map/unmap are done at the (whole)device/object level granularity.
> The patch doesnt actually bind/unbind on hcalls but let it happen at the
> device_add/del phase itself instead.
>
> The guest kernel makes bind/unbind requests for the virtual NVDIMM device
> at the region level granularity. Without interleaving, each virtual NVDIMM
> device is presented as a separate guest physical address range. So, there
> is no way a partial bind/unbind request can come for the vNVDIMM in a
> hcall for a subset of SCM blocks of a virtual NVDIMM. Hence it is safe to
> do bind/unbind everything during the device_add/del.
>
> Signed-off-by: Shivaprasad G Bhat
> ---
> hw/ppc/Makefile.objs |2
> hw/ppc/spapr_nvdimm.c | 337
>
> include/hw/ppc/spapr.h |8 +
> 3 files changed, 345 insertions(+), 2 deletions(-)
> create mode 100644 hw/ppc/spapr_nvdimm.c
>
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 580bb4f0dd..0366020ef9 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -5,7 +5,7 @@ obj-$(CONFIG_PSERIES) += spapr.o spapr_caps.o spapr_vio.o
> spapr_events.o
> obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
> obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
> obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
> -obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
> +obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o spapr_nvdimm.o
> obj-$(CONFIG_SPAPR_RNG) += spapr_rng.o
> # IBM PowerNV
> obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o
> pnv_occ.o pnv_bmc.o
> diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
> new file mode 100644
> index 00..4a3f796597
> --- /dev/null
> +++ b/hw/ppc/spapr_nvdimm.c
> @@ -0,0 +1,337 @@
> +/*
> + * QEMU PAPR Storage Class Memory Interfaces
> + *
> + * Copyright (c) 2019, IBM Corporation.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "hw/ppc/spapr.h"
> +#include "hw/ppc/spapr_drc.h"
> +#include "hw/mem/nvdimm.h"
> +#include "qemu/range.h"
> +#include "qemu/nvdimm-utils.h"
> +
> +static target_ulong h_scm_read_metadata(PowerPCCPU *cpu,
> +SpaprMachineState *spapr,
> +target_ulong opcode,
> +target_ulong *args)
> +{
> +uint32_t drc_index = args[0];
> +uint64_t offset = args[1];
> +uint64_t numBytesToRead = args[2];
> +SpaprDrc *drc = spapr_drc_by_index(drc_index);
> +NVDIMMDevice *nvdimm;
> +NVDIMMClass *ddc;
> +uint64_t data = 0;
> +uint8_t buf[8] = { 0 };
> +
> +if (!drc || !drc->dev ||
> +spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PMEM) {
> +return H_PARAMETER;
> +}
> +
> +if (numBytesToRead != 1 && numBytesToRead != 2 &&
> +numBytesToRead != 4 && numBytesToRead != 8) {
> +return H_P3;
> +}
> +
> +nvdimm = NVDIMM(drc->dev);
> +if ((offset + numBytesToRead < offset) ||
> +(nvdimm->label_size < numBytesToRead +
Re: [PATCH v18 5/7] ppc: spapr: Handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls
On Thu, Jan 02, 2020 at 01:21:09PM +0530, Ganesh Goudar wrote:
> From: Aravinda Prasad
>
> This patch adds support in QEMU to handle "ibm,nmi-register"
> and "ibm,nmi-interlock" RTAS calls.
>
> The machine check notification address is saved when the
> OS issues "ibm,nmi-register" RTAS call.
>
> This patch also handles the case when multiple processors
> experience machine check at or about the same time by
> handling "ibm,nmi-interlock" call. In such cases, as per
> PAPR, subsequent processors serialize waiting for the first
> processor to issue the "ibm,nmi-interlock" call. The second
> processor that also received a machine check error waits
> till the first processor is done reading the error log.
> The first processor issues "ibm,nmi-interlock" call
> when the error log is consumed.
>
> [Move fwnmi registration to .apply hook]
> Signed-off-by: Ganesh Goudar
> Signed-off-by: Aravinda Prasad
> ---
> hw/ppc/spapr_caps.c| 6 +
> hw/ppc/spapr_rtas.c| 58 ++
> include/hw/ppc/spapr.h | 7 -
> 3 files changed, 70 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index 3001098601..e922419cfb 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -502,6 +502,12 @@ static void cap_fwnmi_mce_apply(SpaprMachineState
> *spapr, uint8_t val,
> if (!val) {
> return; /* Disabled by default */
> }
> +
> +if (!spapr->fwnmi_calls_registered && !kvmppc_set_fwnmi()) {
So, we definitely need the kvmppc_set_fwnmi() call here. But in the
case where we *do* have KVM, but the call fails, we should fail the
.apply hook, rather than ignoring it silently.
As we've discussed although TCG behaviour with fwnmi isn't 100%
correct, it's close enough to pass for most purposes - so it's
reasonable to continue if the cap is selected. But if the cap is
selected and we're running with KVM we *must* enable the capability in
KVM or we're not providing the environment the user requested.
> +/* Register ibm,nmi-register and ibm,nmi-interlock RTAS calls */
> +spapr_fwnmi_register();
We discussed registering the hypercalls here, but I thought after that
I suggested just always registering them, and having them bail out
when called if the cap is not set. I see that you've implemented that
bailout for register, though not for interlock. I think that's
simpler than registering them here.
> +spapr->fwnmi_calls_registered = true;
> +}
> }
>
> SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index 2c066a372d..54b142f35b 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -400,6 +400,56 @@ static void rtas_get_power_level(PowerPCCPU *cpu,
> SpaprMachineState *spapr,
> rtas_st(rets, 1, 100);
> }
>
> +static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
> + SpaprMachineState *spapr,
> + uint32_t token, uint32_t nargs,
> + target_ulong args,
> + uint32_t nret, target_ulong rets)
> +{
> +hwaddr rtas_addr;
> +
> +if (spapr_get_cap(spapr, SPAPR_CAP_FWNMI_MCE) == SPAPR_CAP_OFF) {
> +rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
> +return;
> +}
> +
> +rtas_addr = spapr_get_rtas_addr();
> +if (!rtas_addr) {
> +rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
> +return;
> +}
> +
> +spapr->guest_machine_check_addr = rtas_ld(args, 1);
> +rtas_st(rets, 0, RTAS_OUT_SUCCESS);
> +}
> +
> +static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
> + SpaprMachineState *spapr,
> + uint32_t token, uint32_t nargs,
> + target_ulong args,
> + uint32_t nret, target_ulong rets)
> +{
> +if (spapr->guest_machine_check_addr == -1) {
> +/* NMI register not called */
> +rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
> +return;
> +}
> +
> +if (spapr->mc_status != cpu->vcpu_id) {
> +/* The vCPU that hit the NMI should invoke "ibm,nmi-interlock" */
> +rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
> +return;
> +}
> +
> +/*
> + * vCPU issuing "ibm,nmi-interlock" is done with NMI handling,
> + * hence unset mc_status.
> + */
> +spapr->mc_status = -1;
> +qemu_cond_signal(&spapr->mc_delivery_cond);
> +rtas_st(rets, 0, RTAS_OUT_SUCCESS);
> +}
> +
> static struct rtas_call {
> const char *name;
> spapr_rtas_fn fn;
> @@ -503,6 +553,14 @@ hwaddr spapr_get_rtas_addr(void)
> return (hwaddr)fdt32_to_cpu(*rtas_data);
> }
>
> +void spapr_fwnmi_register(void)
> +{
> +spapr_rtas_register(RTAS_IBM_NMI_REGISTER, "ibm,nmi-register",
> +rtas_ibm_nmi_register);
> +spapr_rtas_register(RTAS_IBM_NMI_INTE
Re: [PATCH v4 3/4] spapr: Add NVDIMM device support
On Tue, Dec 17, 2019 at 02:49:14AM -0600, Shivaprasad G Bhat wrote:
> Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
> device interface in QEMU to support virtual NVDIMM devices for Power.
> Create the required DT entries for the device (some entries have
> dummy values right now).
>
> The patch creates the required DT node and sends a hotplug
> interrupt to the guest. Guest is expected to undertake the normal
> DR resource add path in response and start issuing PAPR SCM hcalls.
>
> The device support is verified based on the machine version unlike x86.
>
> This is how it can be used ..
> Ex :
> For coldplug, the device to be added in qemu command line as shown below
> -object
> memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
> -device
> nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
>
> For hotplug, the device to be added from monitor as below
> object_add
> memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
> device_add
> nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
>
> Signed-off-by: Shivaprasad G Bhat
> Signed-off-by: Bharata B Rao
>[Early implementation]
> ---
> default-configs/ppc64-softmmu.mak |1
> hw/mem/Kconfig|2
> hw/ppc/spapr.c| 216
> ++---
> hw/ppc/spapr_drc.c| 18 +++
> hw/ppc/spapr_events.c |4 +
> include/hw/ppc/spapr.h| 11 ++
> include/hw/ppc/spapr_drc.h|9 ++
> 7 files changed, 245 insertions(+), 16 deletions(-)
>
> diff --git a/default-configs/ppc64-softmmu.mak
> b/default-configs/ppc64-softmmu.mak
> index cca52665d9..ae0841fa3a 100644
> --- a/default-configs/ppc64-softmmu.mak
> +++ b/default-configs/ppc64-softmmu.mak
> @@ -8,3 +8,4 @@ CONFIG_POWERNV=y
>
> # For pSeries
> CONFIG_PSERIES=y
> +CONFIG_NVDIMM=y
> diff --git a/hw/mem/Kconfig b/hw/mem/Kconfig
> index 620fd4cb59..2ad052a536 100644
> --- a/hw/mem/Kconfig
> +++ b/hw/mem/Kconfig
> @@ -8,4 +8,4 @@ config MEM_DEVICE
> config NVDIMM
> bool
> default y
> -depends on PC
> +depends on (PC || PSERIES)
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 3ae7db1563..921d8d7c8e 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -80,6 +80,8 @@
> #include "hw/ppc/spapr_cpu_core.h"
> #include "hw/mem/memory-device.h"
> #include "hw/ppc/spapr_tpm_proxy.h"
> +#include "hw/mem/nvdimm.h"
> +#include "qemu/nvdimm-utils.h"
>
> #include "monitor/monitor.h"
>
> @@ -685,12 +687,22 @@ static int spapr_populate_drmem_v2(SpaprMachineState
> *spapr, void *fdt,
> nr_entries++;
> }
>
> -/* Entry for DIMM */
> -drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
> -g_assert(drc);
> -elem = spapr_get_drconf_cell(size / lmb_size, addr,
> - spapr_drc_index(drc), node,
> - SPAPR_LMB_FLAGS_ASSIGNED);
> +if (info->value->type == MEMORY_DEVICE_INFO_KIND_DIMM) {
> +/* Entry for DIMM */
> +drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
> +g_assert(drc);
> +elem = spapr_get_drconf_cell(size / lmb_size, addr,
> + spapr_drc_index(drc), node,
> + SPAPR_LMB_FLAGS_ASSIGNED);
> +} else if (info->value->type == MEMORY_DEVICE_INFO_KIND_NVDIMM) {
> +/*
> + * NVDIMM sits here, let the DIMM LMBs be unusable here in the
> + * whole range
> + */
> +elem = spapr_get_drconf_cell(size / lmb_size, addr, 0, -1,
> + SPAPR_LMB_FLAGS_RESERVED |
> + SPAPR_LMB_FLAGS_DRC_INVALID);
> +}
As discussed in reply to an earlier thread, this whole scheme
basically breaks down in the presence of hotplug - it relies on which
GPAs are DIMMs and which are NVDIMMs not changing.
Other than that significant problem, the rest of this looks
reasonable.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v1 01/36] target/riscv: Convert MIP CSR to target_ulong
On Thu, Jan 2, 2020 at 10:18 AM Palmer Dabbelt wrote:
>
> On Mon, 09 Dec 2019 10:10:43 PST (-0800), Alistair Francis wrote:
> > The MIP CSR is a xlen CSR, it was only 32-bits to allow atomic access.
> > Now that we don't use atomics for MIP we can change this back to a xlen
> > CSR.
> >
> > Signed-off-by: Alistair Francis
> > ---
> > target/riscv/cpu.c | 2 +-
> > target/riscv/cpu.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index d37861a430..e521ebe2e1 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -224,7 +224,7 @@ static void riscv_cpu_dump_state(CPUState *cs, FILE *f,
> > int flags)
> > #ifndef CONFIG_USER_ONLY
> > qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mhartid ", env->mhartid);
> > qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mstatus ", env->mstatus);
> > -qemu_fprintf(f, " %s 0x%x\n", "mip ", env->mip);
> > +qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mip ", env->mip);
> > qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mie ", env->mie);
> > qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mideleg ", env->mideleg);
> > qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "medeleg ", env->medeleg);
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index e59343e13c..f889427869 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -121,7 +121,7 @@ struct CPURISCVState {
> > target_ulong mhartid;
> > target_ulong mstatus;
> >
> > -uint32_t mip;
> > +target_ulong mip;
> > uint32_t miclaim;
> >
> > target_ulong mie;
>
> Reviewed-by: Palmer Dabbelt
Thanks!
Can you just apply the patches from this series as they are reviewed?
Also, can you review this series :)
Alistair
Re: [PATCH v2 0/4] tcg: Include tcg files using tcg/ dirname, reduce cpp search path list
On 1/1/20 10:22 PM, Philippe Mathieu-Daudé wrote: > Noticed we could clean this while reviewing Richard patch last night: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg667606.html > > Since v1: > - moved headers to include/tcg/ (Paolo) > - include in .inc.c relative to parent (Stefan) > > v1: https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg05356.html > > Philippe Mathieu-Daudé (4): > tcg: Search includes from the project root source directory > tcg: Search includes in the parent source directory > tcg: Move TCG headers to include/tcg/ > configure: Remove tcg/ from the preprocessor include search list Reviewed-by: Richard Henderson Will queue shortly. r~
Re: [PATCH v3 2/3] spapr: Add NVDIMM device support
On Thu, Dec 12, 2019 at 02:22:56PM +0530, Shivaprasad G Bhat wrote: > > > On 12/11/2019 01:35 PM, Igor Mammedov wrote: > > On Wed, 11 Dec 2019 09:44:11 +0530 > > Shivaprasad G Bhat wrote: > > > > > On 12/06/2019 07:22 AM, David Gibson wrote: > > > > On Wed, Nov 27, 2019 at 09:50:54AM +0530, Bharata B Rao wrote: > > > > > On Fri, Nov 22, 2019 at 10:42 AM David Gibson > > > > > wrote: > > > > > > Ok. A number of queries about this. > > > > > > > > > > > > 1) The PAPR spec for ibm,dynamic-memory-v2 says that the first word > > > > > > in > > > > > > each entry is the number of LMBs, but for NVDIMMs you use the > > > > > > not-necessarily-equal scm_block_size instead. Does the NVDIMM > > > > > > amendment for PAPR really specify to use different block sizes for > > > > > > these cases? (In which case that's a really stupid spec decision, > > > > > > but > > > > > > that wouldn't surprise me at this point). > > > > > SCM block sizes can be different from LMB sizes, but here we enforce > > > > > that SCM device size (excluding metadata) to multiple of LMB size so > > > > > that we don't end up memory range that is not aligned to LMB size. > > > > Right, but it still doesn't make sense to use scm_block_size when you > > > > create the dynamic-memory-v2 property. > > > Right, I should use LMB size here as I will be creating holes here to > > > disallow DIMMs > > > to claim those LMBs marking them INVALID as Bharata Suggested before. > > > > > > >As far as the thing > > > > interpreting that goes, it *must* be LMB size, not SCM block size. If > > > > those are required to be the same at this point, you should use an > > > > assert(). > > > SCM block size should be a multiple for LMB size, need not be equal. > > > I'll add an assert > > > for that, checking if equal. There is no benefit I see as of now having > > > higher > > > SCM block size as the bind/unbind are already done before the bind hcall. > > > > > > > > > 2) Similarly, the ibm,dynamic-memory-v2 description says that the > > > > > > memory block described by the entry has a whole batch of contiguous > > > > > > DRCs starting at the DRC index given and continuing for #LMBs DRCs. > > > > > > For NVDIMMs it appears that you just have one DRC for the whole > > > > > > NVDIMM. Is that right? > > > > > One NVDIMM has one DRC, In our case, we need to mark the LMBs > > > > > corresponding to that address range in ibm,dynamic-memory-v2 as > > > > > reserved and invalid. > > > > Ok, that fits very weirdly with the DRC allocation for the rest of > > > > pluggable memory, but I suppose that's PAPR for you. > > > > > > > > Having these in together is very inscrutable though, and relies on a > > > > heap of non-obvious constraints about placement of DIMMs and NVDIMMs > > > > relative to each other. I really wonder if it would be better to have > > > > a completely different address range for the NVDIMMs. > > > The backend object for both DIMM and NVDIMM are memory-backend-* > > > and they use the address from the same space. Separating it would mean > > > using/introducing different backend object. I dont think we have a > > > choice here. > > What address-space(s) are are talking about here exactly? > > From my point of view memory-backend-* provides RAM block at > > some HVA, which shouldn't not have anything to do with how NVDIMM > > partitions and maps it to GPA. > > Ah, you are right! I got confused with the HVA. > > Nonetheless, I don't see a need for having vNVDIMM in different > guest physical address range as the existing code has support for marking > memory ranges distinctly for DIMM/NVDIMM. The problem is that the way you create the dynamic-memory-v2 property relies on knowing whether a GPA is DIMM or NVDIMM -but you can't in the presence of hotplug. Using the default address allocation, DIMMs and NVDIMMs are dynamically assigned addresses in the hotplug memory area. So, if you have an NVDIMM plugged at boot time, you'll mark that range of LMBs as invalid. If you then unplug it, and instead plug in a regular DIMM (before the guest has even tried to online the NVDIMM), it will probably use the same GPA range. You therefore need regular LMB DRCs for that range, and we have no way to communicate that to the guest. Similar problems if you go the other way (unplug DIMM, plug NVDIMM). > On another note, the x86 too does it the same way. There is no separate > range defined there. Yes, but AIUI, the way PC describes DIMMs and NVDIMMs in ACPI are pretty similar. In PAPR they are gratuitously different - we don't even have the concept of a DIMM, only the individual LMBs that go into it. The match between the DIMM backend and the PAPR LMB frontend is already pretty poor, covering NVDIMMs in the same range pushes it past breaking point. > > > > > > 3) You're not setting *any* extra flags on the entry. How is the > > > > > > guest supposed to know which are NVDIMM entries and which are > > > > > > regular > > > > > > DIMM entries?
Re: [PATCH v7 4/6] tpm_spapr: Support suspend and resume
On Thu, Dec 19, 2019 at 09:06:03AM -0500, Stefan Berger wrote:
> Extend the tpm_spapr frontend with VM suspend and resume support.
>
> Signed-off-by: Stefan Berger
> ---
> hw/tpm/tpm_spapr.c | 67 -
> hw/tpm/trace-events | 2 ++
> 2 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/hw/tpm/tpm_spapr.c b/hw/tpm/tpm_spapr.c
> index ab184fbb82..cf5c7851e7 100644
> --- a/hw/tpm/tpm_spapr.c
> +++ b/hw/tpm/tpm_spapr.c
> @@ -76,6 +76,9 @@ typedef struct {
>
> unsigned char buffer[TPM_SPAPR_BUFFER_MAX];
>
> +uint32_t numbytes; /* number of bytes in suspend_buffer */
> +unsigned char *suspend_buffer;
> +
> TPMBackendCmd cmd;
>
> TPMBackend *be_driver;
> @@ -240,6 +243,13 @@ static void tpm_spapr_request_completed(TPMIf *ti, int
> ret)
>
> /* a max. of be_buffer_size bytes can be transported */
> len = MIN(tpm_cmd_get_size(s->buffer), s->be_buffer_size);
> +
> +if (runstate_check(RUN_STATE_FINISH_MIGRATE)) {
> +/* defer delivery of response until .post_load */
> +s->numbytes = len;
> +return;
> +}
I'm not understanding the basics of what's going on here. IIUC, the
backend TPM can complete a request after we've entered migration
downtime. But if that's the case, I can't see any guarantee that we
won't have already transmitted the TPM device state, so updating it
here might never reach the destination. In that case we'd still lose
the request, so I'm not sure what we're accomplishing here.
> rc = spapr_vio_dma_write(&s->vdev, be32_to_cpu(crq->data),
> s->buffer, len);
>
> @@ -288,11 +298,13 @@ static void tpm_spapr_reset(SpaprVioDevice *dev)
> SpaprTpmState *s = VIO_SPAPR_VTPM(dev);
>
> s->state = SPAPR_VTPM_STATE_NONE;
> +s->numbytes = 0;
>
> s->be_tpm_version = tpm_backend_get_tpm_version(s->be_driver);
>
> s->be_buffer_size = MIN(tpm_backend_get_buffer_size(s->be_driver),
> TPM_SPAPR_BUFFER_MAX);
> +s->suspend_buffer = g_realloc(s->suspend_buffer, s->be_buffer_size);
>
> tpm_backend_reset(s->be_driver);
> tpm_spapr_do_startup_tpm(s, s->be_buffer_size);
> @@ -309,9 +321,62 @@ static enum TPMVersion tpm_spapr_get_version(TPMIf *ti)
> return tpm_backend_get_tpm_version(s->be_driver);
> }
>
> +/* persistent state handling */
> +
> +static int tpm_spapr_pre_save(void *opaque)
> +{
> +SpaprTpmState *s = opaque;
> +
> +tpm_backend_finish_sync(s->be_driver);
> +
> +if (s->numbytes) {
> +memcpy(s->suspend_buffer, s->buffer, s->numbytes);
> +}
> +
> +trace_tpm_spapr_pre_save(s->numbytes);
> +/*
> + * we cannot deliver the results to the VM since DMA would touch VM
> memory
> + */
> +
> +return 0;
> +}
> +
> +static int tpm_spapr_post_load(void *opaque, int version_id)
> +{
> +SpaprTpmState *s = opaque;
> +
> +if (s->numbytes) {
> +trace_tpm_spapr_post_load();
> +
> +memcpy(s->buffer, s->suspend_buffer,
> + MIN(s->numbytes, s->be_buffer_size));
> +/* deliver the results to the VM via DMA */
> +tpm_spapr_request_completed(TPM_IF(s), 0);
> +s->numbytes = 0;
> +}
> +
> +return 0;
> +}
> +
> static const VMStateDescription vmstate_spapr_vtpm = {
> .name = "tpm-spapr",
> -.unmigratable = 1,
> +.version_id = 1,
> +.minimum_version_id = 0,
> +.minimum_version_id_old = 0,
> +.pre_save = tpm_spapr_pre_save,
> +.post_load = tpm_spapr_post_load,
> +.fields = (VMStateField[]) {
> +VMSTATE_SPAPR_VIO(vdev, SpaprTpmState),
> +
> +VMSTATE_UINT8(state, SpaprTpmState),
> +VMSTATE_UINT32(numbytes, SpaprTpmState),
> +VMSTATE_VBUFFER_ALLOC_UINT32(suspend_buffer,
> + SpaprTpmState, 0, NULL,
> + numbytes),
> +/* remember DMA address */
> +VMSTATE_UINT32(crq.data, SpaprTpmState),
> +VMSTATE_END_OF_LIST(),
> +}
> };
>
> static Property tpm_spapr_properties[] = {
> diff --git a/hw/tpm/trace-events b/hw/tpm/trace-events
> index 9143a8eaa3..5592cec7de 100644
> --- a/hw/tpm/trace-events
> +++ b/hw/tpm/trace-events
> @@ -67,3 +67,5 @@ tpm_spapr_do_crq_get_version(uint32_t version) "response:
> version %u"
> tpm_spapr_do_crq_prepare_to_suspend(void) "response: preparing to suspend"
> tpm_spapr_do_crq_unknown_msg_type(uint8_t type) "Unknown message type 0x%02x"
> tpm_spapr_do_crq_unknown_crq(uint8_t raw1, uint8_t raw2) "unknown CRQ 0x%02x
> 0x%02x ..."
> +tpm_spapr_pre_save(uint32_t v) "Number of TPM response bytes to deliver
> after resume: %u"
> +tpm_spapr_post_load(void) "Delivering TPM response after resume"
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
h
Re: [PATCH v7 6/6] docs: tpm: Add example command line for ppc64 and tpm-spapr
On Thu, Dec 19, 2019 at 09:06:05AM -0500, Stefan Berger wrote: > Add an example to the TPM docs for how to add a TPM SPAPR > device model to a QEMU VM emulating a pSeries machine. > > Signed-off-by: Stefan Berger I don't see any advantage to splitting this out - it can be merged into 3/6. > --- > docs/specs/tpm.txt | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt > index 9c8cca042d..9c3e67d8a7 100644 > --- a/docs/specs/tpm.txt > +++ b/docs/specs/tpm.txt > @@ -34,6 +34,12 @@ The CRB interface makes a memory mapped IO region in the > area 0xfed4 - > QEMU files related to TPM CRB interface: > - hw/tpm/tpm_crb.c > > + > +pSeries (ppc64) machines offer a tpm-spapr device model. > + > +QEMU files related to the SPAPR interface: > + - hw/tpm/tpm_spapr.c > + > = fw_cfg interface = > > The bios/firmware may read the "etc/tpm/config" fw_cfg entry for > @@ -281,7 +287,7 @@ swtpm socket --tpmstate dir=/tmp/mytpm1 \ >--log level=20 > > Command line to start QEMU with the TPM emulator device communicating with > -the swtpm: > +the swtpm (x86): > > qemu-system-x86_64 -display sdl -accel kvm \ >-m 1024 -boot d -bios bios-256k.bin -boot menu=on \ > @@ -289,6 +295,18 @@ qemu-system-x86_64 -display sdl -accel kvm \ >-tpmdev emulator,id=tpm0,chardev=chrtpm \ >-device tpm-tis,tpmdev=tpm0 test.img > > +In case a pSeries machine is emulated, use the following command line: > + > +qemu-system-ppc64 -display sdl -machine pseries,accel=kvm \ > + -m 1024 -bios slof.bin -boot menu=on \ > + -nodefaults -device VGA -device pci-ohci -device usb-kbd \ > + -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ > + -tpmdev emulator,id=tpm0,chardev=chrtpm \ > + -device tpm-spapr,tpmdev=tpm0 \ > + -device spapr-vscsi,id=scsi0,reg=0x2000 \ > + -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0 > \ > + -drive file=test.img,format=raw,if=none,id=drive-virtio-disk0 > + > > In case SeaBIOS is used as firmware, it should show the TPM menu item > after entering the menu with 'ESC'. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v2 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine
Hey Philippe, On Thu, Jan 2, 2020 at 10:11 PM Philippe Mathieu-Daudé wrote: > Hi Niek, > > On 1/2/20 8:52 PM, Niek Linnenbank wrote: > > Hi Philippe, > > > > I'm almost ready to send out v3 here. > > > > Now for documentation I'm not sure yet what to do: > > > > 1) Where should I place board documentation? > > For example, the information that I wrote on the cover letter with > > instructions on how to get the board up and running, > > some description of the design, where to find more inforformation, > > datasheet sources, etc. I don't yet see any documentation > > We usually refer the datasheet in the implementation header, see: > > $ git grep -F .pdf hw/ | wc -l > 62 > > You can cite the datasheet globally in hw/arm/allwinner-h3.c, and then > the particular chapters or source files in the other hw/*/allwinner-* > files. > > > for the other boards in the source. In my opinion, it is important > > to keep that information somewhere, such that also in the future > > the boards can still be properly maintained. Can I / shall I place a > > new file like ./docs/hw/arm/orangepi.txt for that? > > See docs/microvm.rst which is a recent example of machine documentation, > the obvious name is docs/orangepi.rst. > > Ah great, that is very helpful! I will use the microvm.rst as example and add a new file docs/orangepi.rst to document the board. > Maybe refer to this file in hw/arm/orangepi.c header for completeness. > > > 2) Is is allowed / encouraged to provide Doxygen-style comments in the > > header files in include/hw/*? > > I see that some of the API's have that, but the boards and devices > > mostly are free of Doxygen-style comments. > > It takes some work, but I think it can really help to give more > > insight / background info on how things are working > > for the devices and boards. But if it's not preferred for QEMU, I'm > > fine with that as well. > > Documentation is certainly welcome! > > There are 2 different schools over the codebase, one that document the > declarations, and another that documents the implementation/definition. > > I personally prefer to document the headers, which is where I look when > I want to consume an API. > The implementation school says this can lead to documentation getting > outdated. > > So if you are willing to document, I'd suggest to document your > include/hw/ files. > OK, thanks for clarifying! Yes, I also prefer to have it in the header files, it makes the most sense indeed. > > Happy new year! > And happy new year to you as well Philippe! Regards, Niek > > Phil. > > > On Mon, Dec 30, 2019 at 9:10 PM Niek Linnenbank > > mailto:nieklinnenb...@gmail.com>> wrote: > > > > > > > > On Mon, Dec 30, 2019 at 3:56 PM Philippe Mathieu-Daudé > > mailto:phi...@redhat.com>> wrote: > > > > On 12/30/19 12:28 PM, Niek Linnenbank wrote: > > > Hi, > > > > > > Here a short status report of this patch series. > > > > Good idea! > > > > > > > > For V3 update I already prepared the following: > > > - reworked all review comments from Philippe, except: > > > - patch#8: question for the SID, whether command-line > > override is > > > required (and how is the best way for machine-specific cli > > arg?) [1] > > > > Answered recently. > > > > Thanks! > > > > > > > - added BootROM support, allows booting with only specifying > > -sd > > > - added SDRAM controller driver, for U-Boot SPL > > > - added Allwinner generic RTC driver (for both Cubieboard and > > OrangePi > > > PC, supports sun4i, sun6i, sun7i) > > > - small fixes for EMAC > > > > > > My current TODO: > > > - integrate Philips acceptance tests in the series > > > > You can queue them in your series, adding your Signed-off-by tag > > after > > mine. See: > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin > > > > The sign-off is a simple line at the end of the explanation > > for the > > patch, which certifies that you wrote it or otherwise have the > > right to > > pass it on as an open-source patch. > > > > See point (c). > > > > Ah that certainly helps. I'll read that page. > > > > > - integrate Philips work for generalizing the Allwinner > > timer, and > > > finish it > > > > We can also do that later, and get your work merged first. > > > > > > Ok that sounds very good! Agreed, lets do the timer work later. > > > > > > > - test and fix BSD targets (NetBSD, FreeBSD) [2, 3] > > > - further generalize the series to cover very similar SoCs: > > H2+, H5 > > > > > > Does anyone have more comments/requests for the V3 update? > >
Re: [PATCH v2 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine
Hi Niek, On 1/2/20 8:52 PM, Niek Linnenbank wrote: Hi Philippe, I'm almost ready to send out v3 here. Now for documentation I'm not sure yet what to do: 1) Where should I place board documentation? For example, the information that I wrote on the cover letter with instructions on how to get the board up and running, some description of the design, where to find more inforformation, datasheet sources, etc. I don't yet see any documentation We usually refer the datasheet in the implementation header, see: $ git grep -F .pdf hw/ | wc -l 62 You can cite the datasheet globally in hw/arm/allwinner-h3.c, and then the particular chapters or source files in the other hw/*/allwinner-* files. for the other boards in the source. In my opinion, it is important to keep that information somewhere, such that also in the future the boards can still be properly maintained. Can I / shall I place a new file like ./docs/hw/arm/orangepi.txt for that? See docs/microvm.rst which is a recent example of machine documentation, the obvious name is docs/orangepi.rst. Maybe refer to this file in hw/arm/orangepi.c header for completeness. 2) Is is allowed / encouraged to provide Doxygen-style comments in the header files in include/hw/*? I see that some of the API's have that, but the boards and devices mostly are free of Doxygen-style comments. It takes some work, but I think it can really help to give more insight / background info on how things are working for the devices and boards. But if it's not preferred for QEMU, I'm fine with that as well. Documentation is certainly welcome! There are 2 different schools over the codebase, one that document the declarations, and another that documents the implementation/definition. I personally prefer to document the headers, which is where I look when I want to consume an API. The implementation school says this can lead to documentation getting outdated. So if you are willing to document, I'd suggest to document your include/hw/ files. Happy new year! Phil. On Mon, Dec 30, 2019 at 9:10 PM Niek Linnenbank mailto:nieklinnenb...@gmail.com>> wrote: On Mon, Dec 30, 2019 at 3:56 PM Philippe Mathieu-Daudé mailto:phi...@redhat.com>> wrote: On 12/30/19 12:28 PM, Niek Linnenbank wrote: > Hi, > > Here a short status report of this patch series. Good idea! > > For V3 update I already prepared the following: > - reworked all review comments from Philippe, except: > - patch#8: question for the SID, whether command-line override is > required (and how is the best way for machine-specific cli arg?) [1] Answered recently. Thanks! > - added BootROM support, allows booting with only specifying -sd > - added SDRAM controller driver, for U-Boot SPL > - added Allwinner generic RTC driver (for both Cubieboard and OrangePi > PC, supports sun4i, sun6i, sun7i) > - small fixes for EMAC > > My current TODO: > - integrate Philips acceptance tests in the series You can queue them in your series, adding your Signed-off-by tag after mine. See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. See point (c). Ah that certainly helps. I'll read that page. > - integrate Philips work for generalizing the Allwinner timer, and > finish it We can also do that later, and get your work merged first. Ok that sounds very good! Agreed, lets do the timer work later. > - test and fix BSD targets (NetBSD, FreeBSD) [2, 3] > - further generalize the series to cover very similar SoCs: H2+, H5 > > Does anyone have more comments/requests for the V3 update? > > [1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg04049.html > [2] https://wiki.netbsd.org/ports/evbarm/allwinner/ > [3] > https://wiki.freebsd.org/action/show/arm/Allwinner?action=show&redirect=FreeBSD%2Farm%2FAllwinner -- Niek Linnenbank -- Niek Linnenbank
[PATCH 2/2] tpm-ppi: page-align PPI RAM
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau
---
hw/tpm/tpm_ppi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/tpm/tpm_ppi.c b/hw/tpm/tpm_ppi.c
index ff314592b4..6d9c1a3e40 100644
--- a/hw/tpm/tpm_ppi.c
+++ b/hw/tpm/tpm_ppi.c
@@ -43,7 +43,8 @@ void tpm_ppi_reset(TPMPPI *tpmppi)
void tpm_ppi_init(TPMPPI *tpmppi, struct MemoryRegion *m,
hwaddr addr, Object *obj)
{
-tpmppi->buf = g_malloc0(HOST_PAGE_ALIGN(TPM_PPI_ADDR_SIZE));
+tpmppi->buf = qemu_memalign(qemu_real_host_page_size,
+HOST_PAGE_ALIGN(TPM_PPI_ADDR_SIZE));
memory_region_init_ram_device_ptr(&tpmppi->ram, obj, "tpm-ppi",
TPM_PPI_ADDR_SIZE, tpmppi->buf);
vmstate_register_ram(&tpmppi->ram, DEVICE(obj));
--
2.24.0.308.g228f53135a
[PATCH 0/2] tpm: fix PPI RAM migration
Hi, The following series fixes a migration issue with the TPM PPI code due to unaligned host RAM pointer. Marc-André Lureau (2): RFC: savevm: check RAM is page_size aligned tpm-ppi: page-align PPI RAM hw/tpm/tpm_ppi.c | 3 ++- migration/savevm.c | 5 + 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.24.0.308.g228f53135a
[PATCH 1/2] RFC: savevm: check RAM is page_size aligned
Check the host pointer is correctly aligned, otherwise we may fail
during migration in ram_block_discard_range().
Signed-off-by: Marc-André Lureau
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index a71b930b91..ab6e02011f 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2910,6 +2910,11 @@ err_drain:
void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev)
{
+RAMBlock *rb = mr->ram_block;
+uintptr_t hostaddr = (uintptr_t)qemu_ram_get_host_addr(rb);
+
+assert((hostaddr & (qemu_ram_pagesize(rb) - 1)) == 0);
+
qemu_ram_set_idstr(mr->ram_block,
memory_region_name(mr), dev);
qemu_ram_set_migratable(mr->ram_block);
--
2.24.0.308.g228f53135a
[PATCH RFC] i386/kvm: fix enlightened VMCS with fine-grained VMX feature enablement
When enlightened VMCS is enabled, certain VMX controls disappear, e.g.
posted interrupts for PINBASED_CTLS. With fine-grained VMX feature
enablement QEMU tries to do KVM_SET_MSRS with default (matching CPU
model) values and fails as KVM doesn't allow to set now-unsupported
controls.
The ideal solution for the issue would probably be to re-read VMX
feature MSRs after enabling KVM_CAP_HYPERV_ENLIGHTENED_VMCS, however,
this doesn't seem to be possible: currently, KVM returns global
&vmcs_config.nested values for VMX MSRs when userspace does KVM_GET_MSR.
It is also possible to modify KVM to apply 'evmcs filtering' to VMX
MSRs when userspace tries to set them and hide the issue but this doesn't
seem to be entirely correct.
It is unfortunate that we now need to support the list of VMX features
disabled by enlightened VMCS in QEMU. When (and if) enlightened VMCS v2
arrives we'll need to fix QEMU and allow previously disabled features.
Signed-off-by: Vitaly Kuznetsov
---
- I don't quite like this workaround myself, thus RFC. I'm sure someone
will suggest a better alternative.
---
target/i386/kvm.c | 24
1 file changed, 24 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 0b511906e3fe..1b0589b79358 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1198,6 +1198,30 @@ static int hyperv_handle_properties(CPUState *cs,
}
if (!r) {
+/*
+ * Certain VMX controls are unsupported when enlightened VMCS is
+ * enabled, filter them out here so we don't attempt to set them
+ * with KVM_SET_MSR even if they are supported by CPU model.
+ * The list below is for eVMCS version 1.
+ */
+env->features[FEAT_VMX_PINBASED_CTLS] &=
+~(VMX_PIN_BASED_VMX_PREEMPTION_TIMER |
+ VMX_PIN_BASED_POSTED_INTR);
+env->features[FEAT_VMX_SECONDARY_CTLS] &=
+~(VMX_SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
+ VMX_SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
+ VMX_SECONDARY_EXEC_APIC_REGISTER_VIRT |
+ VMX_SECONDARY_EXEC_ENABLE_PML |
+ VMX_SECONDARY_EXEC_ENABLE_VMFUNC |
+ VMX_SECONDARY_EXEC_SHADOW_VMCS |
+ /* VMX_SECONDARY_EXEC_TSC_SCALING | */
+ VMX_SECONDARY_EXEC_PAUSE_LOOP_EXITING);
+env->features[FEAT_VMX_ENTRY_CTLS] &=
+~VMX_VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
+env->features[FEAT_VMX_EXIT_CTLS] &=
+~VMX_VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL;
+env->features[FEAT_VMX_VMFUNC] &= ~MSR_VMX_VMFUNC_EPT_SWITCHING;
+
env->features[FEAT_HV_RECOMM_EAX] |=
HV_ENLIGHTENED_VMCS_RECOMMENDED;
env->features[FEAT_HV_NESTED_EAX] = evmcs_version;
--
2.24.1
Re: [PATCH v2] hppa: allow max ram size upto 4Gb
On 02.01.20 18:46, Igor Mammedov wrote:
> Previous patch drops silent ram_size fixup and makes
> QEMU error out with:
>
> "RAM size more than 3840m is not supported"
>
> when user specified -m X more than supported value.
>
> User shouldn't be bothered with starting QEMU with valid CLI,
> so for the sake of user convenience allow using -m 4G vs -m 3840M.
>
> Requested-by: Helge Deller
> Signed-off-by: Igor Mammedov
> ---
> v2:
> - make main ram -1 prio, so it wouldn't conflict with other regions
> starting from 0xf900
>
> I dislike it but if you feel it's really necessary feel free to ack it.
>
> should be applied on top of:
> "hppa: drop RAM size fixup"
Hello Igor,
I appreciate that you are trying to make it more cleaner.
But, can't you merge both of your patches to one patch?
Right now you have one patch "hppa: drop RAM size fixup", which is
what I think is wrong. Then you add another one which somehow
fixes it up again and adds other stuff.
Having everything in one single patch makes your full change more
understandable.
Is it necessary to introduce clamped_ram_size and not continue with
ram_size (even if you would add it as static local variable)?
Helge
> ---
> hw/hppa/machine.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> index ebbf44f..0302983 100644
> --- a/hw/hppa/machine.c
> +++ b/hw/hppa/machine.c
> @@ -54,6 +54,7 @@ static uint64_t cpu_hppa_to_phys(void *opaque, uint64_t
> addr)
>
> static HPPACPU *cpu[HPPA_MAX_CPUS];
> static uint64_t firmware_entry;
> +static ram_addr_t clamped_ram_size;
>
> static void machine_hppa_init(MachineState *machine)
> {
> @@ -74,8 +75,6 @@ static void machine_hppa_init(MachineState *machine)
> long i;
> unsigned int smp_cpus = machine->smp.cpus;
>
> -ram_size = machine->ram_size;
> -
> /* Create CPUs. */
> for (i = 0; i < smp_cpus; i++) {
> char *name = g_strdup_printf("cpu%ld-io-eir", i);
> @@ -90,12 +89,14 @@ static void machine_hppa_init(MachineState *machine)
> }
>
> /* Limit main memory. */
> -if (ram_size > FIRMWARE_START) {
> -error_report("RAM size more than %d is not supported",
> FIRMWARE_START);
> +if (machine->ram_size > 4 * GiB) {
> +error_report("RAM size more than 4Gb is not supported");
> exit(EXIT_FAILURE);
> }
> +clamped_ram_size = machine->ram_size > FIRMWARE_START ?
> +FIRMWARE_START : machine->ram_size;
>
> -memory_region_add_subregion(addr_space, 0, machine->ram);
> +memory_region_add_subregion_overlap(addr_space, 0, machine->ram, -1);
>
> /* Init Dino (PCI host bus chip). */
> pci_bus = dino_init(addr_space, &rtc_irq, &serial_irq);
> @@ -151,7 +152,7 @@ static void machine_hppa_init(MachineState *machine)
> qemu_log_mask(CPU_LOG_PAGE, "Firmware loaded at 0x%08" PRIx64
>"-0x%08" PRIx64 ", entry at 0x%08" PRIx64 ".\n",
>firmware_low, firmware_high, firmware_entry);
> -if (firmware_low < ram_size || firmware_high >= FIRMWARE_END) {
> +if (firmware_low < clamped_ram_size || firmware_high >= FIRMWARE_END) {
> error_report("Firmware overlaps with memory or IO space");
> exit(1);
> }
> @@ -204,7 +205,7 @@ static void machine_hppa_init(MachineState *machine)
> (1) Due to sign-extension problems and PDC,
> put the initrd no higher than 1G.
> (2) Reserve 64k for stack. */
> -initrd_base = MIN(ram_size, 1 * GiB);
> +initrd_base = MIN(clamped_ram_size, 1 * GiB);
> initrd_base = initrd_base - 64 * KiB;
> initrd_base = (initrd_base - initrd_size) & TARGET_PAGE_MASK;
>
> @@ -232,7 +233,7 @@ static void machine_hppa_init(MachineState *machine)
> * various parameters in registers. After firmware initialization,
> * firmware will start the Linux kernel with ramdisk and cmdline.
> */
> -cpu[0]->env.gr[26] = ram_size;
> +cpu[0]->env.gr[26] = clamped_ram_size;
> cpu[0]->env.gr[25] = kernel_entry;
>
> /* tell firmware how many SMP CPUs to present in inventory table */
> @@ -255,11 +256,11 @@ static void hppa_machine_reset(MachineState *ms)
> }
>
> /* already initialized by machine_hppa_init()? */
> -if (cpu[0]->env.gr[26] == ram_size) {
> +if (cpu[0]->env.gr[26] == clamped_ram_size) {
> return;
> }
>
> -cpu[0]->env.gr[26] = ram_size;
> +cpu[0]->env.gr[26] = clamped_ram_size;
> cpu[0]->env.gr[25] = 0; /* no firmware boot menu */
> cpu[0]->env.gr[24] = 'c';
> /* gr22/gr23 unused, no initrd while reboot. */
>
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 02.01.20 16:49, Philippe Mathieu-Daudé wrote:
> On 1/2/20 4:08 PM, Igor Mammedov wrote:
>> On Thu, 2 Jan 2020 15:17:14 +0100
>> Philippe Mathieu-Daudé wrote:
>>
>>> On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
>>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported",
FIRMWARE_START);
+ exit(EXIT_FAILURE);
>>>
>>> $ qemu-system-hppa -m 3841m
>>> qemu-system-hppa: invalid accelerator kvm
>>> qemu-system-hppa: falling back to tcg
>>> qemu-system-hppa: RAM size more than -268435456 is not supported
>>>
>>> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format,
>>> we can simply use "RAM size more than 3840m is not supported". Is that
>>> OK with you?
>>
>> I don't really like that change.
>>
>> We currently only emulate a 32-bit system, and for those 4GB is the
>> maximum.
>> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
>> then automatically uses the maximum possible of 3841MB (which is limited
>> by
>> firmware start address).
>> I don't expect users to know the excact 3841MB number.
>> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or
>> 4GB,
>> but not "3841MB".
>
> Thanks for the explanation. This deserves a comment in the source file
> IMHO (and displaying a warning to the user that the behavior is changed).
>
> I understand the CPU can't access this DRAM area because the ROM is
> mapped there. What about other devices, can they do DMA access to it?
>
> Igor: If this complicates your series too much, I think we can directly
> allocate up-to 4GiB and not worry about the 256MiB lost.
Do you mean
s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
supported"/
>>>
>>> Works for me! You can keep my R-b with this change, thanks.
>>
>> Well, it's not that simple.
>> Do we map whole 4G in address space, if yes then we have to "unbreak"
>> firmware mapping and use overlap mapping or do we map only portion of it?
>> Both would make code more confusing and all for the sake of user convenience
>> so they won't have to change their CLI?
>
> I was thinking about this patch:
>
> -- >8 --
> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> index 5d0de26140..fa0b6a9536 100644
> --- a/hw/hppa/machine.c
> +++ b/hw/hppa/machine.c
> @@ -91,15 +91,16 @@ static void machine_hppa_init(MachineState *machine)
> }
>
> /* Limit main memory. */
> - if (ram_size > FIRMWARE_START) {
> - machine->ram_size = ram_size = FIRMWARE_START;
> + if (ram_size > 4 * GiB) {
> + error_report("Can not model more than 4GB of RAM");
> + exit(EXIT_FAILURE);
> }
>
> /* Main memory region. */
> ram_region = g_new(MemoryRegion, 1);
> memory_region_allocate_system_memory(ram_region, OBJECT(machine),
> "ram", ram_size);
> - memory_region_add_subregion(addr_space, 0, ram_region);
> + memory_region_add_subregion_overlap(addr_space, 0, ram_region, -1);
>
> /* Init Dino (PCI host bus chip). */
> pci_bus = dino_init(addr_space, &rtc_irq, &serial_irq);
I haven't tested this patch, but that one seems good.
Helge
> ---
>
> $ hppa-softmmu/qemu-system-hppa -m 3840m -S -monitor stdio
> QEMU 4.2.50 monitor - type 'help' for more information
> (qemu) info mtree
> address-space: memory
> - (prio 0, i/o): system
> -efff (prio -1, ram): ram
> f000-f07f (prio 0, ram): firmware
> f900-f90007ff (prio 0, i/o): isa-io
> f920-f921 (prio 0, i/o): pic
> f9000
Re: [PATCH v2 00/10] Add Allwinner H3 SoC and Orange Pi PC Machine
Hi Philippe, I'm almost ready to send out v3 here. Now for documentation I'm not sure yet what to do: 1) Where should I place board documentation? For example, the information that I wrote on the cover letter with instructions on how to get the board up and running, some description of the design, where to find more inforformation, datasheet sources, etc. I don't yet see any documentation for the other boards in the source. In my opinion, it is important to keep that information somewhere, such that also in the future the boards can still be properly maintained. Can I / shall I place a new file like ./docs/hw/arm/orangepi.txt for that? 2) Is is allowed / encouraged to provide Doxygen-style comments in the header files in include/hw/*? I see that some of the API's have that, but the boards and devices mostly are free of Doxygen-style comments. It takes some work, but I think it can really help to give more insight / background info on how things are working for the devices and boards. But if it's not preferred for QEMU, I'm fine with that as well. Regards, Niek On Mon, Dec 30, 2019 at 9:10 PM Niek Linnenbank wrote: > > > On Mon, Dec 30, 2019 at 3:56 PM Philippe Mathieu-Daudé > wrote: > >> On 12/30/19 12:28 PM, Niek Linnenbank wrote: >> > Hi, >> > >> > Here a short status report of this patch series. >> >> Good idea! >> >> > >> > For V3 update I already prepared the following: >> > - reworked all review comments from Philippe, except: >> > - patch#8: question for the SID, whether command-line override is >> > required (and how is the best way for machine-specific cli arg?) [1] >> >> Answered recently. >> > Thanks! > >> >> > - added BootROM support, allows booting with only specifying -sd >> > - added SDRAM controller driver, for U-Boot SPL >> > - added Allwinner generic RTC driver (for both Cubieboard and OrangePi >> > PC, supports sun4i, sun6i, sun7i) >> > - small fixes for EMAC >> > >> > My current TODO: >> > - integrate Philips acceptance tests in the series >> >> You can queue them in your series, adding your Signed-off-by tag after >> mine. See: >> >> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin >> >>The sign-off is a simple line at the end of the explanation for the >> patch, which certifies that you wrote it or otherwise have the right to >> pass it on as an open-source patch. >> >> See point (c). >> >> Ah that certainly helps. I'll read that page. > > >> > - integrate Philips work for generalizing the Allwinner timer, and >> > finish it >> >> We can also do that later, and get your work merged first. >> > > Ok that sounds very good! Agreed, lets do the timer work later. > > >> >> > - test and fix BSD targets (NetBSD, FreeBSD) [2, 3] >> > - further generalize the series to cover very similar SoCs: H2+, H5 >> > >> > Does anyone have more comments/requests for the V3 update? >> > >> > [1] https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg04049.html >> > [2] https://wiki.netbsd.org/ports/evbarm/allwinner/ >> > [3] >> > >> https://wiki.freebsd.org/action/show/arm/Allwinner?action=show&redirect=FreeBSD%2Farm%2FAllwinner >> >> > > -- > Niek Linnenbank > > -- Niek Linnenbank
Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update
Hi On Thu, Jan 2, 2020 at 3:03 PM Felipe Franciosi wrote: > The reason I dislike yet another offloading protocol (ie. there is > vhost, there is vfio, and then there would be qdev-over-socket) is > that we keep reinventing the wheel. I very much prefer picking > something solid (eg. VFIO) and keep investing on it. I don't have a lot of experience with VFIO, so I can't tell if it's really solid for the user-space case. Alex W could probably discuss that. > In that case, wouldn't it be preferable to revive our proposal from > Edinburgh (KVM Forum 2018)? Our prototypes moved more of the Qemu VFIO > code to "common" and added a "user" backend underneath it, similar to > how vhost-user-scsi moved some of vhost-scsi to vhost-scsi-common and > added vhost-user-scsi. It was centric on PCI, but it doesn't have to > be. The other side can be implemented in libmuser for facilitating things. Same idea back in KVM forum 2017 (briefly mentioned at the end of our talk with Conrad) The PoC is still around: https://github.com/elmarco/qemu/tree/wip/vfio-user/contrib/libvfio-user > I even recall highlighting that vhost-user could be moved underneath > that later, greatly simplifying lots of other Qemu code. That would eventually be an option, but vhost-user is already quite complicated. We could try to split it up somehow for the non-virtio parts. cheers -- Marc-André Lureau
Re: [PATCH v10 Kernel 1/5] vfio: KABI for migration interface for device state
* Alex Williamson (alex.william...@redhat.com) wrote: > On Fri, 20 Dec 2019 01:40:35 +0530 > Kirti Wankhede wrote: > > > On 12/19/2019 10:57 PM, Alex Williamson wrote: > > > > > > > > > > If device state it at pre-copy state (011b). > > Transition, i.e., write to device state as stop-and-copy state (010b) > > failed, then by previous state I meant device should return pre-copy > > state(011b), i.e. previous state which was successfully set, or as you > > said current state which was successfully set. > > Yes, the point I'm trying to make is that this version of the spec > tries to tell the user what they should do upon error according to our > current interpretation of the QEMU migration protocol. We're not > defining the QEMU migration protocol, we're defining something that can > be used in a way to support that protocol. So I think we should be > concerned with defining our spec, for example my proposal would be: "If > a state transition fails the user can read device_state to determine the > current state of the device. This should be the previous state of the > device unless the vendor driver has encountered an internal error, in > which case the device may report the invalid device_state 110b. The > user must use the device reset ioctl in order to recover the device > from this state. If the device is indicated in a valid device state > via reading device_state, the user may attempt to transition the device > to any valid state reachable from the current state." We might want to be able to distinguish between: a) The device has failed and needs a reset b) The migration has failed If some part of the devices mechanics for migration fail, but the device is otherwise operational then we should be able to decide to fail the migration without taking the device down, which might be very bad for the VM. Losing a VM during migration due to a problem with migration really annoys users; it's one thing the migration failing, but taking the VM out as well really gets to them. Having the device automatically transition back to the 'running' state seems a bad idea to me; much better to tell the hypervisor and provide it with a way to clean up; for example, imagine a system with multiple devices that are being migrated, most of them have happily transitioned to stop-and-copy, but then the last device decides to fail - so now someone is going to have to take all of them back to running. Dave > > >>> and allowable state transitions independent > > >>> of the expected usage model. > > >> > > >> Do you mean to define array of ['from','to'], same as runstate > > >> transition array in QEMU? > > >>static const RunStateTransition runstate_transitions_def[] > > > > > > I'm thinking that independent of expected QEMU usage models, are there > > > any invalid transitions or is every state reachable from every other > > > state. I'm afraid this design is so focused on a specific usage model > > > that vendor drivers are going to fall over if the user invokes a > > > transition outside of those listed above. If there are invalid > > > transitions, those should be listed so they can be handled > > > consistently. If there are no invalid transitions, it should be noted > > > in the spec to encourage vendor drivers to expect this. > > > > > > > I think vendor driver can decide which state transitions it can support, > > rather than defining/prescribing that all. > > Suppose, if vendor driver doesn't want to support save-restore > > functionality, then vendor driver can return error -EINVAL for write() > > operation on device_state for transition from _RUNNING to > > stop-and-copy(010b) state. > > This is unsupportable. If the vendor driver doesn't want to support > save-restore then they simply do not implement the migration > extensions. If they expose this interface then the user (QEMU) will > rightfully assume that the device supports migration, only to find out > upon trying to use it that it's unsupported, or maybe broken. > > > >>> For example, I think a user should always > > >>> be allowed to transition a device to stopped regardless of the expected > > >>> migration flow. An error might have occurred elsewhere and we want to > > >>> stop everything for debugging. I think it's also allowable to switch > > >>> directly from running to stop-and-copy, for example to save and resume > > >>> a VM offline. > > >>> > > > Also, it seems like it's the vendor driver's discretion to actually > > > provide data during the pre-copy phase. As we've defined it, the > > > vendor driver needs to participate in the migration region regardless, > > > they might just always report no pending_bytes until we enter > > > stop-and-copy. > > > > > > > Yes. And if pending_bytes are reported as 0 in pre-copy by vendor > > driver > > then QEMU doesn't reiterate for that device. > > >>> > > >>> Maybe we can state that as the expected m
Re: [PATCH v1 01/36] target/riscv: Convert MIP CSR to target_ulong
On Mon, 09 Dec 2019 10:10:43 PST (-0800), Alistair Francis wrote:
The MIP CSR is a xlen CSR, it was only 32-bits to allow atomic access.
Now that we don't use atomics for MIP we can change this back to a xlen
CSR.
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 2 +-
target/riscv/cpu.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index d37861a430..e521ebe2e1 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -224,7 +224,7 @@ static void riscv_cpu_dump_state(CPUState *cs, FILE *f, int
flags)
#ifndef CONFIG_USER_ONLY
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mhartid ", env->mhartid);
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mstatus ", env->mstatus);
-qemu_fprintf(f, " %s 0x%x\n", "mip ", env->mip);
+qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mip ", env->mip);
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mie ", env->mie);
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "mideleg ", env->mideleg);
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "medeleg ", env->medeleg);
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index e59343e13c..f889427869 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -121,7 +121,7 @@ struct CPURISCVState {
target_ulong mhartid;
target_ulong mstatus;
-uint32_t mip;
+target_ulong mip;
uint32_t miclaim;
target_ulong mie;
Reviewed-by: Palmer Dabbelt
[PATCH v2] hppa: allow max ram size upto 4Gb
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience allow using -m 4G vs -m 3840M.
Requested-by: Helge Deller
Signed-off-by: Igor Mammedov
---
v2:
- make main ram -1 prio, so it wouldn't conflict with other regions
starting from 0xf900
I dislike it but if you feel it's really necessary feel free to ack it.
should be applied on top of:
"hppa: drop RAM size fixup"
---
hw/hppa/machine.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index ebbf44f..0302983 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -54,6 +54,7 @@ static uint64_t cpu_hppa_to_phys(void *opaque, uint64_t addr)
static HPPACPU *cpu[HPPA_MAX_CPUS];
static uint64_t firmware_entry;
+static ram_addr_t clamped_ram_size;
static void machine_hppa_init(MachineState *machine)
{
@@ -74,8 +75,6 @@ static void machine_hppa_init(MachineState *machine)
long i;
unsigned int smp_cpus = machine->smp.cpus;
-ram_size = machine->ram_size;
-
/* Create CPUs. */
for (i = 0; i < smp_cpus; i++) {
char *name = g_strdup_printf("cpu%ld-io-eir", i);
@@ -90,12 +89,14 @@ static void machine_hppa_init(MachineState *machine)
}
/* Limit main memory. */
-if (ram_size > FIRMWARE_START) {
-error_report("RAM size more than %d is not supported", FIRMWARE_START);
+if (machine->ram_size > 4 * GiB) {
+error_report("RAM size more than 4Gb is not supported");
exit(EXIT_FAILURE);
}
+clamped_ram_size = machine->ram_size > FIRMWARE_START ?
+FIRMWARE_START : machine->ram_size;
-memory_region_add_subregion(addr_space, 0, machine->ram);
+memory_region_add_subregion_overlap(addr_space, 0, machine->ram, -1);
/* Init Dino (PCI host bus chip). */
pci_bus = dino_init(addr_space, &rtc_irq, &serial_irq);
@@ -151,7 +152,7 @@ static void machine_hppa_init(MachineState *machine)
qemu_log_mask(CPU_LOG_PAGE, "Firmware loaded at 0x%08" PRIx64
"-0x%08" PRIx64 ", entry at 0x%08" PRIx64 ".\n",
firmware_low, firmware_high, firmware_entry);
-if (firmware_low < ram_size || firmware_high >= FIRMWARE_END) {
+if (firmware_low < clamped_ram_size || firmware_high >= FIRMWARE_END) {
error_report("Firmware overlaps with memory or IO space");
exit(1);
}
@@ -204,7 +205,7 @@ static void machine_hppa_init(MachineState *machine)
(1) Due to sign-extension problems and PDC,
put the initrd no higher than 1G.
(2) Reserve 64k for stack. */
-initrd_base = MIN(ram_size, 1 * GiB);
+initrd_base = MIN(clamped_ram_size, 1 * GiB);
initrd_base = initrd_base - 64 * KiB;
initrd_base = (initrd_base - initrd_size) & TARGET_PAGE_MASK;
@@ -232,7 +233,7 @@ static void machine_hppa_init(MachineState *machine)
* various parameters in registers. After firmware initialization,
* firmware will start the Linux kernel with ramdisk and cmdline.
*/
-cpu[0]->env.gr[26] = ram_size;
+cpu[0]->env.gr[26] = clamped_ram_size;
cpu[0]->env.gr[25] = kernel_entry;
/* tell firmware how many SMP CPUs to present in inventory table */
@@ -255,11 +256,11 @@ static void hppa_machine_reset(MachineState *ms)
}
/* already initialized by machine_hppa_init()? */
-if (cpu[0]->env.gr[26] == ram_size) {
+if (cpu[0]->env.gr[26] == clamped_ram_size) {
return;
}
-cpu[0]->env.gr[26] = ram_size;
+cpu[0]->env.gr[26] = clamped_ram_size;
cpu[0]->env.gr[25] = 0; /* no firmware boot menu */
cpu[0]->env.gr[24] = 'c';
/* gr22/gr23 unused, no initrd while reboot. */
--
2.7.4
Re: [PATCH] hppa: allow max ram size upto 4Gb
On Thu, 2 Jan 2020 18:15:02 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 6:08 PM, Igor Mammedov wrote:
> > Previous patch drops silent ram_size fixup and makes
> > QEMU error out with:
> >
> > "RAM size more than 3840m is not supported"
> >
> > when user specified -m X more than supported value.
> >
> > User shouldn't be bothered with starting QEMU with valid CLI,
> > so for the sake of user convenience to allow using -m 4G vs -m 3840M.
> >
> > Requested-by: Helge Deller
> > Signed-off-by: Igor Mammedov
> > ---
> > I dislike it but if you feel it's really necessary feel free to ack it.
> >
> > should be applied on top of:
> >"hppa: drop RAM size fixup"
> > ---
> > hw/hppa/machine.c | 22 --
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> > index ebbf44f..7f8c92f 100644
> > --- a/hw/hppa/machine.c
> > +++ b/hw/hppa/machine.c
> > @@ -54,6 +54,7 @@ static uint64_t cpu_hppa_to_phys(void *opaque, uint64_t
> > addr)
> >
> > static HPPACPU *cpu[HPPA_MAX_CPUS];
> > static uint64_t firmware_entry;
> > +static ram_addr_t clamped_ram_size;
> >
> > static void machine_hppa_init(MachineState *machine)
> > {
> > @@ -74,8 +75,6 @@ static void machine_hppa_init(MachineState *machine)
> > long i;
> > unsigned int smp_cpus = machine->smp.cpus;
> >
> > -ram_size = machine->ram_size;
> > -
> > /* Create CPUs. */
> > for (i = 0; i < smp_cpus; i++) {
> > char *name = g_strdup_printf("cpu%ld-io-eir", i);
> > @@ -90,10 +89,12 @@ static void machine_hppa_init(MachineState *machine)
> > }
> >
> > /* Limit main memory. */
> > -if (ram_size > FIRMWARE_START) {
> > -error_report("RAM size more than %d is not supported",
> > FIRMWARE_START);
> > +if (machine->ram_size > 4 * GiB) {
> > +error_report("RAM size more than 4Gb is not supported");
> > exit(EXIT_FAILURE);
> > }
> > +clamped_ram_size = machine->ram_size > FIRMWARE_START ?
> > +FIRMWARE_START : machine->ram_size;
> >
> > memory_region_add_subregion(addr_space, 0, machine->ram);
> >
> > @@ -151,7 +152,7 @@ static void machine_hppa_init(MachineState *machine)
> > qemu_log_mask(CPU_LOG_PAGE, "Firmware loaded at 0x%08" PRIx64
> > "-0x%08" PRIx64 ", entry at 0x%08" PRIx64 ".\n",
> > firmware_low, firmware_high, firmware_entry);
> > -if (firmware_low < ram_size || firmware_high >= FIRMWARE_END) {
> > +if (firmware_low < clamped_ram_size || firmware_high >= FIRMWARE_END) {
> > error_report("Firmware overlaps with memory or IO space");
> > exit(1);
> > }
> > @@ -160,7 +161,8 @@ static void machine_hppa_init(MachineState *machine)
> > rom_region = g_new(MemoryRegion, 1);
> > memory_region_init_ram(rom_region, NULL, "firmware",
> > (FIRMWARE_END - FIRMWARE_START), &error_fatal);
> > -memory_region_add_subregion(addr_space, FIRMWARE_START, rom_region);
> > +memory_region_add_subregion_overlap(addr_space, FIRMWARE_START,
> > rom_region,
> > +1);
>
> I don't think this is enough because we also have:
>
> (qemu) info mtree
> address-space: memory
>f900-f90007ff (prio 0, i/o): isa-io
>fff8-fff80fff (prio 0, i/o): dino
>fff83800-fff83807 (prio 0, i/o): serial
>fffb-fffb0003 (prio 0, i/o): cpu0-io-eir
>
> Which is why I went the other way around, using prio=-1 for the ram.
True
(you see it just snowball of un-obvious changes for user convenience)
>
> >
> > /* Load kernel */
> > if (kernel_filename) {
> > @@ -204,7 +206,7 @@ static void machine_hppa_init(MachineState *machine)
> > (1) Due to sign-extension problems and PDC,
> > put the initrd no higher than 1G.
> > (2) Reserve 64k for stack. */
> > -initrd_base = MIN(ram_size, 1 * GiB);
> > +initrd_base = MIN(clamped_ram_size, 1 * GiB);
> > initrd_base = initrd_base - 64 * KiB;
> > initrd_base = (initrd_base - initrd_size) & TARGET_PAGE_MASK;
> >
> > @@ -232,7 +234,7 @@ static void machine_hppa_init(MachineState *machine)
> >* various parameters in registers. After firmware initialization,
> >* firmware will start the Linux kernel with ramdisk and cmdline.
> >*/
> > -cpu[0]->env.gr[26] = ram_size;
> > +cpu[0]->env.gr[26] = clamped_ram_size;
> > cpu[0]->env.gr[25] = kernel_entry;
> >
> > /* tell firmware how many SMP CPUs to present in inventory table */
> > @@ -255,11 +257,11 @@ static void hppa_machine_reset(MachineState *ms)
> > }
> >
> > /* already initialized by machine_hppa_init()? */
> > -if (cpu[0]->env.gr[26] == ram_size) {
> > +if (cpu[0]->en
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 18:14:32 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 5:50 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 16:49:00 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 4:08 PM, Igor Mammedov wrote:
> >>> On Thu, 2 Jan 2020 15:17:14 +0100
> >>> Philippe Mathieu-Daudé wrote:
> >>>
> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 13:06:33 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 12:31 PM, Helge Deller wrote:
> >>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> > If user provided non-sense RAM size, board will complain and
> > continue running with max RAM size supported.
> > Also RAM is going to be allocated by generic code, so it won't be
> > possible for board to fix things up for user.
> >
> > Make it error message and exit to force user fix CLI,
> > instead of accepting non-sense CLI values.
> >
> > Signed-off-by: Igor Mammedov
> > ---
> > hw/hppa/machine.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> > index 5d0de26..25f5afc 100644
> > --- a/hw/hppa/machine.c
> > +++ b/hw/hppa/machine.c
> > @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState
> > *machine)
> > /* Limit main memory. */
> > if (ram_size > FIRMWARE_START) {
> > - machine->ram_size = ram_size = FIRMWARE_START;
> > + error_report("RAM size more than %d is not supported",
> > FIRMWARE_START);
> > +exit(EXIT_FAILURE);
>
> $ qemu-system-hppa -m 3841m
> qemu-system-hppa: invalid accelerator kvm
> qemu-system-hppa: falling back to tcg
> qemu-system-hppa: RAM size more than -268435456 is not supported
>
> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned
> format, we can simply use "RAM size more than 3840m is not
> supported". Is that OK with you?
> >>>
> >>> I don't really like that change.
> >>>
> >>> We currently only emulate a 32-bit system, and for those 4GB is the
> >>> maximum.
> >>> So, if I start my machine with "qemu-system-hppa -m 4G", the current
> >>> code
> >>> then automatically uses the maximum possible of 3841MB (which is
> >>> limited by
> >>> firmware start address).
> >>> I don't expect users to know the excact 3841MB number.
> >>> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB
> >>> or 4GB,
> >>> but not "3841MB".
> >>
> >> Thanks for the explanation. This deserves a comment in the source file
> >> IMHO (and displaying a warning to the user that the behavior is
> >> changed).
> >>
> >> I understand the CPU can't access this DRAM area because the ROM is
> >> mapped there. What about other devices, can they do DMA access to it?
> >>
> >> Igor: If this complicates your series too much, I think we can directly
> >> allocate up-to 4GiB and not worry about the 256MiB lost.
> >
> > Do you mean
> > s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is
> > not supported"/
>
> Works for me! You can keep my R-b with this change, thanks.
> >>>
> >>> Well, it's not that simple.
> >>> Do we map whole 4G in address space, if yes then we have to "unbreak"
> >>> firmware mapping and use overlap mapping or do we map only portion of it?
> >>> Both would make code more confusing and all for the sake of user
> >>> convenience
> >>> so they won't have to change their CLI?
> >>
> >> I was thinking about this patch:
> > it probably should be a bit more complicated.
> >
> >>
> >> -- >8 --
> >> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> >> index 5d0de26140..fa0b6a9536 100644
> >> --- a/hw/hppa/machine.c
> >> +++ b/hw/hppa/machine.c
> >> @@ -91,15 +91,16 @@ static void machine_hppa_init(MachineState *machine)
> >>}
> >>
> >>/* Limit main memory. */
> >> -if (ram_size > FIRMWARE_START) {
> >> -machine->ram_size = ram_size = FIRMWARE_START;
> >> +if (ram_size > 4 * GiB) {
> >> +error_report("Can not model more than 4GB of RAM");
> >> +exit(EXIT_FAILURE);
> >>}
> >>
> >>/* Main memory region. */
> >>ram_region = g_new(MemoryRegion, 1);
> >>memory_region_allocate_system_memory(ram_region, OBJECT(machine),
> >> "ram", ram_size);
> >> -memory_region_add_subregion(addr_space, 0, ram_region);
> >> +memory_region_add_subregion_overlap(addr_space, 0, ram_region, -1);
> >>
> >>/* Init Dino (PCI host bus chip). */
> >>
Re: [PATCH 66/86] ppc:ppc440_bamboo/sam460ex: drop RAM size fixup
On Thu, 2 Jan 2020 16:52:50 +0100 (CET)
BALATON Zoltan wrote:
> On Thu, 2 Jan 2020, Igor Mammedov wrote:
> > On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
> > BALATON Zoltan wrote:
> >> On Tue, 31 Dec 2019, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
> >>> continue running with max RAM size supported.
> >>> Also RAM is going to be allocated by generic code, so it won't be
> >>> possible for board to fix things up for user.
> >>>
> >>> Make it error message and exit to force user fix CLI,
> >>> instead of accepting non-sense CLI values.
> >>>
> >>> Signed-off-by: Igor Mammedov
> >>> ---
> >>> include/hw/ppc/ppc4xx.h | 9 -
> >>> hw/ppc/ppc440_bamboo.c | 11 ---
> >>> hw/ppc/ppc4xx_devs.c| 26 --
> >>> hw/ppc/sam460ex.c | 5 ++---
> >>> 4 files changed, 26 insertions(+), 25 deletions(-)
> >>>
> >>> diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
> >>> index 7d82259..1a28127 100644
> >>> --- a/include/hw/ppc/ppc4xx.h
> >>> +++ b/include/hw/ppc/ppc4xx.h
> >>> @@ -42,11 +42,10 @@ enum {
> >>> qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
> >>>uint32_t dcr_base, int has_ssr, int has_vr);
> >>>
> >>> -ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
> >>> - MemoryRegion ram_memories[],
> >>> - hwaddr ram_bases[],
> >>> - hwaddr ram_sizes[],
> >>> - const ram_addr_t sdram_bank_sizes[]);
> >>> +void ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
> >>> + MemoryRegion ram_memories[],
> >>> + hwaddr ram_bases[], hwaddr ram_sizes[],
> >>> + const ram_addr_t sdram_bank_sizes[]);
> >>
> >> With this change this function does not adjust ram size any more so it may
> >> need to be renamed, e.g. ppc4xx_sdram_banks or something else.
> >>
> >> A better patch title may be
> >>
> >> ppc/{ppc440_bamboo,sam460x}: drop RAM size fixup
> >>
> >> (or without curly braces at your preference).
> > I'll rename and use this subj as you suggest on v2.
> >
> >> This is inconvenient for the user because it worked whatever number
> >> they've given but now they have to do the math. So it suggests that what
> >> you're replacing this with may not support all the existing use cases. If
> >> that can't be fixed to allow checking and changing ram size (maybe via a
> >> callback in board code similar to above adjust function returning adjusted
> >> size) it may be OK to drop this convenience for the sake of cleaning up
> >> code elsewhere.
> >
> > There were few boards that did fix up and in all cases it was to cover up
> > invalid CLI input.
> > Creating callback for fixing user mistake doesn't seems to me justified,
> > I'd much prefer to have a hard error and consistent behavior across all
> > the boards versus being lax on error checking.
> >
> > [...]
> >
> >
> >>> @@ -699,10 +698,19 @@ ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size,
> >>> int nr_banks,
> >>> }
> >>> }
> >>>
> >>> -ram_size -= size_left;
> >>> if (size_left) {
> >>> -error_report("Truncating memory to %" PRId64 " MiB to fit SDRAM"
> >>> - " controller limits", ram_size / MiB);
> >>> +char *s = g_strdup("");
> >>> +for (i = 0; sdram_bank_sizes[i]; i++) {
> >>> +char *t = g_strdup_printf("%s%" PRIi64 "%s", s,
> >>> sdram_bank_sizes[i],
> >>> + sdram_bank_sizes[i + 1] ? " ," :
> >>> "");
> >>> +g_free(s);
> >>> +s = t;
> >>> +}
> >>> +error_report("Invalid RAM size, unable to fit all RAM into RAM
> >>> banks"
> >>> + " (unassigned RAM: %" PRIi64 ")", size_left);
> >>> +error_report("Supported: %d banks and sizes/bank: %s", nr_banks,
> >>> s);
> >
> > Do you have any suggestions how to make error message better?
> > (maybe do calculation here and dump all valid -m variants instead of
> > "#bank,size/bank")
>
> Listing the valid values would certainly help users who don't know what
> the constraints of the SoC or SPD ROMs are (which I think most users don't
> have a clue about and we should not expect them to know). I've also seen
ok, I'll go ahead with it.
> similar concerns in another response for hppa machines so maybe having a
> callback to allow adjusting user input to board constraints is not a bad
> idea. It's not lax error checking but convenience for the average user
> where board has specific constraints and cannot handle any mem size.
It could be usefull to generalize and probably introspect valid/supported
RAM sizes but I doubt it would be easy to sell a callback for fixing up
invalid user input vs just a hard error.
Anyways it looks out of scope of this series and could be done on top if
there is dema
Re: [PATCH] hppa: allow max ram size upto 4Gb
On 1/2/20 6:08 PM, Igor Mammedov wrote:
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience to allow using -m 4G vs -m 3840M.
Requested-by: Helge Deller
Signed-off-by: Igor Mammedov
---
I dislike it but if you feel it's really necessary feel free to ack it.
should be applied on top of:
"hppa: drop RAM size fixup"
---
hw/hppa/machine.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index ebbf44f..7f8c92f 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -54,6 +54,7 @@ static uint64_t cpu_hppa_to_phys(void *opaque, uint64_t addr)
static HPPACPU *cpu[HPPA_MAX_CPUS];
static uint64_t firmware_entry;
+static ram_addr_t clamped_ram_size;
static void machine_hppa_init(MachineState *machine)
{
@@ -74,8 +75,6 @@ static void machine_hppa_init(MachineState *machine)
long i;
unsigned int smp_cpus = machine->smp.cpus;
-ram_size = machine->ram_size;
-
/* Create CPUs. */
for (i = 0; i < smp_cpus; i++) {
char *name = g_strdup_printf("cpu%ld-io-eir", i);
@@ -90,10 +89,12 @@ static void machine_hppa_init(MachineState *machine)
}
/* Limit main memory. */
-if (ram_size > FIRMWARE_START) {
-error_report("RAM size more than %d is not supported", FIRMWARE_START);
+if (machine->ram_size > 4 * GiB) {
+error_report("RAM size more than 4Gb is not supported");
exit(EXIT_FAILURE);
}
+clamped_ram_size = machine->ram_size > FIRMWARE_START ?
+FIRMWARE_START : machine->ram_size;
memory_region_add_subregion(addr_space, 0, machine->ram);
@@ -151,7 +152,7 @@ static void machine_hppa_init(MachineState *machine)
qemu_log_mask(CPU_LOG_PAGE, "Firmware loaded at 0x%08" PRIx64
"-0x%08" PRIx64 ", entry at 0x%08" PRIx64 ".\n",
firmware_low, firmware_high, firmware_entry);
-if (firmware_low < ram_size || firmware_high >= FIRMWARE_END) {
+if (firmware_low < clamped_ram_size || firmware_high >= FIRMWARE_END) {
error_report("Firmware overlaps with memory or IO space");
exit(1);
}
@@ -160,7 +161,8 @@ static void machine_hppa_init(MachineState *machine)
rom_region = g_new(MemoryRegion, 1);
memory_region_init_ram(rom_region, NULL, "firmware",
(FIRMWARE_END - FIRMWARE_START), &error_fatal);
-memory_region_add_subregion(addr_space, FIRMWARE_START, rom_region);
+memory_region_add_subregion_overlap(addr_space, FIRMWARE_START, rom_region,
+1);
I don't think this is enough because we also have:
(qemu) info mtree
address-space: memory
f900-f90007ff (prio 0, i/o): isa-io
fff8-fff80fff (prio 0, i/o): dino
fff83800-fff83807 (prio 0, i/o): serial
fffb-fffb0003 (prio 0, i/o): cpu0-io-eir
Which is why I went the other way around, using prio=-1 for the ram.
/* Load kernel */
if (kernel_filename) {
@@ -204,7 +206,7 @@ static void machine_hppa_init(MachineState *machine)
(1) Due to sign-extension problems and PDC,
put the initrd no higher than 1G.
(2) Reserve 64k for stack. */
-initrd_base = MIN(ram_size, 1 * GiB);
+initrd_base = MIN(clamped_ram_size, 1 * GiB);
initrd_base = initrd_base - 64 * KiB;
initrd_base = (initrd_base - initrd_size) & TARGET_PAGE_MASK;
@@ -232,7 +234,7 @@ static void machine_hppa_init(MachineState *machine)
* various parameters in registers. After firmware initialization,
* firmware will start the Linux kernel with ramdisk and cmdline.
*/
-cpu[0]->env.gr[26] = ram_size;
+cpu[0]->env.gr[26] = clamped_ram_size;
cpu[0]->env.gr[25] = kernel_entry;
/* tell firmware how many SMP CPUs to present in inventory table */
@@ -255,11 +257,11 @@ static void hppa_machine_reset(MachineState *ms)
}
/* already initialized by machine_hppa_init()? */
-if (cpu[0]->env.gr[26] == ram_size) {
+if (cpu[0]->env.gr[26] == clamped_ram_size) {
return;
}
-cpu[0]->env.gr[26] = ram_size;
+cpu[0]->env.gr[26] = clamped_ram_size;
cpu[0]->env.gr[25] = 0; /* no firmware boot menu */
cpu[0]->env.gr[24] = 'c';
/* gr22/gr23 unused, no initrd while reboot. */
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 1/2/20 5:50 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 16:49:00 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 4:08 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported", FIRMWARE_START);
+exit(EXIT_FAILURE);
$ qemu-system-hppa -m 3841m
qemu-system-hppa: invalid accelerator kvm
qemu-system-hppa: falling back to tcg
qemu-system-hppa: RAM size more than -268435456 is not supported
Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we can simply use
"RAM size more than 3840m is not supported". Is that OK with you?
I don't really like that change.
We currently only emulate a 32-bit system, and for those 4GB is the maximum.
So, if I start my machine with "qemu-system-hppa -m 4G", the current code
then automatically uses the maximum possible of 3841MB (which is limited by
firmware start address).
I don't expect users to know the excact 3841MB number.
Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
but not "3841MB".
Thanks for the explanation. This deserves a comment in the source file
IMHO (and displaying a warning to the user that the behavior is changed).
I understand the CPU can't access this DRAM area because the ROM is
mapped there. What about other devices, can they do DMA access to it?
Igor: If this complicates your series too much, I think we can directly
allocate up-to 4GiB and not worry about the 256MiB lost.
Do you mean
s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
supported"/
Works for me! You can keep my R-b with this change, thanks.
Well, it's not that simple.
Do we map whole 4G in address space, if yes then we have to "unbreak"
firmware mapping and use overlap mapping or do we map only portion of it?
Both would make code more confusing and all for the sake of user convenience
so they won't have to change their CLI?
I was thinking about this patch:
it probably should be a bit more complicated.
-- >8 --
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26140..fa0b6a9536 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -91,15 +91,16 @@ static void machine_hppa_init(MachineState *machine)
}
/* Limit main memory. */
-if (ram_size > FIRMWARE_START) {
-machine->ram_size = ram_size = FIRMWARE_START;
+if (ram_size > 4 * GiB) {
+error_report("Can not model more than 4GB of RAM");
+exit(EXIT_FAILURE);
}
/* Main memory region. */
ram_region = g_new(MemoryRegion, 1);
memory_region_allocate_system_memory(ram_region, OBJECT(machine),
"ram", ram_size);
-memory_region_add_subregion(addr_space, 0, ram_region);
+memory_region_add_subregion_overlap(addr_space, 0, ram_region, -1);
/* Init Dino (PCI host bus chip). */
pci_bus = dino_init(addr_space, &rtc_irq, &serial_irq);
Ok, I give up on trying to convince you to avoid relaxing error check
but I'd make it an extra patch on top of "[PATCH 43/86] hppa: drop RAM size
fixup"
as it's a separate change.
I am simply not understanding what you are suggesting...
Can you share a diff snippet of what you would prefer?
[PATCH] hppa: allow max ram size upto 4Gb
Previous patch drops silent ram_size fixup and makes
QEMU error out with:
"RAM size more than 3840m is not supported"
when user specified -m X more than supported value.
User shouldn't be bothered with starting QEMU with valid CLI,
so for the sake of user convenience to allow using -m 4G vs -m 3840M.
Requested-by: Helge Deller
Signed-off-by: Igor Mammedov
---
I dislike it but if you feel it's really necessary feel free to ack it.
should be applied on top of:
"hppa: drop RAM size fixup"
---
hw/hppa/machine.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index ebbf44f..7f8c92f 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -54,6 +54,7 @@ static uint64_t cpu_hppa_to_phys(void *opaque, uint64_t addr)
static HPPACPU *cpu[HPPA_MAX_CPUS];
static uint64_t firmware_entry;
+static ram_addr_t clamped_ram_size;
static void machine_hppa_init(MachineState *machine)
{
@@ -74,8 +75,6 @@ static void machine_hppa_init(MachineState *machine)
long i;
unsigned int smp_cpus = machine->smp.cpus;
-ram_size = machine->ram_size;
-
/* Create CPUs. */
for (i = 0; i < smp_cpus; i++) {
char *name = g_strdup_printf("cpu%ld-io-eir", i);
@@ -90,10 +89,12 @@ static void machine_hppa_init(MachineState *machine)
}
/* Limit main memory. */
-if (ram_size > FIRMWARE_START) {
-error_report("RAM size more than %d is not supported", FIRMWARE_START);
+if (machine->ram_size > 4 * GiB) {
+error_report("RAM size more than 4Gb is not supported");
exit(EXIT_FAILURE);
}
+clamped_ram_size = machine->ram_size > FIRMWARE_START ?
+FIRMWARE_START : machine->ram_size;
memory_region_add_subregion(addr_space, 0, machine->ram);
@@ -151,7 +152,7 @@ static void machine_hppa_init(MachineState *machine)
qemu_log_mask(CPU_LOG_PAGE, "Firmware loaded at 0x%08" PRIx64
"-0x%08" PRIx64 ", entry at 0x%08" PRIx64 ".\n",
firmware_low, firmware_high, firmware_entry);
-if (firmware_low < ram_size || firmware_high >= FIRMWARE_END) {
+if (firmware_low < clamped_ram_size || firmware_high >= FIRMWARE_END) {
error_report("Firmware overlaps with memory or IO space");
exit(1);
}
@@ -160,7 +161,8 @@ static void machine_hppa_init(MachineState *machine)
rom_region = g_new(MemoryRegion, 1);
memory_region_init_ram(rom_region, NULL, "firmware",
(FIRMWARE_END - FIRMWARE_START), &error_fatal);
-memory_region_add_subregion(addr_space, FIRMWARE_START, rom_region);
+memory_region_add_subregion_overlap(addr_space, FIRMWARE_START, rom_region,
+1);
/* Load kernel */
if (kernel_filename) {
@@ -204,7 +206,7 @@ static void machine_hppa_init(MachineState *machine)
(1) Due to sign-extension problems and PDC,
put the initrd no higher than 1G.
(2) Reserve 64k for stack. */
-initrd_base = MIN(ram_size, 1 * GiB);
+initrd_base = MIN(clamped_ram_size, 1 * GiB);
initrd_base = initrd_base - 64 * KiB;
initrd_base = (initrd_base - initrd_size) & TARGET_PAGE_MASK;
@@ -232,7 +234,7 @@ static void machine_hppa_init(MachineState *machine)
* various parameters in registers. After firmware initialization,
* firmware will start the Linux kernel with ramdisk and cmdline.
*/
-cpu[0]->env.gr[26] = ram_size;
+cpu[0]->env.gr[26] = clamped_ram_size;
cpu[0]->env.gr[25] = kernel_entry;
/* tell firmware how many SMP CPUs to present in inventory table */
@@ -255,11 +257,11 @@ static void hppa_machine_reset(MachineState *ms)
}
/* already initialized by machine_hppa_init()? */
-if (cpu[0]->env.gr[26] == ram_size) {
+if (cpu[0]->env.gr[26] == clamped_ram_size) {
return;
}
-cpu[0]->env.gr[26] = ram_size;
+cpu[0]->env.gr[26] = clamped_ram_size;
cpu[0]->env.gr[25] = 0; /* no firmware boot menu */
cpu[0]->env.gr[24] = 'c';
/* gr22/gr23 unused, no initrd while reboot. */
--
2.7.4
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 16:49:00 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 4:08 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 15:17:14 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> >>> On Thu, 2 Jan 2020 13:06:33 +0100
> >>> Philippe Mathieu-Daudé wrote:
> >>>
> On 1/2/20 12:31 PM, Helge Deller wrote:
> > On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
> >>> continue running with max RAM size supported.
> >>> Also RAM is going to be allocated by generic code, so it won't be
> >>> possible for board to fix things up for user.
> >>>
> >>> Make it error message and exit to force user fix CLI,
> >>> instead of accepting non-sense CLI values.
> >>>
> >>> Signed-off-by: Igor Mammedov
> >>> ---
> >>> hw/hppa/machine.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> >>> index 5d0de26..25f5afc 100644
> >>> --- a/hw/hppa/machine.c
> >>> +++ b/hw/hppa/machine.c
> >>> @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> >>> /* Limit main memory. */
> >>> if (ram_size > FIRMWARE_START) {
> >>> - machine->ram_size = ram_size = FIRMWARE_START;
> >>> + error_report("RAM size more than %d is not supported",
> >>> FIRMWARE_START);
> >>> +exit(EXIT_FAILURE);
> >>
> >> $ qemu-system-hppa -m 3841m
> >> qemu-system-hppa: invalid accelerator kvm
> >> qemu-system-hppa: falling back to tcg
> >> qemu-system-hppa: RAM size more than -268435456 is not supported
> >>
> >> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned
> >> format, we can simply use "RAM size more than 3840m is not supported".
> >> Is that OK with you?
> >
> > I don't really like that change.
> >
> > We currently only emulate a 32-bit system, and for those 4GB is the
> > maximum.
> > So, if I start my machine with "qemu-system-hppa -m 4G", the current
> > code
> > then automatically uses the maximum possible of 3841MB (which is
> > limited by
> > firmware start address).
> > I don't expect users to know the excact 3841MB number.
> > Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or
> > 4GB,
> > but not "3841MB".
>
> Thanks for the explanation. This deserves a comment in the source file
> IMHO (and displaying a warning to the user that the behavior is changed).
>
> I understand the CPU can't access this DRAM area because the ROM is
> mapped there. What about other devices, can they do DMA access to it?
>
> Igor: If this complicates your series too much, I think we can directly
> allocate up-to 4GiB and not worry about the 256MiB lost.
> >>>
> >>> Do you mean
> >>> s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
> >>> supported"/
> >>
> >> Works for me! You can keep my R-b with this change, thanks.
> >
> > Well, it's not that simple.
> > Do we map whole 4G in address space, if yes then we have to "unbreak"
> > firmware mapping and use overlap mapping or do we map only portion of it?
> > Both would make code more confusing and all for the sake of user convenience
> > so they won't have to change their CLI?
>
> I was thinking about this patch:
it probably should be a bit more complicated.
>
> -- >8 --
> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> index 5d0de26140..fa0b6a9536 100644
> --- a/hw/hppa/machine.c
> +++ b/hw/hppa/machine.c
> @@ -91,15 +91,16 @@ static void machine_hppa_init(MachineState *machine)
> }
>
> /* Limit main memory. */
> -if (ram_size > FIRMWARE_START) {
> -machine->ram_size = ram_size = FIRMWARE_START;
> +if (ram_size > 4 * GiB) {
> +error_report("Can not model more than 4GB of RAM");
> +exit(EXIT_FAILURE);
> }
>
> /* Main memory region. */
> ram_region = g_new(MemoryRegion, 1);
> memory_region_allocate_system_memory(ram_region, OBJECT(machine),
>"ram", ram_size);
> -memory_region_add_subregion(addr_space, 0, ram_region);
> +memory_region_add_subregion_overlap(addr_space, 0, ram_region, -1);
>
> /* Init Dino (PCI host bus chip). */
> pci_bus = dino_init(addr_space, &rtc_irq, &serial_irq);
Ok, I give up on trying to convince you to avoid relaxing error check
but I'd make it an extra patch on top of "[PATCH 43/86] hppa: drop RAM size
fixup"
as it's a separate change.
> ---
>
> $ hppa-softmmu/qemu-system-hppa -m 3840m -S -monitor stdio
> QEMU 4.2.50 monitor - type 'help' for more information
> (qemu) info mtree
> address-space: memory
>0
Re: [RFC v4 PATCH 00/49] Initial support of multi-process qemu - status update
On Tue, Dec 17, 2019 at 04:33:16PM +, Stefan Hajnoczi wrote: > On Mon, Dec 16, 2019 at 07:57:32PM +, Felipe Franciosi wrote: > > > On 16 Dec 2019, at 20:47, Elena Ufimtseva > > > wrote: > > > On Fri, Dec 13, 2019 at 10:41:16AM +, Stefan Hajnoczi wrote: > > >> Is there a work-in-progress muser patch series you can post to start the > > >> discussion early? That way we can avoid reviewers like myself asking > > >> you to make changes after you have invested a lot of time. > > >> > > > > > > Absolutely, that is our plan. At the moment we do not have the patches > > > ready for the review. We have setup internally a milestone and will be > > > sending that early version as a tarball after we have it completed. > > > Would be also a meeting something that could help us to stay on the same > > > page? > > > > Please loop us in if you so set up a meeting. > Hi Stefan And happy New Year to everyone! > There is a bi-weekly KVM Community Call that we can use for phone > discussions: > > > https://calendar.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ > Our team would like to join the call on Jan 14 and maybe talk over few things. Felipe, will you and your team be joining as well? > Or we can schedule a one-off call at any time :). > Awesome! Thank you, we will use for sure this opportunity. Elena > Questions I've seen when discussing muser with people have been: > > 1. Can unprivileged containers create muser devices? If not, this is a >blocker for use cases that want to avoid root privileges entirely. > > 2. Does muser need to be in the kernel (e.g. slower to develop/ship, >security reasons)? A similar library could be implemented in >userspace along the lines of the vhost-user protocol. Although VMMs >would then need to use a new libmuser-client library instead of >reusing their VFIO code to access the device. > > 3. Should this feature be Linux-only? vhost-user can be implemented on >non-Linux OSes... > > Stefan
Re: [PATCH 66/86] ppc:ppc440_bamboo/sam460ex: drop RAM size fixup
On Thu, 2 Jan 2020, Igor Mammedov wrote:
On Wed, 1 Jan 2020 12:54:37 +0100 (CET)
BALATON Zoltan wrote:
On Tue, 31 Dec 2019, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
include/hw/ppc/ppc4xx.h | 9 -
hw/ppc/ppc440_bamboo.c | 11 ---
hw/ppc/ppc4xx_devs.c| 26 --
hw/ppc/sam460ex.c | 5 ++---
4 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 7d82259..1a28127 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -42,11 +42,10 @@ enum {
qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
uint32_t dcr_base, int has_ssr, int has_vr);
-ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
- MemoryRegion ram_memories[],
- hwaddr ram_bases[],
- hwaddr ram_sizes[],
- const ram_addr_t sdram_bank_sizes[]);
+void ppc4xx_sdram_adjust(ram_addr_t ram_size, int nr_banks,
+ MemoryRegion ram_memories[],
+ hwaddr ram_bases[], hwaddr ram_sizes[],
+ const ram_addr_t sdram_bank_sizes[]);
With this change this function does not adjust ram size any more so it may
need to be renamed, e.g. ppc4xx_sdram_banks or something else.
A better patch title may be
ppc/{ppc440_bamboo,sam460x}: drop RAM size fixup
(or without curly braces at your preference).
I'll rename and use this subj as you suggest on v2.
This is inconvenient for the user because it worked whatever number
they've given but now they have to do the math. So it suggests that what
you're replacing this with may not support all the existing use cases. If
that can't be fixed to allow checking and changing ram size (maybe via a
callback in board code similar to above adjust function returning adjusted
size) it may be OK to drop this convenience for the sake of cleaning up
code elsewhere.
There were few boards that did fix up and in all cases it was to cover up
invalid CLI input.
Creating callback for fixing user mistake doesn't seems to me justified,
I'd much prefer to have a hard error and consistent behavior across all
the boards versus being lax on error checking.
[...]
@@ -699,10 +698,19 @@ ram_addr_t ppc4xx_sdram_adjust(ram_addr_t ram_size, int
nr_banks,
}
}
-ram_size -= size_left;
if (size_left) {
-error_report("Truncating memory to %" PRId64 " MiB to fit SDRAM"
- " controller limits", ram_size / MiB);
+char *s = g_strdup("");
+for (i = 0; sdram_bank_sizes[i]; i++) {
+char *t = g_strdup_printf("%s%" PRIi64 "%s", s,
sdram_bank_sizes[i],
+ sdram_bank_sizes[i + 1] ? " ," : "");
+g_free(s);
+s = t;
+}
+error_report("Invalid RAM size, unable to fit all RAM into RAM banks"
+ " (unassigned RAM: %" PRIi64 ")", size_left);
+error_report("Supported: %d banks and sizes/bank: %s", nr_banks, s);
Do you have any suggestions how to make error message better?
(maybe do calculation here and dump all valid -m variants instead of
"#bank,size/bank")
Listing the valid values would certainly help users who don't know what
the constraints of the SoC or SPD ROMs are (which I think most users don't
have a clue about and we should not expect them to know). I've also seen
similar concerns in another response for hppa machines so maybe having a
callback to allow adjusting user input to board constraints is not a bad
idea. It's not lax error checking but convenience for the average user
where board has specific constraints and cannot handle any mem size.
Regards,
BALATON Zoltan
[Bug 1858046] Re: qemu-aarch64 hangs on cptofs during a build of NixOS SD card image
Update: compiling qemu upstream & using the latest version didn't change anything. I don't know if this is an instance of user emulation limitations due to missing syscalls. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1858046 Title: qemu-aarch64 hangs on cptofs during a build of NixOS SD card image Status in QEMU: New Bug description: First, thank you for this incredible project. While following this guide to build my own image of NixOS: https://nixos.wiki/wiki/NixOS_on_ARM#Compiling_through_QEMU on ARM Aarch64. I encountered a very strange behavior, qemu is correctly used and build most of the binaries until it executes this exact line over qemu: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make- ext4-fs.nix#L55 At this step, the qemu process goes to 100 % of CPU, hangs in a certain syscall I don't know which one (according to strace & gdb which has no symbols so breaking and looking the backtrace was useless). According to iotop, no I/O was done. And it spent all its time in this syscall during more than 10 hours, which looks anomalous to me. I attach some of my CPU info: model : 142 model name: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz stepping : 10 microcode : 0x96 cpu MHz : 3107.071 cache size: 8192 KB I'm using a ThinkPad T480 to perform those builds, I'm uncertain of how to debug further this issue, I discussed this with some people over #nixos-aarch64 and they told me they didn't know how to debug it further too. I tried all with this package: https://aur.archlinux.org/packages /qemu-arm-static/ — I'm currently compiling qemu-git to see if it happens on upstream too. Will comment when it's done. Thank you in advance! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1858046/+subscriptions
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 1/2/20 4:08 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported", FIRMWARE_START);
+exit(EXIT_FAILURE);
$ qemu-system-hppa -m 3841m
qemu-system-hppa: invalid accelerator kvm
qemu-system-hppa: falling back to tcg
qemu-system-hppa: RAM size more than -268435456 is not supported
Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we can simply use
"RAM size more than 3840m is not supported". Is that OK with you?
I don't really like that change.
We currently only emulate a 32-bit system, and for those 4GB is the maximum.
So, if I start my machine with "qemu-system-hppa -m 4G", the current code
then automatically uses the maximum possible of 3841MB (which is limited by
firmware start address).
I don't expect users to know the excact 3841MB number.
Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
but not "3841MB".
Thanks for the explanation. This deserves a comment in the source file
IMHO (and displaying a warning to the user that the behavior is changed).
I understand the CPU can't access this DRAM area because the ROM is
mapped there. What about other devices, can they do DMA access to it?
Igor: If this complicates your series too much, I think we can directly
allocate up-to 4GiB and not worry about the 256MiB lost.
Do you mean
s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
supported"/
Works for me! You can keep my R-b with this change, thanks.
Well, it's not that simple.
Do we map whole 4G in address space, if yes then we have to "unbreak"
firmware mapping and use overlap mapping or do we map only portion of it?
Both would make code more confusing and all for the sake of user convenience
so they won't have to change their CLI?
I was thinking about this patch:
-- >8 --
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26140..fa0b6a9536 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -91,15 +91,16 @@ static void machine_hppa_init(MachineState *machine)
}
/* Limit main memory. */
-if (ram_size > FIRMWARE_START) {
-machine->ram_size = ram_size = FIRMWARE_START;
+if (ram_size > 4 * GiB) {
+error_report("Can not model more than 4GB of RAM");
+exit(EXIT_FAILURE);
}
/* Main memory region. */
ram_region = g_new(MemoryRegion, 1);
memory_region_allocate_system_memory(ram_region, OBJECT(machine),
"ram", ram_size);
-memory_region_add_subregion(addr_space, 0, ram_region);
+memory_region_add_subregion_overlap(addr_space, 0, ram_region, -1);
/* Init Dino (PCI host bus chip). */
pci_bus = dino_init(addr_space, &rtc_irq, &serial_irq);
---
$ hppa-softmmu/qemu-system-hppa -m 3840m -S -monitor stdio
QEMU 4.2.50 monitor - type 'help' for more information
(qemu) info mtree
address-space: memory
- (prio 0, i/o): system
-efff (prio -1, ram): ram
f000-f07f (prio 0, ram): firmware
f900-f90007ff (prio 0, i/o): isa-io
f920-f921 (prio 0, i/o): pic
f970-f971 (prio 0, i/o): rtc
f970-f970 (prio 0, i/o): rtc-index
f9a0-f9a1 (prio 0, i/o): pic
f90004d0-f90004d0 (prio 0, i/o): elcr
f90004d1-f90004d1 (prio 0, i/o): elcr
fff8-fff80fff (prio 0, i/o): dino
fff80064-fff80067 (prio 0, i/o): pci-conf-idx
fff80068-fff8006b (prio 0, i/o): pci-conf-data
fff83800-fff83807 (prio 0, i/o): serial
fffb-fffb0003 (prio 0, i/o): cpu0-io-eir
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 1/2/20 4:35 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 15:45:55 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 3:41 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported", FIRMWARE_START);
+exit(EXIT_FAILURE);
$ qemu-system-hppa -m 3841m
qemu-system-hppa: invalid accelerator kvm
qemu-system-hppa: falling back to tcg
qemu-system-hppa: RAM size more than -268435456 is not supported
Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we can simply use
"RAM size more than 3840m is not supported". Is that OK with you?
I don't really like that change.
We currently only emulate a 32-bit system, and for those 4GB is the maximum.
So, if I start my machine with "qemu-system-hppa -m 4G", the current code
then automatically uses the maximum possible of 3841MB (which is limited by
firmware start address).
I don't expect users to know the excact 3841MB number.
It's annoying to see a error where it used to work before
with no matter what -m value user have used.
But error message tells exact max size one could use,
so user doesn't have to know max, just fix CLI with provided value.
Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
but not "3841MB".
So, I think that patch is - although it's more correct - not a
benefit for the end user.
Sure thing that users dislike when we do breaking changes (removing legacy CLI
options, fixups or adding error checks that weren't there before).
But I'd choose correctness (and consistent codebase) vs convenience.
(it's no like we are hiding max from user)
Going from 3841MB to 4GB is not a breaking change, and 4GB is correct I
under breaking change, I've meant exit with error when it used to work with
any values.
But the point in removing fixups to make user aware of valid input and
make clear what's going on when someone reads the code.
QEMU code is already too complex to read, so I'd avoid supporting values
that are not really supported by current impl. just for the sake of convenience.
(a wrapper script could do that RAM size clamping if it is really necessary)
think. The Raspberry Pi machines do the same (allocate more RAM than the
CPU is able to access, and DMA is able to use this extra RAM).
In current impl. raspi accepts RAM upto 1Gb maps all of it and reports
that size to the guest. QEMU doesn't mask or waste anything.
If we where to rise limit upto 4Gb, then there should be the code that
would inform and allow guest utilize that.
For the raspi2/3, 16MB are lost and we don't complain neither change the
ram_size, see the bcm2835-peripherals block overmapping the ram:
$ qemu-system-aarch64 -M raspi3 -monitor stdio -S
QEMU 3.1.1 monitor - type 'help' for more information
(qemu) info mtree
address-space: memory
- (prio 0, i/o): system
-3fff (prio 0, ram): ram
3f00-3fff (prio 1, i/o): bcm2835-peripherals
3f007000-3f007fff (prio 0, i/o): bcm2835-dma
3f00b200-3f00b3ff (prio 0, i/o): bcm2835-ic
3f00b800-3f00bbff (prio 0, i/o): bcm2835-mbox
3f104000-3f10400f (prio 0, i/o): bcm2835-rng
3f20-3f200fff (prio 0, i/o): bcm2835_gpio
3f201000-3f201fff (prio 0, i/o): pl011
3f202000-3f202fff (prio 0, i/o): bcm2835-sdhost
3f215000-3f2150ff (prio 0, i/o): bcm2835-aux
3f30-3f3000ff (prio 0, i/o): sdhci
3fe05000-3fe050ff (prio 0, i/o): bcm2835-dma-chan15
4000-40ff (prio 0, i/o): bcm2836-control
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 15:45:55 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 3:41 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 12:31:58 +0100
> > Helge Deller wrote:
> >
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> If user provided non-sense RAM size, board will complain and
> continue running with max RAM size supported.
> Also RAM is going to be allocated by generic code, so it won't be
> possible for board to fix things up for user.
>
> Make it error message and exit to force user fix CLI,
> instead of accepting non-sense CLI values.
>
> Signed-off-by: Igor Mammedov
> ---
> hw/hppa/machine.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> index 5d0de26..25f5afc 100644
> --- a/hw/hppa/machine.c
> +++ b/hw/hppa/machine.c
> @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> /* Limit main memory. */
> if (ram_size > FIRMWARE_START) {
> - machine->ram_size = ram_size = FIRMWARE_START;
> + error_report("RAM size more than %d is not supported",
> FIRMWARE_START);
> +exit(EXIT_FAILURE);
> >>>
> >>> $ qemu-system-hppa -m 3841m
> >>> qemu-system-hppa: invalid accelerator kvm
> >>> qemu-system-hppa: falling back to tcg
> >>> qemu-system-hppa: RAM size more than -268435456 is not supported
> >>>
> >>> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format,
> >>> we can simply use "RAM size more than 3840m is not supported". Is that OK
> >>> with you?
> >>
> >> I don't really like that change.
> >>
> >> We currently only emulate a 32-bit system, and for those 4GB is the
> >> maximum.
> >> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
> >> then automatically uses the maximum possible of 3841MB (which is limited by
> >> firmware start address).
> >> I don't expect users to know the excact 3841MB number.
> > It's annoying to see a error where it used to work before
> > with no matter what -m value user have used.
> >
> > But error message tells exact max size one could use,
> > so user doesn't have to know max, just fix CLI with provided value.
> >
> >> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
> >> but not "3841MB".
> >>
> >> So, I think that patch is - although it's more correct - not a
> >> benefit for the end user.
> > Sure thing that users dislike when we do breaking changes (removing legacy
> > CLI
> > options, fixups or adding error checks that weren't there before).
> > But I'd choose correctness (and consistent codebase) vs convenience.
> > (it's no like we are hiding max from user)
>
> Going from 3841MB to 4GB is not a breaking change, and 4GB is correct I
under breaking change, I've meant exit with error when it used to work with
any values.
But the point in removing fixups to make user aware of valid input and
make clear what's going on when someone reads the code.
QEMU code is already too complex to read, so I'd avoid supporting values
that are not really supported by current impl. just for the sake of convenience.
(a wrapper script could do that RAM size clamping if it is really necessary)
> think. The Raspberry Pi machines do the same (allocate more RAM than the
> CPU is able to access, and DMA is able to use this extra RAM).
In current impl. raspi accepts RAM upto 1Gb maps all of it and reports
that size to the guest. QEMU doesn't mask or waste anything.
If we where to rise limit upto 4Gb, then there should be the code that
would inform and allow guest utilize that.
Re: GraphViz extension on QEMU Wiki
On 1/2/20 4:09 PM, Stefan Hajnoczi wrote: On Thu, Dec 26, 2019 at 07:05:04PM +0100, Philippe Mathieu-Daudé wrote: I'm not sure who is responsible of this... Jeff maintains the web server and wiki. I can look into things when Jeff is too busy, but lets see if he has time in January. Sure no problem this is not urgent, this is to improve some documentation and add GSoC ideas. Thanks.
Re: How to impove downtime of Live-Migration caused bdrv_drain_all()
> On Jan 2, 2020, at 3:07 PM, Stefan Hajnoczi wrote: > > On Thu, Dec 26, 2019 at 05:40:22PM +0800, 张海斌 wrote: >> Stefan Hajnoczi 于2019年3月29日周五 上午1:08写道： >>> >>> On Thu, Mar 28, 2019 at 05:53:34PM +0800, 张海斌 wrote: hi, stefan I have faced the same problem you wrote in https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04025.html Reproduce as follow: 1. Clone qemu code from https://git.qemu.org/git/qemu.git, add some debug information and compile 2. Start a new VM 3. In VM, use fio randwrite to add pressure for disk 4. Live migrate Log show as follow: [2019-03-28 15:10:40.206] /data/qemu/cpus.c:1086: enter do_vm_stop [2019-03-28 15:10:40.212] /data/qemu/cpus.c:1097: call bdrv_drain_all [2019-03-28 15:10:40.989] /data/qemu/cpus.c:1099: call replay_disable_events [2019-03-28 15:10:40.989] /data/qemu/cpus.c:1101: call bdrv_flush_all [2019-03-28 15:10:41.004] /data/qemu/cpus.c:1104: done do_vm_stop Calling bdrv_drain_all() costs 792 mini-seconds. I just add a bdrv_drain_all() at start of do_vm_stop() before pause_all_vcpus(), but it doesn't work. Is there any way to improve live-migration downtime cause by bdrv_drain_all()? > > I believe there were ideas about throttling storage controller devices > during the later phases of live migration to reduce the number of > pending I/Os. > > In other words, if QEMU's virtio-blk/scsi emulation code reduces the > queue depth as live migration nears the handover point, bdrv_drain_all() > should become cheaper because fewer I/O requests will be in-flight. > > A simple solution would reduce the queue depth during live migration > (e.g. queue depth 1). A smart solution would look at I/O request > latency to decide what queue depth is acceptable. For example, if > requests are taking 4 ms to complete then we might allow 2 or 3 requests > to achieve a ~10 ms bdrv_drain_all() downtime target. > > As far as I know this has not been implemented. > > Do you want to try implementing this? > > Stefan It is a really hard problem to solve. Ultimately, if guarantees are needed about the blackout period, I don't see any viable solution other than aborting all pending storage commands. Starting with a "go to QD=1 mode" approach is probably sensible. Vhost-based backends could even do that off the "you need to log" message, given that these are only used during migration. Having a "you are taking too long, abort everything" command might be something worth looking into, specially if we can *safely* replay them on the other side. (That may be backend-dependent.) F.
Re: qemu_set_fd_handler callback is delayed
On Mon, Dec 30, 2019 at 06:21:27PM +, Eltahawy, Mahmoud wrote: > I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for > qemu_set_fd_handler that the callback for reading from a file descriptor is > delayed then expected while the file descriptor(socket) has a data to read. > > I register a callback for reading from a socket using qemu_set_fd_handler and > during runtime, this callback is not invoked for about 14msec, however the > socket has a data available for read. I tested this behavior by just creating > a pthread which periodically checks the socket for any data using > ioctl(socket_fd, FIONREAD, &count), and for a period of 14ms, I found that > the pthread indicates there is a data in the socket while the > qemu_set_fd_handler didn't trigger the read callback. QEMU uses an event loop. If another handler takes 14 ms to execute, then the fd handler could be delayed. Is there other event loop activity? Also, a polling thread will respond more quickly than the event loop because the event loop thread is waiting for the host kernel scheduler to wake it up. When the host is under heavy load this could take some time, depending on the scheduler and its settings. Was the machine under heavy CPU load? Stefan signature.asc Description: PGP signature
Re: Making QEMU easier for management tools and applications
* Stefan Hajnoczi (stefa...@gmail.com) wrote: > 5. A jailer is needed to isolate the QEMU process and vhost-user > device backends using seccomp, Linux namespaces, and maybe > SELinux/AppArmor. We used to be able to rely on libvirt for QEMU > security, but it's becoming a common task for any device backend and > IMO should be its own launcher tool. It feels like there's two parts to this: a) The sandboxing at startup b) Then whatever comms is needed to allow things like hotplugging afterwards, passing fd's etc you'd think (a) would be some code that would be shared between logs of projects. Dave > 6. A configuration file format is sorely needed so that guest > configuration can be persisted and easily launched. Today you have to > create a shell script that executes a QEMU command-line, but this is > suboptimal because sharing executable scripts is dangerous from a > security perspective and is hard to parse or modify programmatically. > > In many of these areas we already have a partial solution. It just > needs more work. I think it would be worth the effort and the mental > shift to really providing APIs that are easy to use by applications. > > What do you think? > > Have I missed things that are needed? > > Have I included things that are unnecessary? > > Stefan > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: GraphViz extension on QEMU Wiki
On Thu, Dec 26, 2019 at 07:05:04PM +0100, Philippe Mathieu-Daudé wrote: > I'm not sure who is responsible of this... Jeff maintains the web server and wiki. I can look into things when Jeff is too busy, but lets see if he has time in January. Stefan signature.asc Description: PGP signature
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 15:17:14 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 3:12 PM, Igor Mammedov wrote:
> > On Thu, 2 Jan 2020 13:06:33 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> On 1/2/20 12:31 PM, Helge Deller wrote:
> >>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> > If user provided non-sense RAM size, board will complain and
> > continue running with max RAM size supported.
> > Also RAM is going to be allocated by generic code, so it won't be
> > possible for board to fix things up for user.
> >
> > Make it error message and exit to force user fix CLI,
> > instead of accepting non-sense CLI values.
> >
> > Signed-off-by: Igor Mammedov
> > ---
> > hw/hppa/machine.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> > index 5d0de26..25f5afc 100644
> > --- a/hw/hppa/machine.c
> > +++ b/hw/hppa/machine.c
> > @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> > /* Limit main memory. */
> > if (ram_size > FIRMWARE_START) {
> > - machine->ram_size = ram_size = FIRMWARE_START;
> > + error_report("RAM size more than %d is not supported",
> > FIRMWARE_START);
> > +exit(EXIT_FAILURE);
>
> $ qemu-system-hppa -m 3841m
> qemu-system-hppa: invalid accelerator kvm
> qemu-system-hppa: falling back to tcg
> qemu-system-hppa: RAM size more than -268435456 is not supported
>
> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format,
> we can simply use "RAM size more than 3840m is not supported". Is that
> OK with you?
> >>>
> >>> I don't really like that change.
> >>>
> >>> We currently only emulate a 32-bit system, and for those 4GB is the
> >>> maximum.
> >>> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
> >>> then automatically uses the maximum possible of 3841MB (which is limited
> >>> by
> >>> firmware start address).
> >>> I don't expect users to know the excact 3841MB number.
> >>> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or
> >>> 4GB,
> >>> but not "3841MB".
> >>
> >> Thanks for the explanation. This deserves a comment in the source file
> >> IMHO (and displaying a warning to the user that the behavior is changed).
> >>
> >> I understand the CPU can't access this DRAM area because the ROM is
> >> mapped there. What about other devices, can they do DMA access to it?
> >>
> >> Igor: If this complicates your series too much, I think we can directly
> >> allocate up-to 4GiB and not worry about the 256MiB lost.
> >
> > Do you mean
> > s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
> > supported"/
>
> Works for me! You can keep my R-b with this change, thanks.
Well, it's not that simple.
Do we map whole 4G in address space, if yes then we have to "unbreak"
firmware mapping and use overlap mapping or do we map only portion of it?
Both would make code more confusing and all for the sake of user convenience
so they won't have to change their CLI?
> >>> So, I think that patch is - although it's more correct - not a
> >>> benefit for the end user.
> >>>
> >>> Helge
> >>>
> >>
> >>
> >
>
Re: How to impove downtime of Live-Migration caused bdrv_drain_all()
On Thu, Dec 26, 2019 at 05:40:22PM +0800, 张海斌 wrote: > Stefan Hajnoczi 于2019年3月29日周五 上午1:08写道： > > > > On Thu, Mar 28, 2019 at 05:53:34PM +0800, 张海斌 wrote: > > > hi, stefan > > > > > > I have faced the same problem you wrote in > > > https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04025.html > > > > > > Reproduce as follow: > > > 1. Clone qemu code from https://git.qemu.org/git/qemu.git, add some > > > debug information and compile > > > 2. Start a new VM > > > 3. In VM, use fio randwrite to add pressure for disk > > > 4. Live migrate > > > > > > Log show as follow: > > > [2019-03-28 15:10:40.206] /data/qemu/cpus.c:1086: enter do_vm_stop > > > [2019-03-28 15:10:40.212] /data/qemu/cpus.c:1097: call bdrv_drain_all > > > [2019-03-28 15:10:40.989] /data/qemu/cpus.c:1099: call > > > replay_disable_events > > > [2019-03-28 15:10:40.989] /data/qemu/cpus.c:1101: call bdrv_flush_all > > > [2019-03-28 15:10:41.004] /data/qemu/cpus.c:1104: done do_vm_stop > > > > > > Calling bdrv_drain_all() costs 792 mini-seconds. > > > I just add a bdrv_drain_all() at start of do_vm_stop() before > > > pause_all_vcpus(), but it doesn't work. > > > Is there any way to improve live-migration downtime cause by > > > bdrv_drain_all()? I believe there were ideas about throttling storage controller devices during the later phases of live migration to reduce the number of pending I/Os. In other words, if QEMU's virtio-blk/scsi emulation code reduces the queue depth as live migration nears the handover point, bdrv_drain_all() should become cheaper because fewer I/O requests will be in-flight. A simple solution would reduce the queue depth during live migration (e.g. queue depth 1). A smart solution would look at I/O request latency to decide what queue depth is acceptable. For example, if requests are taking 4 ms to complete then we might allow 2 or 3 requests to achieve a ~10 ms bdrv_drain_all() downtime target. As far as I know this has not been implemented. Do you want to try implementing this? Stefan signature.asc Description: PGP signature
Re: Making QEMU easier for management tools and applications
* Markus Armbruster (arm...@redhat.com) wrote: > Stefan Hajnoczi writes: > > 4. Go and Rust bindings would also be useful. There is > > https://github.com/intel/govmm but I think it makes sense to keep it > > in qemu.git and provide an interface similar to our Python modules. > > Mapping QAPI/QMP commands and events to function signatures isn't hard > (the QAPI code generator does). Two problems (at least): > > 1. Leads to some pretty ridiculous functions. Here's one: > > void qmp_blockdev_mirror(bool has_job_id, const char *job_id, > const char *device, > const char *target, > bool has_replaces, const char *replaces, > MirrorSyncMode sync, > bool has_speed, int64_t speed, > bool has_granularity, uint32_t granularity, > bool has_buf_size, int64_t buf_size, > bool has_on_source_error, > BlockdevOnError on_source_error, > bool has_on_target_error, BlockdevOnError > on_target_error, > bool has_filter_node_name, const char > *filter_node_name, > bool has_copy_mode, MirrorCopyMode copy_mode, > bool has_auto_finalize, bool auto_finalize, > bool has_auto_dismiss, bool auto_dismiss, > Error **errp); Those might not be as bad when mapped to other languages, all the bool/value pairs would become Option<...> so that removes that doubling. The Error ** mechanism should somehow map onto functions returning a normal Rust Result<> type. Dave > We commonly use 'boxed': true for such beasts, which results in > functions like this one: > > void qmp_blockdev_add(BlockdevOptions *arg, Error **errp); > > 2. Many schema changes that are nicely backward compatible in QMP are >anything but in such an "obvious" C API. Adding optional arguments, >for instance, or changing integer type width. The former is less of >an issue with 'boxed': true. > > Perhaps less of an issue with dynamic languages. > > I figure a static language would need much more expressive oomph than C > to be a good target. No idea how well Go or Rust bindings can work. > > > 5. A jailer is needed to isolate the QEMU process and vhost-user > > device backends using seccomp, Linux namespaces, and maybe > > SELinux/AppArmor. We used to be able to rely on libvirt for QEMU > > security, but it's becoming a common task for any device backend and > > IMO should be its own launcher tool. > > Perhaps the libvirt refactoring effort can give us one. > > > 6. A configuration file format is sorely needed so that guest > > configuration can be persisted and easily launched. Today you have to > > create a shell script that executes a QEMU command-line, but this is > > suboptimal because sharing executable scripts is dangerous from a > > security perspective and is hard to parse or modify programmatically. > > No argument. There is -readconfig, but it falls way short. > > With command line QAPIfication, a real configuration file will be quite > feasible. > > The main reason for the lack of progress there is our dedication to > backward compatibility. A functional replacement of our CLI is a huge > task already. Throwing in backward compatibility makes it a daunting > one. Not least because nobody fully understands all the quirks. > > > In many of these areas we already have a partial solution. It just > > needs more work. I think it would be worth the effort and the mental > > shift to really providing APIs that are easy to use by applications. > > > > What do you think? > > > > Have I missed things that are needed? > > > > Have I included things that are unnecessary? > > I feel we need to make up our minds what kind of interface(s) we want to > provide. > > We provide a low-level interface for management applications. I feel we > need to nail this one. Its QMP part is okay, I think, the CLI part is > not. > > We also try to provide friendlier interfaces for human users. Not only > do we suck at it, we're also prone to create liabilities for later: much > of the compatibility woes that have been holding us back are rooted in > "convenience" features. And don't get me started on the folly of us > dabbling in GUI. > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v1] virtio: stregthen virtqueue size invariants
On Mon, Dec 23, 2019 at 04:18:20PM +0300, Denis Plotnikov wrote:
> 1. virtqueue_size is a power of 2
> 2. virtqueue_size > 2, since seg_max is virtqueue_size - 2
>
> Signed-off-by: Denis Plotnikov
> ---
> hw/virtio/virtio.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 04716b5f6c..e3ab69061e 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -2166,7 +2166,8 @@ void virtio_queue_set_num(VirtIODevice *vdev, int n,
> int num)
> */
> if (!!num != !!vdev->vq[n].vring.num ||
> num > VIRTQUEUE_MAX_SIZE ||
> -num < 0) {
> +num < 2 ||
This is generic VIRTIO code so it's not possible to make assumptions
about seg_max, which is a virtio-blk/scsi concept. Other VIRTIO devices
may tolerate num < 2 just fine. Please drop this.
> +!is_power_of_2(num)) {
This constraint only applies to the Split Virtqueue layout. Please see
VIRTIO 1.1 "2.7.10.1 Structure Size and Alignment" for the Packed
Virtqueue layout:
The Queue Size value does not have to be a power of 2.
The condition should be:
!(virtio_has_features(vdev, VIRTIO_F_RING_PACKED) || is_power_of_2(num))
signature.asc
Description: PGP signature
CONFIG_JUMP_LABEL=y on 32-bit x86 leads to intermittent qemu crashes
Hi, Here's an interesting crash I've seen pop up since enabling CONFIG_JUMP_LABEL=y: [4.716238] EIP: secure_tcp_seq+0x1e/0xa0^M [4.716238] Code: c1 e8 46 90 fb ff eb a2 8d 74 26 00 55 89 e5 83 ec 18 89 75 f8 89 c6 0f b7 45 08 89 5d f4 0f b7 d9 89 7d fc 89 d7 89 45 ec 3e <8d> 74 26 00 8b 4d ec c1 e3 10 89 fa c7 04 24 d0 e3 36 c1 89 f0 09^M [4.716238] EAX: 90bc EBX: 5114 ECX: 5114 EDX: 01f1a8c0^M [4.716238] ESI: 02f1a8c0 EDI: 01f1a8c0 EBP: c010bb88 ESP: c010bb70^M [4.716238] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS: 0282^M [4.716238] CR0: 80050033 CR2: bfcd7fb0 CR3: 0038 CR4: 0690^M [4.716238] Call Trace:^M [4.716238] ^M [4.716238] tcp_v4_init_seq+0x3d/0x50^M [4.716238] tcp_conn_request+0x35d/0x926^M [4.716238] ? fib6_table_lookup+0xb5/0x210^M [4.716238] ? ip_route_input_slow+0x864/0x900^M ... It looks like this is: secure_tcp_seq -> net_secret_init-> net_get_random_once(&net_secret, sizeof(net_secret)) get_random_once(&net_secret, sizeof(net_secret)) DO_ONCE(get_random_bytes(&net_secret, sizeof(net_secret))) Which then expands to the usual static_key logic. I was only able to reproduce this when the host system running `qemu-system-i386 -m 256M -smp 4 -cpu coreduo -machine q35` is under considerable load. Is there a TCG issue with how it handles the dynamic patching debug instructions? Jason
Re: Making QEMU easier for management tools and applications
On Sat, Dec 21, 2019 at 10:02:23AM +0100, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
> > Hi,
> > QEMU presents a command-line interface and QMP monitor for
> > applications to interact with. Applications actually need API
> > bindings in their programming language. Bindings avoid reimplementing
> > code to spawn a QEMU process and interact with QMP. QEMU is kind of
> > lazy and de facto relies on libvirt for API bindings.
> >
> > Is it time for better QEMU APIs?
> >
> > 1. We have qapi-schema.json. Let's render to HTML and publish
> > versioned documentation online.
>
> Make can build docs/interop/qemu-qmp-ref.{7,html,info,pdf,txt}. Grab
> the .html and go for it. There's also qmp-ga-ref.
The missing step here is to integrate doc generation and upload into the
release process so the documentation is published.
Once my recent documentation publishing patches have been merged I'll
see if Mike Roth wants to extend the release scripts.
> > 2. scripts/qmp/ contains command-line tools for QMP communication.
> > They could use some polish and then be shipped.
>
> MAINTAINERS blames them on me, but they're effectively unmaintained.
> Prerequisite for shipping: having a maintainer who actually gives a
> damn.
...
> * scripts/qmp/qmp-shell
>
> Half-hearted attempt at a human-friendly wrapper around the JSON
> syntax. I have no use for this myself.
I think this one is used by people. John Snow comes to mind.
> > 3. python/qemu/ contains Python modules for managing a QEMU process
> > and QMP communication. This should be packaged in distros and
> > available on PyPI.
>
> Currently maintained by Eduardo and Cleber (cc'ed) under "Python
> scripts".
>
> > 4. Go and Rust bindings would also be useful. There is
> > https://github.com/intel/govmm but I think it makes sense to keep it
> > in qemu.git and provide an interface similar to our Python modules.
>
> Mapping QAPI/QMP commands and events to function signatures isn't hard
> (the QAPI code generator does). Two problems (at least):
>
> 1. Leads to some pretty ridiculous functions. Here's one:
>
> void qmp_blockdev_mirror(bool has_job_id, const char *job_id,
> const char *device,
> const char *target,
> bool has_replaces, const char *replaces,
> MirrorSyncMode sync,
> bool has_speed, int64_t speed,
> bool has_granularity, uint32_t granularity,
> bool has_buf_size, int64_t buf_size,
> bool has_on_source_error,
> BlockdevOnError on_source_error,
> bool has_on_target_error, BlockdevOnError
> on_target_error,
> bool has_filter_node_name, const char
> *filter_node_name,
> bool has_copy_mode, MirrorCopyMode copy_mode,
> bool has_auto_finalize, bool auto_finalize,
> bool has_auto_dismiss, bool auto_dismiss,
> Error **errp);
>
> We commonly use 'boxed': true for such beasts, which results in
> functions like this one:
>
> void qmp_blockdev_add(BlockdevOptions *arg, Error **errp);
>
> 2. Many schema changes that are nicely backward compatible in QMP are
>anything but in such an "obvious" C API. Adding optional arguments,
>for instance, or changing integer type width. The former is less of
>an issue with 'boxed': true.
>
> Perhaps less of an issue with dynamic languages.
>
> I figure a static language would need much more expressive oomph than C
> to be a good target. No idea how well Go or Rust bindings can work.
Most of what govmm does is build QEMU command-lines, not wrap QMP APIs.
Native QMP API bindings are harder and we'd need to see who really needs
this. Languages with a built-in dict type like Python make working with
JSON-level QMP feasible. In C it's painful though and native API
bindings are desirable.
signature.asc
Description: PGP signature
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 14:02:01 +0100
Helge Deller wrote:
> On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> > On 1/2/20 12:31 PM, Helge Deller wrote:
> >> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> If user provided non-sense RAM size, board will complain and
> continue running with max RAM size supported.
> Also RAM is going to be allocated by generic code, so it won't be
> possible for board to fix things up for user.
>
> Make it error message and exit to force user fix CLI,
> instead of accepting non-sense CLI values.
>
> Signed-off-by: Igor Mammedov
> ---
> hw/hppa/machine.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> index 5d0de26..25f5afc 100644
> --- a/hw/hppa/machine.c
> +++ b/hw/hppa/machine.c
> @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> /* Limit main memory. */
> if (ram_size > FIRMWARE_START) {
> - machine->ram_size = ram_size = FIRMWARE_START;
> + error_report("RAM size more than %d is not supported",
> FIRMWARE_START);
> + exit(EXIT_FAILURE);
> >>>
> >>> $ qemu-system-hppa -m 3841m
> >>> qemu-system-hppa: invalid accelerator kvm
> >>> qemu-system-hppa: falling back to tcg
> >>> qemu-system-hppa: RAM size more than -268435456 is not supported
> >>>
> >>> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format,
> >>> we can simply use "RAM size more than 3840m is not supported". Is that OK
> >>> with you?
> >>
> >> I don't really like that change.
> >>
> >> We currently only emulate a 32-bit system, and for those 4GB is the
> >> maximum.
> >> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
> >> then automatically uses the maximum possible of 3841MB (which is limited by
> >> firmware start address).
> >> I don't expect users to know the excact 3841MB number.
> >> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
> >> but not "3841MB".
> >
> > Thanks for the explanation. This deserves a comment in the source
> > file IMHO (and displaying a warning to the user that the behavior is
> > changed).
>
> If you put 4GB physically in the box, you wouldn't get a warning either...
> It will simply use just 3841MB.
>
> > I understand the CPU can't access this DRAM area because the ROM is
> > mapped there. What about other devices, can they do DMA access to
> > it?
>
> Yes, I think so.
Question is if is it supported/used in current impl?
If it's not then lets keep a hard error providing the exact max value,
instead of complicating code for unclear benefit.
>
> > Igor: If this complicates your series too much, I think we can
> > directly allocate up-to 4GiB and not worry about the 256MiB lost.
>
> Sounds like the best solution.
>
> Helge
>
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 1/2/20 3:41 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported", FIRMWARE_START);
+exit(EXIT_FAILURE);
$ qemu-system-hppa -m 3841m
qemu-system-hppa: invalid accelerator kvm
qemu-system-hppa: falling back to tcg
qemu-system-hppa: RAM size more than -268435456 is not supported
Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we can simply use
"RAM size more than 3840m is not supported". Is that OK with you?
I don't really like that change.
We currently only emulate a 32-bit system, and for those 4GB is the maximum.
So, if I start my machine with "qemu-system-hppa -m 4G", the current code
then automatically uses the maximum possible of 3841MB (which is limited by
firmware start address).
I don't expect users to know the excact 3841MB number.
It's annoying to see a error where it used to work before
with no matter what -m value user have used.
But error message tells exact max size one could use,
so user doesn't have to know max, just fix CLI with provided value.
Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
but not "3841MB".
So, I think that patch is - although it's more correct - not a
benefit for the end user.
Sure thing that users dislike when we do breaking changes (removing legacy CLI
options, fixups or adding error checks that weren't there before).
But I'd choose correctness (and consistent codebase) vs convenience.
(it's no like we are hiding max from user)
Going from 3841MB to 4GB is not a breaking change, and 4GB is correct I
think. The Raspberry Pi machines do the same (allocate more RAM than the
CPU is able to access, and DMA is able to use this extra RAM).
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 12:31:58 +0100
Helge Deller wrote:
> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> > On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >> If user provided non-sense RAM size, board will complain and
> >> continue running with max RAM size supported.
> >> Also RAM is going to be allocated by generic code, so it won't be
> >> possible for board to fix things up for user.
> >>
> >> Make it error message and exit to force user fix CLI,
> >> instead of accepting non-sense CLI values.
> >>
> >> Signed-off-by: Igor Mammedov
> >> ---
> >> hw/hppa/machine.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> >> index 5d0de26..25f5afc 100644
> >> --- a/hw/hppa/machine.c
> >> +++ b/hw/hppa/machine.c
> >> @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> >> /* Limit main memory. */
> >> if (ram_size > FIRMWARE_START) {
> >> - machine->ram_size = ram_size = FIRMWARE_START;
> >> + error_report("RAM size more than %d is not supported",
> >> FIRMWARE_START);
> >> +exit(EXIT_FAILURE);
> >
> > $ qemu-system-hppa -m 3841m
> > qemu-system-hppa: invalid accelerator kvm
> > qemu-system-hppa: falling back to tcg
> > qemu-system-hppa: RAM size more than -268435456 is not supported
> >
> > Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we
> > can simply use "RAM size more than 3840m is not supported". Is that OK with
> > you?
>
> I don't really like that change.
>
> We currently only emulate a 32-bit system, and for those 4GB is the maximum.
> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
> then automatically uses the maximum possible of 3841MB (which is limited by
> firmware start address).
> I don't expect users to know the excact 3841MB number.
It's annoying to see a error where it used to work before
with no matter what -m value user have used.
But error message tells exact max size one could use,
so user doesn't have to know max, just fix CLI with provided value.
> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
> but not "3841MB".
>
> So, I think that patch is - although it's more correct - not a
> benefit for the end user.
Sure thing that users dislike when we do breaking changes (removing legacy CLI
options, fixups or adding error checks that weren't there before).
But I'd choose correctness (and consistent codebase) vs convenience.
(it's no like we are hiding max from user)
> Helge
>
Re: Making QEMU easier for management tools and applications
On Tue, Dec 24, 2019 at 01:00:35PM +, Daniel P. Berrangé wrote: > On Fri, Dec 20, 2019 at 04:13:59PM +, Stefan Hajnoczi wrote: > > Hi, > > QEMU presents a command-line interface and QMP monitor for > > applications to interact with. Applications actually need API > > bindings in their programming language. Bindings avoid reimplementing > > code to spawn a QEMU process and interact with QMP. QEMU is kind of > > lazy and de facto relies on libvirt for API bindings. > > > > Is it time for better QEMU APIs? > > > > 1. We have qapi-schema.json. Let's render to HTML and publish > > versioned documentation online. > > You have patches to publish this to the website already which is > good for git master. We still need to get this published for > stable releases, ideally we would have up to publish it for our > pre-existing stable releases back a year or two too. > > At the same time though this is insufficient. It is *really* hard > to understand how QAPI schema maps to either JSON or CLI args for > either QMP or the CLI. Most docs examples just talk in terms of > -drive. I think the qapi schema docs could benefit from more > work to provide real world example usage inline. > > > > 2. scripts/qmp/ contains command-line tools for QMP communication. > > They could use some polish and then be shipped. > > The qmp-shell in particular is interesting. Libvirt has a similar > need for a simpler way to deal with QMP and "virsh qemu-monitor-command" > has notable overlap with functionality of qmp-shell. > > I wonder if there's a way to spin this off so that we have have a > standard QMP client shell that can either talk direct to a UNIX > socket, or indirect via libvirt's QMP command passthrough APIs. A standard (and easier-to-use and powerful) QMP shell would be nice. > > 3. python/qemu/ contains Python modules for managing a QEMU process > > and QMP communication. This should be packaged in distros and > > available on PyPI. > > > > 4. Go and Rust bindings would also be useful. There is > > https://github.com/intel/govmm but I think it makes sense to keep it > > in qemu.git and provide an interface similar to our Python modules. > > Presumably you mean bindings for the QMP commands ? This will > quickly expand to mean bindings for every aspect of QEMU configuration > that's currently QAPI-ified. It will quickly become a very big job > to design, develop & maintain, especially if you want to support > multiple languages in a natural way. No, I mean just launching QEMU and communicating over QMP. I think creating bindings for QMP commands is too much effort. It would duplicate the QAPI schema documentation because we'd need native API documentation too. I think clients should work at the QMP JSON level. > > 5. A jailer is needed to isolate the QEMU process and vhost-user > > device backends using seccomp, Linux namespaces, and maybe > > SELinux/AppArmor. We used to be able to rely on libvirt for QEMU > > security, but it's becoming a common task for any device backend and > > IMO should be its own launcher tool. > > Based on experiance in libvirt, this is an even larger job than (4), > as the feature set here is huge. Much of it directly ties into the > config problem, as to deal with SELinux / namespace setup the code > needs to understand what resources to provide access to. This > requires a way to express 100% coverage of all QEMU configuration > in use & analyse it to determine what resources it implies. So this > ties strongly into QAPI-ification completion. I don't have a clear design in mind yet but I've learnt a little from writing the virtiofsd namespace isolation and seccomp code. The task is really hard for a general-purpose QEMU binary that supports all features, because configuring the sandbox with the minimal attack surface requires knowledge of the feature set being used in this QEMU invocation :(. > On the libvirt side, we've a strong long term desire to move our > codebase from C to either Go or Rust. In doing this refactoring > and rewriting, we would quite likely end up with self-contained > packages / modules / APIs that can be used independantly of the > main libvirt API. Thus there's probably scope here to collaborate > between libvirt & QEMU communities to develop new APIs. > > Some of this code could be directly QEMU related, but other parts > of the code are likely to be generic & not tied to QEMU at all. > For example libvirt's SELinux, namespace, cgroup setup code is used > by LXC too. Thus from the libvirt POV, some libraries might be > deliverable by QEMU project, but others might be deliverable by > libvirt project. Or might be scope for a indepent new project to > deliver pieces. I think duplication is in the nature of these isolation mechanisms. systemd also supports most of the features necessary for isolation but neither QEMU nor libvirt take advantage of systemd and it's not easy to do so either. I think it will be necessary to be pragmatic and lo
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 1/2/20 3:12 PM, Igor Mammedov wrote:
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported", FIRMWARE_START);
+exit(EXIT_FAILURE);
$ qemu-system-hppa -m 3841m
qemu-system-hppa: invalid accelerator kvm
qemu-system-hppa: falling back to tcg
qemu-system-hppa: RAM size more than -268435456 is not supported
Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we can simply use
"RAM size more than 3840m is not supported". Is that OK with you?
I don't really like that change.
We currently only emulate a 32-bit system, and for those 4GB is the maximum.
So, if I start my machine with "qemu-system-hppa -m 4G", the current code
then automatically uses the maximum possible of 3841MB (which is limited by
firmware start address).
I don't expect users to know the excact 3841MB number.
Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
but not "3841MB".
Thanks for the explanation. This deserves a comment in the source file
IMHO (and displaying a warning to the user that the behavior is changed).
I understand the CPU can't access this DRAM area because the ROM is
mapped there. What about other devices, can they do DMA access to it?
Igor: If this complicates your series too much, I think we can directly
allocate up-to 4GiB and not worry about the 256MiB lost.
Do you mean
s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
supported"/
Works for me! You can keep my R-b with this change, thanks.
So, I think that patch is - although it's more correct - not a
benefit for the end user.
Helge
Re: [PATCH v2] q800: implement mac rom reset function for BIOS-less mode
Le 02/01/2020 à 13:01, Jason A. Donenfeld a écrit :
> On Linux, calling `reboot(RB_AUTOBOOT);` will result in
> arch/m68k/mac/misc.c's mac_reset function being called. That in turn
> looks at the rombase (or uses 0x4080 is there's no rombase), adds
> 0xa, and jumps to that address. At the moment, there's nothing there, so
> the kernel just crashes when trying to reboot. So, this commit adds a
> very simple implementation at that location, which just writes to via2
> to power down. We also correct the value of ROMBASE while we're at it.
>
> Signed-off-by: Jason A. Donenfeld
> ---
> hw/m68k/q800.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
> index 4ca8678007..f03679e24c 100644
> --- a/hw/m68k/q800.c
> +++ b/hw/m68k/q800.c
> @@ -47,7 +47,7 @@
> #include "sysemu/runstate.h"
> #include "sysemu/reset.h"
>
> -#define MACROM_ADDR 0x4000
> +#define MACROM_ADDR 0x4080
> #define MACROM_SIZE 0x0010
>
> #define MACROM_FILENAME "MacROM.bin"
> @@ -128,6 +128,27 @@ static void main_cpu_reset(void *opaque)
> cpu->env.pc = ldl_phys(cs->as, 4);
> }
>
> +static uint8_t fake_mac_rom[] = {
> +0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> +
> +/* offset: 0xa - mac_reset */
> +
> +/* via2[vDirB] |= VIA2B_vPower */
> +0x20, 0x7C, 0x50, 0xF0, 0x24, 0x00, /* moveal VIA2_BASE+vDirB,%a0 */
> +0x10, 0x10, /* moveb %a0@,%d0 */
> +0x00, 0x00, 0x00, 0x04, /* orib #4,%d0 */
> +0x10, 0x80, /* moveb %d0,%a0@ */
> +
> +/* via2[vBufB] &= ~VIA2B_vPower */
> +0x20, 0x7C, 0x50, 0xF0, 0x20, 0x00, /* moveal VIA2_BASE+vBufB,%a0 */
> +0x10, 0x10, /* moveb %a0@,%d0 */
> +0x02, 0x00, 0xFF, 0xFB, /* andib #-5,%d0 */
> +0x10, 0x80, /* moveb %d0,%a0@ */
> +
> +/* while (true) ; */
> +0x60, 0xFE /* bras [self] */
> +};
> +
> static void q800_init(MachineState *machine)
> {
> M68kCPU *cpu = NULL;
> @@ -340,6 +361,12 @@ static void q800_init(MachineState *machine)
>(graphic_width * graphic_depth + 7) / 8);
> BOOTINFO1(cs->as, parameters_base, BI_MAC_SCCBASE, SCC_BASE);
>
> +rom = g_malloc(sizeof(*rom));
> +memory_region_init_ram_ptr(rom, NULL, "m68k_fake_mac.rom",
> + sizeof(fake_mac_rom), fake_mac_rom);
> +memory_region_set_readonly(rom, true);
> +memory_region_add_subregion(get_system_memory(), MACROM_ADDR, rom);
> +
> if (kernel_cmdline) {
> BOOTINFOSTR(cs->as, parameters_base, BI_COMMAND_LINE,
> kernel_cmdline);
>
Reviewed-by: Laurent Vivier
Re: [PATCH 43/86] hppa: drop RAM size fixup
On Thu, 2 Jan 2020 13:06:33 +0100
Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
> > On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
> >> On 12/31/19 2:03 PM, Igor Mammedov wrote:
> >>> If user provided non-sense RAM size, board will complain and
> >>> continue running with max RAM size supported.
> >>> Also RAM is going to be allocated by generic code, so it won't be
> >>> possible for board to fix things up for user.
> >>>
> >>> Make it error message and exit to force user fix CLI,
> >>> instead of accepting non-sense CLI values.
> >>>
> >>> Signed-off-by: Igor Mammedov
> >>> ---
> >>> hw/hppa/machine.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
> >>> index 5d0de26..25f5afc 100644
> >>> --- a/hw/hppa/machine.c
> >>> +++ b/hw/hppa/machine.c
> >>> @@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
> >>> /* Limit main memory. */
> >>> if (ram_size > FIRMWARE_START) {
> >>> - machine->ram_size = ram_size = FIRMWARE_START;
> >>> + error_report("RAM size more than %d is not supported",
> >>> FIRMWARE_START);
> >>> +exit(EXIT_FAILURE);
> >>
> >> $ qemu-system-hppa -m 3841m
> >> qemu-system-hppa: invalid accelerator kvm
> >> qemu-system-hppa: falling back to tcg
> >> qemu-system-hppa: RAM size more than -268435456 is not supported
> >>
> >> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we
> >> can simply use "RAM size more than 3840m is not supported". Is that OK
> >> with you?
> >
> > I don't really like that change.
> >
> > We currently only emulate a 32-bit system, and for those 4GB is the maximum.
> > So, if I start my machine with "qemu-system-hppa -m 4G", the current code
> > then automatically uses the maximum possible of 3841MB (which is limited by
> > firmware start address).
> > I don't expect users to know the excact 3841MB number.
> > Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
> > but not "3841MB".
>
> Thanks for the explanation. This deserves a comment in the source file
> IMHO (and displaying a warning to the user that the behavior is changed).
>
> I understand the CPU can't access this DRAM area because the ROM is
> mapped there. What about other devices, can they do DMA access to it?
>
> Igor: If this complicates your series too much, I think we can directly
> allocate up-to 4GiB and not worry about the 256MiB lost.
Do you mean
s/"RAM size more than %d is not supported"/"RAM size more than 4Gb is not
supported"/
> > So, I think that patch is - although it's more correct - not a
> > benefit for the end user.
> >
> > Helge
> >
>
>
[Bug 1829459] Re: qemu seems to lack support for pid namespace.
I think you should investigate
`qemu: qemu_thread_create: Invalid argument`
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in QEMU:
New
Bug description:
# Version
qemu-4.0.0
glibc-2.28
# commands used to launch qemu-aarch64 in user mode.
: ${QEMU_BINFMT_FLAGS:=OC}
printf '%s\n' ':qemu-
aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin
/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}"
>/proc/sys/fs/binfmt_misc/register
> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin
> sudo chroot $RPI /bin/ksh -l
# host
Gentoo Linux amd64
# Guest
Gentoo Linux aarch64
# The problem that I have
"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid
argument".
"emerge" is Gentoo's package manager that compiles and installs packages.
# Workaround
Disable pid-sandbox in emerge.
# How to reproduce the issue
Execute
unshare --pid -- echo hello world
or
python -c "import portage.process; portage.process.spawn(['echo',
'hello', 'world'], unshare_pid=True)"
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1829459/+subscriptions
[Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.
I executed "emerge" with QEMU_LOG=unimp and QEMU_STRACE="". ** Attachment added: "emerge.log" https://bugs.launchpad.net/qemu/+bug/1857811/+attachment/5317106/+files/emerge.log -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1857811 Title: qemu user static binary seems to lack support for network namespace. Status in QEMU: New Bug description: Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message. Unable to configure loopback interface: Operation not supported If I disable emerge's network-sandbox which utilizes network namespace, the error disappears. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1857811/+subscriptions
Re: [PATCH] q800: implement mac rom reset function for BIOS-less mode
On Thu, Jan 2, 2020 at 12:41 PM Laurent Vivier wrote: > > Le 02/01/2020 à 12:10, Laurent Vivier a écrit : > > Le 02/01/2020 à 11:36, Jason A. Donenfeld a écrit : > >> On Linux, calling `reboot(RB_AUTOBOOT);` will result in > >> arch/m68k/mac/misc.c's mac_reset function being called. That in turn > >> looks at the rombase (or uses 0x4080 is there's no rombase), adds > >> 0xa, and jumps to that address. At the moment, there's nothing there, so > >> the kernel just crashes when trying to reboot. So, this commit adds a > >> very simple implementation at that location, which just writes to via2 > >> to power down. > >> > >> Signed-off-by: Jason A. Donenfeld > >> --- > > > > There are two cleaners solution to do that: > > 1- catch the jump to the ROM address in QEMU and shutdown the machine, see > > > > https://github.com/vivier/qemu-m68k/commit/51cd57d1128059819038b9800455fbf794430c15 > > > > 2- or as you do, write a fake ROM but use the VIA2 port B bit 3 to > > shutdown the machine see hw/misc/mac_via.c mos6522_q800_via2_portB_write(). > > OK, 2 is what you do, so I think we can take this. > > The assembly code is correct but not easy to read, could you use defined > values (VIA_BASE) and add some comments? > > I think we don't need the BI_MAC_ROMBASE: in fact MACROM_ADDR is wrong, > you can change its definition to 0x4080. > > Thanks, > Laurent I've addressed your comments and submitted v2.
[Bug 1829459] Re: qemu seems to lack support for pid namespace.
In a native chroot, `sudo unshare --pid -- echo hello world` works
without a problem.
In a qemu-aarch64 chroot, `sudo unshare --keep-caps --pid -- echo hello
world` fails with the same error described in this issue.
`qemu: qemu_thread_create: Invalid argument`
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in QEMU:
New
Bug description:
# Version
qemu-4.0.0
glibc-2.28
# commands used to launch qemu-aarch64 in user mode.
: ${QEMU_BINFMT_FLAGS:=OC}
printf '%s\n' ':qemu-
aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin
/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}"
>/proc/sys/fs/binfmt_misc/register
> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin
> sudo chroot $RPI /bin/ksh -l
# host
Gentoo Linux amd64
# Guest
Gentoo Linux aarch64
# The problem that I have
"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid
argument".
"emerge" is Gentoo's package manager that compiles and installs packages.
# Workaround
Disable pid-sandbox in emerge.
# How to reproduce the issue
Execute
unshare --pid -- echo hello world
or
python -c "import portage.process; portage.process.spawn(['echo',
'hello', 'world'], unshare_pid=True)"
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1829459/+subscriptions
[Bug 1829459] Re: qemu seems to lack support for pid namespace.
According to `man unshare`, --keep-caps seems to apply only to user
namespace.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in QEMU:
New
Bug description:
# Version
qemu-4.0.0
glibc-2.28
# commands used to launch qemu-aarch64 in user mode.
: ${QEMU_BINFMT_FLAGS:=OC}
printf '%s\n' ':qemu-
aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin
/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}"
>/proc/sys/fs/binfmt_misc/register
> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin
> sudo chroot $RPI /bin/ksh -l
# host
Gentoo Linux amd64
# Guest
Gentoo Linux aarch64
# The problem that I have
"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid
argument".
"emerge" is Gentoo's package manager that compiles and installs packages.
# Workaround
Disable pid-sandbox in emerge.
# How to reproduce the issue
Execute
unshare --pid -- echo hello world
or
python -c "import portage.process; portage.process.spawn(['echo',
'hello', 'world'], unshare_pid=True)"
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1829459/+subscriptions
Re: [PATCH 3/3] iotests: Test external snapshot with VM state
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 19.12.2019 um 15:26 hat Max Reitz geschrieben:
> > On 17.12.19 15:59, Kevin Wolf wrote:
> > > This tests creating an external snapshot with VM state (which results in
> > > an active overlay over an inactive backing file, which is also the root
> > > node of an inactive BlockBackend), re-activating the images and
> > > performing some operations to test that the re-activation worked as
> > > intended.
> > >
> > > Signed-off-by: Kevin Wolf
> >
> > [...]
> >
> > > diff --git a/tests/qemu-iotests/280.out b/tests/qemu-iotests/280.out
> > > new file mode 100644
> > > index 00..5d382faaa8
> > > --- /dev/null
> > > +++ b/tests/qemu-iotests/280.out
> > > @@ -0,0 +1,50 @@
> > > +Formatting 'TEST_DIR/PID-base', fmt=qcow2 size=67108864
> > > cluster_size=65536 lazy_refcounts=off refcount_bits=16
> > > +
> > > +=== Launch VM ===
> > > +Enabling migration QMP events on VM...
> > > +{"return": {}}
> > > +
> > > +=== Migrate to file ===
> > > +{"execute": "migrate", "arguments": {"uri": "exec:cat > /dev/null"}}
> > > +{"return": {}}
> > > +{"data": {"status": "setup"}, "event": "MIGRATION", "timestamp":
> > > {"microseconds": "USECS", "seconds": "SECS"}}
> > > +{"data": {"status": "active"}, "event": "MIGRATION", "timestamp":
> > > {"microseconds": "USECS", "seconds": "SECS"}}
> > > +{"data": {"status": "completed"}, "event": "MIGRATION", "timestamp":
> > > {"microseconds": "USECS", "seconds": "SECS"}}
> > > +
> > > +VM is now stopped:
> > > +completed
> > > +{"execute": "query-status", "arguments": {}}
> > > +{"return": {"running": false, "singlestep": false, "status":
> > > "postmigrate"}}
> >
> > Hmmm, I get a finish-migrate status here (on tmpfs)...
>
> Dave, is it intentional that the "completed" migration event is emitted
> while we are still in finish-migration rather than postmigrate?
Yes it looks like it; it's that the migration state machine hits
COMPLETED that then _causes_ the runstate transitition to POSTMIGRATE.
static void migration_iteration_finish(MigrationState *s)
{
/* If we enabled cpu throttling for auto-converge, turn it off. */
cpu_throttle_stop();
qemu_mutex_lock_iothread();
switch (s->state) {
case MIGRATION_STATUS_COMPLETED:
migration_calculate_complete(s);
runstate_set(RUN_STATE_POSTMIGRATE);
break;
then there are a bunch of error cases where if it landed in
FAILED/CANCELLED etc then we either restart the VM or also go to
POSTMIGRATE.
> I guess we could change wait_migration() in qemu-iotests to wait for the
> postmigrate state rather than the "completed" event, but maybe it would
> be better to change the migration code to avoid similar races in other
> QMP clients.
Given that the migration state machine is driving the runstate state
machine I think it currently makes sense internally; (although I don't
think it's documented to be in that order or tested to be, which we
might want to fix).
Looking at 234 and 262, it looks like you're calling wait_migration on
both the source and dest; I don't think the dest will see the
POSTMIGRATE. Also note that depending what you're trying to do, with
postcopy you'll be running on the destination before you see COMPLETED.
Waiting for the destination to leave 'inmigrate' state is probably
the best strategy; then wait for the source to be in postmigrate.
You can cause early exits if you see transitions to 'FAILED' - but
actually the destination will likely quit in that case; so it should
be much rarer for you to hit a timeout on a failed migration.
Dave
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 02.01.20 13:06, Philippe Mathieu-Daudé wrote:
> On 1/2/20 12:31 PM, Helge Deller wrote:
>> On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
>>> On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported",
FIRMWARE_START);
+ exit(EXIT_FAILURE);
>>>
>>> $ qemu-system-hppa -m 3841m
>>> qemu-system-hppa: invalid accelerator kvm
>>> qemu-system-hppa: falling back to tcg
>>> qemu-system-hppa: RAM size more than -268435456 is not supported
>>>
>>> Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we
>>> can simply use "RAM size more than 3840m is not supported". Is that OK with
>>> you?
>>
>> I don't really like that change.
>>
>> We currently only emulate a 32-bit system, and for those 4GB is the maximum.
>> So, if I start my machine with "qemu-system-hppa -m 4G", the current code
>> then automatically uses the maximum possible of 3841MB (which is limited by
>> firmware start address).
>> I don't expect users to know the excact 3841MB number.
>> Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
>> but not "3841MB".
>
> Thanks for the explanation. This deserves a comment in the source
> file IMHO (and displaying a warning to the user that the behavior is
> changed).
If you put 4GB physically in the box, you wouldn't get a warning either...
It will simply use just 3841MB.
> I understand the CPU can't access this DRAM area because the ROM is
> mapped there. What about other devices, can they do DMA access to
> it?
Yes, I think so.
> Igor: If this complicates your series too much, I think we can
> directly allocate up-to 4GiB and not worry about the 256MiB lost.
Sounds like the best solution.
Helge
Re: [PULL 0/7] Screendump patches
On Thu, Jan 2, 2020 at 3:55 PM Marc-André Lureau wrote: > > The following changes since commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc: > > Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191219' into > staging (2019-12-20 16:37:07 +) > > are available in the Git repository at: > > https://github.com/elmarco/qemu.git tags/screendump-pull-request > > for you to fetch changes up to 6b8d2a5132378ac19cf93597dad694ea764cca4f: > > screendump: use qemu_unlink() (2020-01-02 13:54:57 +0400) > > > console: screendump improvements > > Hi, > > The following patches have been extracted from the "[PATCH v6 00/25] > monitor: add asynchronous command type", as they are > reviewable/mergeable independantly. > > They introduce some internal API changes, and fix > qemu_open()/qemu_close()/unlink() misusages which should be quite > harmless. > > > > Marc-André Lureau (7): > console: add graphic_hw_update_done() > ppm-save: pass opened fd > ui: add pixman image g_autoptr support > object: add g_autoptr support > screendump: replace FILE with QIOChannel and fix close()/qemu_close() > osdep: add qemu_unlink() > screendump: use qemu_unlink() > > hw/display/qxl-render.c | 9 +++-- > hw/display/qxl.c | 1 + > include/qemu/osdep.h | 1 + > include/qom/object.h | 3 ++ > include/ui/console.h | 2 ++ > include/ui/qemu-pixman.h | 2 ++ > ui/console.c | 74 +--- > ui/trace-events | 2 +- > util/osdep.c | 15 > 9 files changed, 71 insertions(+), 38 deletions(-) > > -- > 2.24.0.308.g228f53135a > > nack, travis found an issue: error: unused variable 'error' [-Werror,-Wunused-variable] g_autoptr(GError) error = NULL; -- Marc-André Lureau
[Bug 1829459] Re: qemu seems to lack support for pid namespace.
PID namespace prevents to execute some syscalls, even if you use --map-
root-user. This is managed at kernel level by the capabilities.
Could you try to do the exact same thing with the native architecture
binaries in the chroot to see if the problem really comes from qemu-
user?
Could you try to use the latest unshare version (util-linux package)
that adds a "--keep-caps" parameter (v2.35-rc1) to preserve the
capabilities?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829459
Title:
qemu seems to lack support for pid namespace.
Status in QEMU:
New
Bug description:
# Version
qemu-4.0.0
glibc-2.28
# commands used to launch qemu-aarch64 in user mode.
: ${QEMU_BINFMT_FLAGS:=OC}
printf '%s\n' ':qemu-
aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin
/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}"
>/proc/sys/fs/binfmt_misc/register
> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin
> sudo chroot $RPI /bin/ksh -l
# host
Gentoo Linux amd64
# Guest
Gentoo Linux aarch64
# The problem that I have
"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid
argument".
"emerge" is Gentoo's package manager that compiles and installs packages.
# Workaround
Disable pid-sandbox in emerge.
# How to reproduce the issue
Execute
unshare --pid -- echo hello world
or
python -c "import portage.process; portage.process.spawn(['echo',
'hello', 'world'], unshare_pid=True)"
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1829459/+subscriptions
Re: [PATCH 43/86] hppa: drop RAM size fixup
On 1/2/20 12:31 PM, Helge Deller wrote:
On 31.12.19 16:44, Philippe Mathieu-Daudé wrote:
On 12/31/19 2:03 PM, Igor Mammedov wrote:
If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.
Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.
Signed-off-by: Igor Mammedov
---
hw/hppa/machine.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 5d0de26..25f5afc 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -92,7 +92,8 @@ static void machine_hppa_init(MachineState *machine)
/* Limit main memory. */
if (ram_size > FIRMWARE_START) {
- machine->ram_size = ram_size = FIRMWARE_START;
+ error_report("RAM size more than %d is not supported", FIRMWARE_START);
+exit(EXIT_FAILURE);
$ qemu-system-hppa -m 3841m
qemu-system-hppa: invalid accelerator kvm
qemu-system-hppa: falling back to tcg
qemu-system-hppa: RAM size more than -268435456 is not supported
Instead of using qemu_strtosz_MiB on FIRMWARE_START or unsigned format, we can simply use
"RAM size more than 3840m is not supported". Is that OK with you?
I don't really like that change.
We currently only emulate a 32-bit system, and for those 4GB is the maximum.
So, if I start my machine with "qemu-system-hppa -m 4G", the current code
then automatically uses the maximum possible of 3841MB (which is limited by
firmware start address).
I don't expect users to know the excact 3841MB number.
Even on a phyiscal machine you can only add DIMMs of sizes 2GB, 3GB or 4GB,
but not "3841MB".
Thanks for the explanation. This deserves a comment in the source file
IMHO (and displaying a warning to the user that the behavior is changed).
I understand the CPU can't access this DRAM area because the ROM is
mapped there. What about other devices, can they do DMA access to it?
Igor: If this complicates your series too much, I think we can directly
allocate up-to 4GiB and not worry about the 256MiB lost.
So, I think that patch is - although it's more correct - not a
benefit for the end user.
Helge
[Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.
Could you run qemu unimplemented error trace, by using "export QEMU_LOG=unimp"? You can also set the QEMU_STRACE="" to see which syscall fails. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1857811 Title: qemu user static binary seems to lack support for network namespace. Status in QEMU: New Bug description: Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message. Unable to configure loopback interface: Operation not supported If I disable emerge's network-sandbox which utilizes network namespace, the error disappears. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1857811/+subscriptions
[PATCH v2] q800: implement mac rom reset function for BIOS-less mode
On Linux, calling `reboot(RB_AUTOBOOT);` will result in
arch/m68k/mac/misc.c's mac_reset function being called. That in turn
looks at the rombase (or uses 0x4080 is there's no rombase), adds
0xa, and jumps to that address. At the moment, there's nothing there, so
the kernel just crashes when trying to reboot. So, this commit adds a
very simple implementation at that location, which just writes to via2
to power down. We also correct the value of ROMBASE while we're at it.
Signed-off-by: Jason A. Donenfeld
---
hw/m68k/q800.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 4ca8678007..f03679e24c 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -47,7 +47,7 @@
#include "sysemu/runstate.h"
#include "sysemu/reset.h"
-#define MACROM_ADDR 0x4000
+#define MACROM_ADDR 0x4080
#define MACROM_SIZE 0x0010
#define MACROM_FILENAME "MacROM.bin"
@@ -128,6 +128,27 @@ static void main_cpu_reset(void *opaque)
cpu->env.pc = ldl_phys(cs->as, 4);
}
+static uint8_t fake_mac_rom[] = {
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+
+/* offset: 0xa - mac_reset */
+
+/* via2[vDirB] |= VIA2B_vPower */
+0x20, 0x7C, 0x50, 0xF0, 0x24, 0x00, /* moveal VIA2_BASE+vDirB,%a0 */
+0x10, 0x10, /* moveb %a0@,%d0 */
+0x00, 0x00, 0x00, 0x04, /* orib #4,%d0 */
+0x10, 0x80, /* moveb %d0,%a0@ */
+
+/* via2[vBufB] &= ~VIA2B_vPower */
+0x20, 0x7C, 0x50, 0xF0, 0x20, 0x00, /* moveal VIA2_BASE+vBufB,%a0 */
+0x10, 0x10, /* moveb %a0@,%d0 */
+0x02, 0x00, 0xFF, 0xFB, /* andib #-5,%d0 */
+0x10, 0x80, /* moveb %d0,%a0@ */
+
+/* while (true) ; */
+0x60, 0xFE /* bras [self] */
+};
+
static void q800_init(MachineState *machine)
{
M68kCPU *cpu = NULL;
@@ -340,6 +361,12 @@ static void q800_init(MachineState *machine)
(graphic_width * graphic_depth + 7) / 8);
BOOTINFO1(cs->as, parameters_base, BI_MAC_SCCBASE, SCC_BASE);
+rom = g_malloc(sizeof(*rom));
+memory_region_init_ram_ptr(rom, NULL, "m68k_fake_mac.rom",
+ sizeof(fake_mac_rom), fake_mac_rom);
+memory_region_set_readonly(rom, true);
+memory_region_add_subregion(get_system_memory(), MACROM_ADDR, rom);
+
if (kernel_cmdline) {
BOOTINFOSTR(cs->as, parameters_base, BI_COMMAND_LINE,
kernel_cmdline);
--
2.24.1
[PULL 2/7] ppm-save: pass opened fd
This will allow to pre-open the file before running the async finish
handler and avoid potential monitor fdset races.
(note: this is preliminary work for asynchronous screendump support)
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
ui/console.c| 45 ++---
ui/trace-events | 2 +-
2 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/ui/console.c b/ui/console.c
index 3c941528d2..77d62fe76d 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -193,6 +193,7 @@ static void dpy_refresh(DisplayState *s);
static DisplayState *get_alloc_displaystate(void);
static void text_console_update_cursor_timer(void);
static void text_console_update_cursor(void *opaque);
+static bool ppm_save(int fd, DisplaySurface *ds, Error **errp);
static void gui_update(void *opaque)
{
@@ -308,29 +309,22 @@ void graphic_hw_invalidate(QemuConsole *con)
}
}
-static void ppm_save(const char *filename, DisplaySurface *ds,
- Error **errp)
+static bool ppm_save(int fd, DisplaySurface *ds, Error **errp)
{
int width = pixman_image_get_width(ds->image);
int height = pixman_image_get_height(ds->image);
-int fd;
FILE *f;
int y;
int ret;
pixman_image_t *linebuf;
+bool success = false;
-trace_ppm_save(filename, ds);
-fd = qemu_open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0666);
-if (fd == -1) {
-error_setg(errp, "failed to open file '%s': %s", filename,
- strerror(errno));
-return;
-}
+trace_ppm_save(fd, ds);
f = fdopen(fd, "wb");
ret = fprintf(f, "P6\n%d %d\n%d\n", width, height, 255);
if (ret < 0) {
linebuf = NULL;
-goto write_err;
+goto end;
}
linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, width);
for (y = 0; y < height; y++) {
@@ -339,21 +333,16 @@ static void ppm_save(const char *filename, DisplaySurface
*ds,
ret = fwrite(pixman_image_get_data(linebuf), 1,
pixman_image_get_stride(linebuf), f);
(void)ret;
-if (ferror(f)) {
-goto write_err;
-}
+success = !ferror(f);
}
-out:
+end:
+if (!success) {
+error_setg(errp, "failed to write to PPM file: %s", strerror(errno));
+}
qemu_pixman_image_unref(linebuf);
fclose(f);
-return;
-
-write_err:
-error_setg(errp, "failed to write to file '%s': %s", filename,
- strerror(errno));
-unlink(filename);
-goto out;
+return success;
}
void qmp_screendump(const char *filename, bool has_device, const char *device,
@@ -361,6 +350,7 @@ void qmp_screendump(const char *filename, bool has_device,
const char *device,
{
QemuConsole *con;
DisplaySurface *surface;
+int fd;
if (has_device) {
con = qemu_console_lookup_by_device_name(device, has_head ? head : 0,
@@ -387,7 +377,16 @@ void qmp_screendump(const char *filename, bool has_device,
const char *device,
return;
}
-ppm_save(filename, surface, errp);
+fd = qemu_open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0666);
+if (fd == -1) {
+error_setg(errp, "failed to open file '%s': %s", filename,
+ strerror(errno));
+return;
+}
+
+if (!ppm_save(fd, surface, errp)) {
+unlink(filename);
+}
}
void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata)
diff --git a/ui/trace-events b/ui/trace-events
index 63de72a798..0dcda393c1 100644
--- a/ui/trace-events
+++ b/ui/trace-events
@@ -15,7 +15,7 @@ displaysurface_create_pixman(void *display_surface)
"surface=%p"
displaysurface_free(void *display_surface) "surface=%p"
displaychangelistener_register(void *dcl, const char *name) "%p [ %s ]"
displaychangelistener_unregister(void *dcl, const char *name) "%p [ %s ]"
-ppm_save(const char *filename, void *display_surface) "%s surface=%p"
+ppm_save(int fd, void *display_surface) "fd=%d surface=%p"
# gtk.c
# gtk-gl-area.c
--
2.24.0.308.g228f53135a
[PULL 7/7] screendump: use qemu_unlink()
Don't attempt to remove /dev/fdset files.
Signed-off-by: Marc-André Lureau
Reviewed-by: Daniel P. Berrangé
---
ui/console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/console.c b/ui/console.c
index 587edf4ed4..e6ac462aa0 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -381,7 +381,7 @@ void qmp_screendump(const char *filename, bool has_device,
const char *device,
}
if (!ppm_save(fd, surface, errp)) {
-unlink(filename);
+qemu_unlink(filename);
}
}
--
2.24.0.308.g228f53135a
