Re: [PATCH v2 3/3] hw/{misc, riscv}: pfsoc: add system controller as unimplemented
Hi Conor,
On 12/11/22 14:34, Conor Dooley wrote:
From: Conor Dooley
The system controller on PolarFire SoC is access via a mailbox. The
control registers for this mailbox lie in the "IOSCB" region & the
interrupt is cleared via write to the "SYSREG" region. It also has a
QSPI controller, usually connected to a flash chip, that is used for
storing FPGA bitstreams and used for In-Application Programming (IAP).
Linux has an implementation of the system controller, through which the
hwrng is accessed, leading to load/store access faults.
Add the QSPI as unimplemented and a very basic (effectively
unimplemented) version of the system controller's mailbox. Rather than
purely marking the regions as unimplemented, service the mailbox
requests by reporting failures and raising the interrupt so a guest can
better handle the lack of support.
Signed-off-by: Conor Dooley
---
hw/misc/mchp_pfsoc_ioscb.c | 59 -
hw/misc/mchp_pfsoc_sysreg.c | 19 --
hw/riscv/microchip_pfsoc.c | 6 +++
include/hw/misc/mchp_pfsoc_ioscb.h | 3 ++
include/hw/misc/mchp_pfsoc_sysreg.h | 1 +
include/hw/riscv/microchip_pfsoc.h | 1 +
6 files changed, 83 insertions(+), 6 deletions(-)
@@ -52,10 +54,18 @@ static uint64_t mchp_pfsoc_sysreg_read(void *opaque, hwaddr
offset,
static void mchp_pfsoc_sysreg_write(void *opaque, hwaddr offset,
uint64_t value, unsigned size)
{
-qemu_log_mask(LOG_UNIMP, "%s: unimplemented device write "
- "(size %d, value 0x%" PRIx64
- ", offset 0x%" HWADDR_PRIx ")\n",
- __func__, size, value, offset);
+MchpPfSoCSysregState *s = opaque;
+qemu_irq_lower(s->irq);
Is this always lowered IRQ line wanted? ...
+switch (offset) {
+case MESSAGE_INT:
+qemu_irq_lower(s->irq);
... since we do it here.
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: unimplemented device write "
+ "(size %d, value 0x%" PRIx64
+ ", offset 0x%" HWADDR_PRIx ")\n",
+ __func__, size, value, offset);
+}
}
Re: [PATCH] qga: Add initial OpenBSD and NetBSD support
On 12/11/22 12:40, Brad Smith wrote: qga: Add initial OpenBSD and NetBSD support Signed-off-by: Brad Smith --- meson.build | 2 +- qga/commands-bsd.c | 5 + qga/commands-posix.c | 9 +++-- qga/main.c | 6 +++--- 4 files changed, 16 insertions(+), 6 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v5 09/20] hw/arm: remove current_cpu hack from pxa2xx access
On 11/11/22 19:25, Alex Bennée wrote: We can derive the correct CPU from CPUARMState so lets not rely on current_cpu. Signed-off-by: Alex Bennée --- hw/arm/pxa2xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v5 10/20] target/microblaze: initialise MemTxAttrs for CPU access
On 11/11/22 19:25, Alex Bennée wrote: Both of these functions deal with CPU based access (as is evidenced by the secure check straight after). Use the new MEMTXATTRS_CPU constructor to ensure the correct CPU id is filled in should it ever be needed by any devices later. Signed-off-by: Alex Bennée --- target/microblaze/helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v5 11/20] target/sparc: initialise MemTxAttrs for CPU access
On 11/11/22 19:25, Alex Bennée wrote: Both of the TLB fill functions and the cpu_sparc_get_phys_page deal with CPU based access. Use the new MEMTXATTRS_CPU constructor to ensure the correct CPU id is filled in should it ever be needed by any devices later. Signed-off-by: Alex Bennée --- target/sparc/mmu_helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
[PATCH] capstone: use instead of
The upcoming capstone 5.0 drops support for the old way of including its header, due to this change: https://github.com/capstone-engine/capstone/commit/6656bcb63ab4e87dc6079bd6b6b12cc8dd9b2ad8 The official way is to use This change has already been proposed before, see https://patchwork.kernel.org/project/qemu-devel/patch/20180215173539.11033-1-f4...@amsat.org/ but it didn't find its way into qemu at that time. On current systems, using works now (despite the pkg-config-supplied -I/usr/include/capstone) - since on all systems capstone headers are put into capstone/ subdirectory of a system include dir. So this change is compatible with both the obsolete way of including it and the only future way. I dunno how relevant this is for 7.2, it's probably too late already to test it on everything, but at the same time, once capstone-5 will be released, there will be many user questions about how to build qemu. This has already been asked in #qemu - gentoo already have capstone-5.0-rc and qemu fails to build with that one, but works fine with this change. Cc: Philippe Mathieu-Daudé Signed-off-by: Michael Tokarev --- include/disas/capstone.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/disas/capstone.h b/include/disas/capstone.h index e29068dd97..d8fdc5d537 100644 --- a/include/disas/capstone.h +++ b/include/disas/capstone.h @@ -3,7 +3,7 @@ #ifdef CONFIG_CAPSTONE -#include +#include #else -- 2.30.2
Re: [PATCH v5 14/20] hw/audio: explicitly set .requester_type for intel-hda
On 12/11/22 06:50, Richard Henderson wrote:
On 11/12/22 04:25, Alex Bennée wrote:
This is simulating a bus master writing data back into system memory.
Mark it as such.
Signed-off-by: Alex Bennée
---
hw/audio/intel-hda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c
index f38117057b..95c28b315c 100644
--- a/hw/audio/intel-hda.c
+++ b/hw/audio/intel-hda.c
@@ -345,7 +345,7 @@ static void intel_hda_corb_run(IntelHDAState *d)
static void intel_hda_response(HDACodecDevice *dev, bool solicited,
uint32_t response)
{
- const MemTxAttrs attrs = { .memory = true };
+ const MemTxAttrs attrs = { .requester_type = MTRT_PCI, .memory =
true };
MEMTXATTRS_PCI?
Then removing the 'const' qualifier and setting .memory after.
Re: [PATCH v5 15/20] hw/i386: update vapic_write to use MemTxAttrs
On 11/11/22 19:25, Alex Bennée wrote:
This allows us to drop the current_cpu hack and properly model an
invalid access to the vapic.
Signed-off-by: Alex Bennée
---
hw/i386/kvmvapic.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index 43f8a8f679..a76ed07199 100644
--- a/hw/i386/kvmvapic.c
+++ b/hw/i386/kvmvapic.c
@@ -635,20 +635,21 @@ static int vapic_prepare(VAPICROMState *s)
return 0;
}
-static void vapic_write(void *opaque, hwaddr addr, uint64_t data,
-unsigned int size)
+static MemTxResult vapic_write(void *opaque, hwaddr addr, uint64_t data,
+ unsigned int size, MemTxAttrs attrs)
{
VAPICROMState *s = opaque;
+CPUState *cs;
X86CPU *cpu;
CPUX86State *env;
hwaddr rom_paddr;
-if (!current_cpu) {
-return;
+if (attrs.requester_type != MTRT_CPU) {
+return MEMTX_ACCESS_ERROR;
}
-
-cpu_synchronize_state(current_cpu);
-cpu = X86_CPU(current_cpu);
+cs = qemu_get_cpu(attrs.requester_id);
+cpu_synchronize_state(cs);
+cpu = X86_CPU(cs);
env = &cpu->env;
/*
@@ -708,6 +709,8 @@ static void vapic_write(void *opaque, hwaddr addr, uint64_t
data,
}
break;
}
+
+return MEMTX_OK;
}
static uint64_t vapic_read(void *opaque, hwaddr addr, unsigned size)
@@ -716,7 +719,7 @@ static uint64_t vapic_read(void *opaque, hwaddr addr,
unsigned size)
}
static const MemoryRegionOps vapic_ops = {
-.write = vapic_write,
+.write_with_attrs = vapic_write,
.read = vapic_read,
Shouldn't we do the same for the read() path?
.endianness = DEVICE_NATIVE_ENDIAN,
};
Re: [PATCH v5 19/20] hw/isa: derive CPUState from MemTxAttrs in apm_ioport_writeb
On 11/11/22 19:25, Alex Bennée wrote:
Some of the callbacks need a CPUState so extend the interface so we
can pass that down rather than relying on current_cpu hacks.
Signed-off-by: Alex Bennée
---
include/hw/isa/apm.h | 2 +-
hw/acpi/ich9.c | 1 -
hw/acpi/piix4.c | 2 +-
hw/isa/apm.c | 21 +
hw/isa/lpc_ich9.c| 5 ++---
5 files changed, 21 insertions(+), 10 deletions(-)
-static void apm_ioport_writeb(void *opaque, hwaddr addr, uint64_t val,
- unsigned size)
+static MemTxResult apm_ioport_writeb(void *opaque, hwaddr addr, uint64_t val,
+ unsigned size, MemTxAttrs attrs)
{
APMState *apm = opaque;
+CPUState *cs;
+
+if (attrs.requester_type != MTRT_CPU) {
+qemu_log_mask(LOG_UNIMP | LOG_GUEST_ERROR,
+ "%s: saw non-CPU transaction", __func__);
+return MEMTX_ACCESS_ERROR;
Are you sure it is illegal?
+}
+cs = qemu_get_cpu(attrs.requester_id);
+
addr &= 1;
trace_apm_io_write(addr, val);
@@ -41,11 +52,13 @@ static void apm_ioport_writeb(void *opaque, hwaddr addr,
uint64_t val,
apm->apmc = val;
if (apm->callback) {
-(apm->callback)(val, apm->arg);
+(apm->callback)(cs, val, apm->arg);
}
} else {
apm->apms = val;
}
+
+return MEMTX_OK;
}
[PATCH v2] capstone: use instead of
The upcoming capstone 5.0 drops support for the old way
of including its header, due to this change:
https://github.com/capstone-engine/capstone/commit/6656bcb63ab4e87dc6079bd6b6b12cc8dd9b2ad8
The official way is to use
This change has already been proposed before, see
https://patchwork.kernel.org/project/qemu-devel/patch/20180215173539.11033-1-f4...@amsat.org/
but it didn't find its way into qemu at that time.
On current systems, using works
now (despite the pkg-config-supplied -I/usr/include/capstone) -
since on all systems capstone headers are put into capstone/
subdirectory of a system include dir. So this change is
compatible with both the obsolete way of including it
and the only future way.
I dunno how relevant this is for 7.2, it's probably too
late already to test it on everything, but at the same
time, once capstone-5 will be released, there will be many
user questions about how to build qemu. This has already
been asked in #qemu - gentoo already have capstone-5.0-rc
and qemu fails to build with that one, but works fine
with this change.
Cc: Philippe Mathieu-Daudé
Signed-off-by: Michael Tokarev
---
Since v1: include the forgotten-to-be-committed meson.build change
include/disas/capstone.h | 2 +-
meson.build | 7 +--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/include/disas/capstone.h b/include/disas/capstone.h
index e29068dd97..d8fdc5d537 100644
--- a/include/disas/capstone.h
+++ b/include/disas/capstone.h
@@ -3,7 +3,7 @@
#ifdef CONFIG_CAPSTONE
-#include
+#include
#else
diff --git a/meson.build b/meson.build
index cf3e517e56..6f34c963f7 100644
--- a/meson.build
+++ b/meson.build
@@ -2680,12 +2680,7 @@ if not get_option('capstone').auto() or have_system or
have_user
capstone = dependency('capstone', version: '>=3.0.5',
kwargs: static_kwargs, method: 'pkg-config',
required: get_option('capstone'))
-
- # Some versions of capstone have broken pkg-config file
- # that reports a wrong -I path, causing the #include to
- # fail later. If the system has such a broken version
- # do not use it.
- if capstone.found() and not cc.compiles('#include ',
+ if capstone.found() and not cc.compiles('#include ',
dependencies: [capstone])
capstone = not_found
if get_option('capstone').enabled()
--
2.30.2
Re: [PATCH v2 3/3] hw/{misc, riscv}: pfsoc: add system controller as unimplemented
On Sun, Nov 13, 2022 at 08:30:42PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Conor,
>
> On 12/11/22 14:34, Conor Dooley wrote:
> > From: Conor Dooley
> >
> > The system controller on PolarFire SoC is access via a mailbox. The
> > control registers for this mailbox lie in the "IOSCB" region & the
> > interrupt is cleared via write to the "SYSREG" region. It also has a
> > QSPI controller, usually connected to a flash chip, that is used for
> > storing FPGA bitstreams and used for In-Application Programming (IAP).
> >
> > Linux has an implementation of the system controller, through which the
> > hwrng is accessed, leading to load/store access faults.
> >
> > Add the QSPI as unimplemented and a very basic (effectively
> > unimplemented) version of the system controller's mailbox. Rather than
> > purely marking the regions as unimplemented, service the mailbox
> > requests by reporting failures and raising the interrupt so a guest can
> > better handle the lack of support.
> >
> > Signed-off-by: Conor Dooley
> > ---
> > hw/misc/mchp_pfsoc_ioscb.c | 59 -
> > hw/misc/mchp_pfsoc_sysreg.c | 19 --
> > hw/riscv/microchip_pfsoc.c | 6 +++
> > include/hw/misc/mchp_pfsoc_ioscb.h | 3 ++
> > include/hw/misc/mchp_pfsoc_sysreg.h | 1 +
> > include/hw/riscv/microchip_pfsoc.h | 1 +
> > 6 files changed, 83 insertions(+), 6 deletions(-)
>
> > @@ -52,10 +54,18 @@ static uint64_t mchp_pfsoc_sysreg_read(void *opaque,
> > hwaddr offset,
> > static void mchp_pfsoc_sysreg_write(void *opaque, hwaddr offset,
> > uint64_t value, unsigned size)
> > {
> > -qemu_log_mask(LOG_UNIMP, "%s: unimplemented device write "
> > - "(size %d, value 0x%" PRIx64
> > - ", offset 0x%" HWADDR_PRIx ")\n",
> > - __func__, size, value, offset);
> > +MchpPfSoCSysregState *s = opaque;
> > +qemu_irq_lower(s->irq);
>
> Is this always lowered IRQ line wanted? ...
>
> > +switch (offset) {
> > +case MESSAGE_INT:
> > +qemu_irq_lower(s->irq);
>
> ... since we do it here.
Probably just me pressing the y key instead of the d one.
I'll sort that out for v3, thanks!
> > +break;
> > +default:
> > +qemu_log_mask(LOG_UNIMP, "%s: unimplemented device write "
> > + "(size %d, value 0x%" PRIx64
> > + ", offset 0x%" HWADDR_PRIx ")\n",
> > + __func__, size, value, offset);
> > +}
> > }
>
>
Re: [PATCH v2 2/8] target/riscv: add support for Zca and Zcf extensions
On 11/13/22 12:32, Weiwei Li wrote:
+} else if ((get_xl_max(ctx) == MXL_RV32) &&
+!ctx->cfg_ptr->ext_zcf &&
+(((opcode & 0xe003) == 0x6000) ||
+ ((opcode & 0xe003) == 0x6002) ||
+ ((opcode & 0xe003) == 0xe000) ||
+ ((opcode & 0xe003) == 0xe002))) {
gen_exception_illegal(ctx);
Why aren't you using the same c_flw solution that you do for Zcd?
r~
Re: [PATCH] hw/intc: sifive_plic: Renumber the S irqs for numa support
On Fri, Nov 11, 2022 at 10:20 PM Frédéric Pétrot
wrote:
>
> Commit 40244040 changed the way the S irqs are numbered. This breaks when
> using numa configuration, e.g.:
> ./qemu-system-riscv64 -nographic -machine virt,dumpdtb=numa-tree.dtb \
> -m 2G -smp cpus=16 \
> -object memory-backend-ram,id=mem0,size=512M \
> -object memory-backend-ram,id=mem1,size=512M \
> -object memory-backend-ram,id=mem2,size=512M \
> -object memory-backend-ram,id=mem3,size=512M \
> -numa node,cpus=0-3,memdev=mem0,nodeid=0 \
> -numa node,cpus=4-7,memdev=mem1,nodeid=1 \
> -numa node,cpus=8-11,memdev=mem2,nodeid=2 \
> -numa node,cpus=12-15,memdev=mem3,nodeid=3
> leads to:
> Unexpected error in object_property_find_err() at ../qom/object.c:1304:
> qemu-system-riscv64: Property 'riscv.sifive.plic.unnamed-gpio-out[8]' not
> found
>
> This patch makes the nubering of the S irqs identical to what it was before.
>
> Signed-off-by: Frédéric Pétrot
Reviewed-by: Alistair Francis
Alistair
> ---
> hw/intc/sifive_plic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/intc/sifive_plic.c b/hw/intc/sifive_plic.c
> index c2dfacf028..89d2122742 100644
> --- a/hw/intc/sifive_plic.c
> +++ b/hw/intc/sifive_plic.c
> @@ -480,7 +480,7 @@ DeviceState *sifive_plic_create(hwaddr addr, char
> *hart_config,
>qdev_get_gpio_in(DEVICE(cpu), IRQ_M_EXT));
> }
> if (plic->addr_config[i].mode == PLICMode_S) {
> -qdev_connect_gpio_out(dev, cpu_num,
> +qdev_connect_gpio_out(dev, cpu_num - plic->hartid_base,
>qdev_get_gpio_in(DEVICE(cpu), IRQ_S_EXT));
> }
> }
> --
> 2.37.2
>
>
[PATCH v2] hw/riscv: virt: Remove the redundant ipi-id property
The imsic DT binding[1] has changed and no longer require an ipi-id.
The latest IMSIC driver dynamically allocates ipi id if slow-ipi
is not defined.
Get rid of the unused dt property which may lead to confusion.
[1]
https://lore.kernel.org/lkml/2022044207.1478350-5-apa...@ventanamicro.com/
Signed-off-by: Atish Patra
---
hw/riscv/virt.c | 2 --
include/hw/riscv/virt.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index a5bc7353b412..0bc0964e42a8 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -546,8 +546,6 @@ static void create_fdt_imsic(RISCVVirtState *s, const
MemMapEntry *memmap,
riscv_socket_count(mc) * sizeof(uint32_t) * 4);
qemu_fdt_setprop_cell(mc->fdt, imsic_name, "riscv,num-ids",
VIRT_IRQCHIP_NUM_MSIS);
-qemu_fdt_setprop_cells(mc->fdt, imsic_name, "riscv,ipi-id",
-VIRT_IRQCHIP_IPI_MSI);
if (riscv_socket_count(mc) > 1) {
qemu_fdt_setprop_cell(mc->fdt, imsic_name, "riscv,hart-index-bits",
imsic_num_bits(imsic_max_hart_per_socket));
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index be4ab8fe7f71..62513e075c47 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -93,7 +93,6 @@ enum {
#define VIRT_PLATFORM_BUS_NUM_IRQS 32
-#define VIRT_IRQCHIP_IPI_MSI 1
#define VIRT_IRQCHIP_NUM_MSIS 255
#define VIRT_IRQCHIP_NUM_SOURCES VIRTIO_NDEV
#define VIRT_IRQCHIP_NUM_PRIO_BITS 3
--
2.25.1
RE: [PATCH v1] block/rbd: Add support for layered encryption
> -Original Message- > From: Ilya Dryomov > Sent: 11 November 2022 15:01 > To: Or Ozeri > Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org; Danny Harnik > > Subject: [EXTERNAL] Re: [PATCH v1] block/rbd: Add support for layered > encryption > > I don't understand the need for this char* array. Is there a problem with > putting the blob directly into luks_all_opts->passphrase just like the size is > put into luks_all_opts->passphrase_size? > luks_all_opts->passphrase has a const modifier.
[PATCH v2] block/rbd: Add support for layered encryption
Starting from ceph Reef, RBD has built-in support for layered encryption,
where each ancestor image (in a cloned image setting) can be possibly
encrypted using a unique passphrase.
A new function, rbd_encryption_load2, was added to librbd API.
This new function supports an array of passphrases (via "spec" structs).
This commit extends the qemu rbd driver API to use this new librbd API,
in order to support this new layered encryption feature.
Signed-off-by: Or Ozeri
---
v2: nit fixes suggested by @idryomov
---
block/rbd.c | 122 ++-
qapi/block-core.json | 33 ++--
2 files changed, 151 insertions(+), 4 deletions(-)
diff --git a/block/rbd.c b/block/rbd.c
index f826410f40..bde0326bfd 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -71,6 +71,16 @@ static const char rbd_luks2_header_verification[
'L', 'U', 'K', 'S', 0xBA, 0xBE, 0, 2
};
+static const char rbd_layered_luks_header_verification[
+RBD_ENCRYPTION_LUKS_HEADER_VERIFICATION_LEN] = {
+'R', 'B', 'D', 'L', 0xBA, 0xBE, 0, 1
+};
+
+static const char rbd_layered_luks2_header_verification[
+RBD_ENCRYPTION_LUKS_HEADER_VERIFICATION_LEN] = {
+'R', 'B', 'D', 'L', 0xBA, 0xBE, 0, 2
+};
+
typedef enum {
RBD_AIO_READ,
RBD_AIO_WRITE,
@@ -470,6 +480,9 @@ static int qemu_rbd_encryption_load(rbd_image_t image,
size_t passphrase_len;
rbd_encryption_luks1_format_options_t luks_opts;
rbd_encryption_luks2_format_options_t luks2_opts;
+#ifdef LIBRBD_SUPPORTS_ENCRYPTION_LOAD2
+rbd_encryption_luks_format_options_t luks_any_opts;
+#endif
rbd_encryption_format_t format;
rbd_encryption_options_t opts;
size_t opts_size;
@@ -505,6 +518,23 @@ static int qemu_rbd_encryption_load(rbd_image_t image,
luks2_opts.passphrase_size = passphrase_len;
break;
}
+#ifdef LIBRBD_SUPPORTS_ENCRYPTION_LOAD2
+case RBD_IMAGE_ENCRYPTION_FORMAT_LUKS_ANY: {
+memset(&luks_any_opts, 0, sizeof(luks_any_opts));
+format = RBD_ENCRYPTION_FORMAT_LUKS;
+opts = &luks_any_opts;
+opts_size = sizeof(luks_any_opts);
+r = qemu_rbd_convert_luks_options(
+
qapi_RbdEncryptionOptionsLUKSAny_base(&encrypt->u.luks_any),
+&passphrase, &passphrase_len, errp);
+if (r < 0) {
+return r;
+}
+luks_any_opts.passphrase = passphrase;
+luks_any_opts.passphrase_size = passphrase_len;
+break;
+}
+#endif
default: {
r = -ENOTSUP;
error_setg_errno(
@@ -522,6 +552,76 @@ static int qemu_rbd_encryption_load(rbd_image_t image,
return 0;
}
+
+#ifdef LIBRBD_SUPPORTS_ENCRYPTION_LOAD2
+static int qemu_rbd_encryption_load2(rbd_image_t image,
+ RbdEncryptionOptions *encrypt,
+ Error **errp)
+{
+int r = 0;
+int encrypt_count = 1;
+int i;
+RbdEncryptionOptions *curr_encrypt;
+rbd_encryption_spec_t *specs;
+rbd_encryption_luks_format_options_t* luks_any_opts;
+char **passphrases;
+
+/* count encryption options */
+for (curr_encrypt = encrypt; curr_encrypt->has_parent;
+ curr_encrypt = curr_encrypt->parent) {
+++encrypt_count;
+}
+
+specs = g_new0(rbd_encryption_spec_t, encrypt_count);
+passphrases = g_new0(char*, encrypt_count);
+
+curr_encrypt = encrypt;
+for (i = 0; i < encrypt_count; ++i) {
+if (curr_encrypt->format != RBD_IMAGE_ENCRYPTION_FORMAT_LUKS_ANY) {
+r = -ENOTSUP;
+error_setg_errno(
+errp, -r, "unknown image encryption format: %u",
+curr_encrypt->format);
+goto exit;
+}
+
+specs[i].format = RBD_ENCRYPTION_FORMAT_LUKS;
+specs[i].opts_size = sizeof(rbd_encryption_luks_format_options_t);
+
+luks_any_opts = g_new0(rbd_encryption_luks_format_options_t, 1);
+specs[i].opts = luks_any_opts;
+
+r = qemu_rbd_convert_luks_options(
+qapi_RbdEncryptionOptionsLUKSAny_base(
+&curr_encrypt->u.luks_any),
+&passphrases[i], &luks_any_opts->passphrase_size,
+errp);
+if (r < 0) {
+goto exit;
+}
+
+luks_any_opts->passphrase = passphrases[i];
+
+curr_encrypt = curr_encrypt->parent;
+}
+
+r = rbd_encryption_load2(image, specs, encrypt_count);
+if (r < 0) {
+error_setg_errno(errp, -r, "layered encryption load fail");
+goto exit;
+}
+
+exit:
+for (i = 0; i < encrypt_count; ++i) {
+luks_any_opts = (rbd_encryption_luks_format_options_t*)(specs[i].opts);
+g_free(luks_any_opts);
+g_free(passphrases[i]);
+}
+g_free(passphrases);
+g_free(specs);
+return r;
+}
+#endif
#endif
/* FIXME Deprecate and remove keypairs
Re: [PATCH-for-7.2 v2] libvduse: Avoid warning about dangerous use of strncpy()
On Fri, 11 Nov 2022 at 07:46, Philippe Mathieu-Daudé wrote:
>
> From: Philippe Mathieu-Daudé
>
> GCC 8 added a -Wstringop-truncation warning:
>
> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
> bug 81117 is specifically intended to highlight likely unintended
> uses of the strncpy function that truncate the terminating NUL
> character from the source string.
>
> Here the next line indeed unconditionally zeroes the last byte, but
> 1/ the buffer has been calloc'd, so we don't need to add an extra
> byte, and 2/ we called vduse_name_is_invalid() which checked the
> string length, so we can simply call strcpy().
>
> This fixes when using gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0:
>
> [42/666] Compiling C object subprojects/libvduse/libvduse.a.p/libvduse.c.o
> FAILED: subprojects/libvduse/libvduse.a.p/libvduse.c.o
> cc -m64 -mcx16 -Isubprojects/libvduse/libvduse.a.p -Isubprojects/libvduse
> -I../../subprojects/libvduse [...] -o
> subprojects/libvduse/libvduse.a.p/libvduse.c.o -c
> ../../subprojects/libvduse/libvduse.c
> In file included from /usr/include/string.h:495,
>from ../../subprojects/libvduse/libvduse.c:24:
> In function ‘strncpy’,
> inlined from ‘vduse_dev_create’ at
> ../../subprojects/libvduse/libvduse.c:1312:5:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> ‘__builtin_strncpy’ specified bound 256 equals destination size
> [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> |
> ^~
> cc1: all warnings being treated as errors
> ninja: build stopped: cannot make progress due to previous errors.
>
> Fixes: d9cf16c0be ("libvduse: Replace strcpy() with strncpy()")
> Suggested-by: Markus Armbruster
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Supersedes: <20220919192306.52729-1-f4...@amsat.org>
> Cc: Xie Yongji
> Cc: Kevin Wolf
> ---
> subprojects/libvduse/libvduse.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied to qemu.git/master.
Thanks,
Stefan
Re: [RFC PATCH 0/1] hw/arm: use -cpu max by default on sbsa-ref
W dniu 9.11.2022 o 14:35, Leif Lindholm pisze:
We have mainly (well, as will become clear, in fact "exclusively") been using
sbsa-ref with the "max" CPU. But sbsa-ref was created with a default CPU of
Cortex-A57, which we have not updated along the way.
However, the "max" cpu has seen a bug where Linux boot fails around UEFI
ExitBootServices. Marcin Juszkiewicz has found the cause for that, but that
requires a patch to TF-A. (Has that been submitted upstream?)
TF-A gerrit instance refuses to handle any of my SSH keys. RSA, ED25519
ones.
The only change I did to TF-A was removal of coherent memory stuff as it
was for a57/72 and blocked me from building it for a76/n1.
Attached it.From 246b709867b4fd9a62ea1ae6bce2f454971b548f Mon Sep 17 00:00:00 2001
From: Marcin Juszkiewicz
Date: Tue, 6 Sep 2022 13:48:40 +0200
Subject: [PATCH] qemu_sbsa: drop whole coherent memory stuff
We would like to use Cortex-A76/N1 cpu emulation in sbsa-ref and that
whole coherent memory stuff is not going there.
---
plat/qemu/common/qemu_bl1_setup.c | 4 +---
plat/qemu/common/qemu_bl2_setup.c | 4 +---
plat/qemu/common/qemu_bl31_setup.c | 4 +---
plat/qemu/common/qemu_common.c | 12 +---
plat/qemu/common/qemu_private.h| 8 ++--
plat/qemu/qemu_sbsa/platform.mk| 3 +++
6 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/plat/qemu/common/qemu_bl1_setup.c b/plat/qemu/common/qemu_bl1_setup.c
index 67f33273f..5243293ae 100644
--- a/plat/qemu/common/qemu_bl1_setup.c
+++ b/plat/qemu/common/qemu_bl1_setup.c
@@ -51,9 +51,7 @@ void bl1_plat_arch_setup(void)
{
QEMU_CONFIGURE_BL1_MMU(bl1_tzram_layout.total_base,
bl1_tzram_layout.total_size,
-BL_CODE_BASE, BL1_CODE_END,
-BL1_RO_DATA_BASE, BL1_RO_DATA_END,
-BL_COHERENT_RAM_BASE, BL_COHERENT_RAM_END);
+BL_CODE_BASE, BL1_CODE_END);
}
void bl1_platform_setup(void)
diff --git a/plat/qemu/common/qemu_bl2_setup.c b/plat/qemu/common/qemu_bl2_setup.c
index 2c0da15b9..6e13ece72 100644
--- a/plat/qemu/common/qemu_bl2_setup.c
+++ b/plat/qemu/common/qemu_bl2_setup.c
@@ -92,9 +92,7 @@ void bl2_plat_arch_setup(void)
{
QEMU_CONFIGURE_BL2_MMU(bl2_tzram_layout.total_base,
bl2_tzram_layout.total_size,
- BL_CODE_BASE, BL_CODE_END,
- BL_RO_DATA_BASE, BL_RO_DATA_END,
- BL_COHERENT_RAM_BASE, BL_COHERENT_RAM_END);
+ BL_CODE_BASE, BL_CODE_END);
}
/***
diff --git a/plat/qemu/common/qemu_bl31_setup.c b/plat/qemu/common/qemu_bl31_setup.c
index 4f60eb163..61b6cbc10 100644
--- a/plat/qemu/common/qemu_bl31_setup.c
+++ b/plat/qemu/common/qemu_bl31_setup.c
@@ -65,9 +65,7 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1,
void bl31_plat_arch_setup(void)
{
qemu_configure_mmu_el3(BL31_BASE, (BL31_END - BL31_BASE),
- BL_CODE_BASE, BL_CODE_END,
- BL_RO_DATA_BASE, BL_RO_DATA_END,
- BL_COHERENT_RAM_BASE, BL_COHERENT_RAM_END);
+ BL_CODE_BASE, BL_CODE_END);
}
static void qemu_gpio_init(void)
diff --git a/plat/qemu/common/qemu_common.c b/plat/qemu/common/qemu_common.c
index 0c184f49b..3d5b197ae 100644
--- a/plat/qemu/common/qemu_common.c
+++ b/plat/qemu/common/qemu_common.c
@@ -129,11 +129,7 @@ static const mmap_region_t plat_qemu_mmap[] = {
void qemu_configure_mmu_##_el(unsigned long total_base, \
unsigned long total_size, \
unsigned long code_start, \
- unsigned long code_limit, \
- unsigned long ro_start, \
- unsigned long ro_limit, \
- unsigned long coh_start, \
- unsigned long coh_limit) \
+ unsigned long code_limit) \
{\
mmap_add_region(total_base, total_base, \
total_size,\
@@ -141,12 +137,6 @@ static const mmap_region_t plat_qemu_mmap[] = {
mmap_add_region(code_start, code_start, \
code_limit - code_start, \
MT_CODE | MT_SECURE); \
- mmap_add_region(ro_start, ro_start, \
-ro_limit - ro_start, \
-MT_RO_DATA | MT_SECURE); \
- mmap_add_region(coh_start, coh_start, \
-coh_limit - coh_start, \
-MT_DEVICE | MT_RW | MT_SECURE); \
mmap_add(plat_qemu_mmap);\
init_xlat_tables(); \
\
diff --git a/plat/qemu/common/qemu_private.h b/plat/qemu/common/qemu_private.h
index c313cb63f..ec59e2f31 100644
--- a/plat/qemu/common/qemu_private.h
+++ b/plat/qemu/common/qemu_private.h
@@ -16,14 +16,10 @@ void qemu_configure_mmu_svc_mon(unsigned long total_base,
unsigned long coh_start, unsigned long coh_limit);
void qemu_configure_mmu_el1(unsigned long total_base, unsigned long total_size,
- unsigned long code_start, unsigned long code_limit,
- unsigned long ro_start, unsigned long ro_limit,
- unsigned long coh_start, unsigned long coh_limit);
+ unsigned long code_start, unsigned long code_limit);
void qemu_configure_mmu_el3(unsigned long total_base, unsigned long total_size,
- unsigned long code_start, unsigned long c
virtio4-inputinterrupt triggers 0, causing packet loss
Hi qemu team： Recently, during the development based on virtio net/vhost net, it was found that when virtio enabled multiple queues, there was always another queue whose interrupts were not triggered, and no useful logs were found. The interrupt statistics in Guest are as follows: CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16 CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31 1: 0 1847 0 10 0 0 284 0 0 0 0 0 0 0 0 0 0 0 0453 0 0 0 0 0 0 0 2464 0 0 0 0 IO-APIC 1-edge i8042 4: 0 0 0 0 0202 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 56 0 0 IO-APIC 4-edge ttyS0 6: 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 6-edge floppy 8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 8-edge rtc0 9: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 9-fasteoi acpi 10:456 29 0 32272 0 0 0 0 121471 66176 1701 0 0 1118 0 0 0 0 0 0 121799 7261 0 0 0 1 0 31662 25064 0 0 0 IO-APIC 10-fasteoi ehci_hcd:usb1, virtio3 12: 0 0 16 1801 0 0 0 0 0 0 0 0 0 0 7217 0 0 0 0 0 0 10404 0 0 0 0 1170 0 0 0 0 0 IO-APIC 12-edge i8042 14: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 14-edge ata_piix 15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 15-edge ata_piix 24: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 65536-edge virtio1-config 25: 0 31340 0 0 0 0 0303 178500 72390 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 65537-edge virtio1-virtqueues 26: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 81920-edge virtio2-config 27: 0 0 0 0 0 0 0 0 0 0
