Re: [PATCH 03/16] target/riscv/cpu.c: restrict 'mvendorid' value

[Alistair Francis]

On Tue, Jun 13, 2023 at 4:52 AM Daniel Henrique Barboza
 wrote:
>
>
>
> On 6/12/23 00:56, Alistair Francis wrote:
> > On Wed, May 31, 2023 at 5:49 AM Daniel Henrique Barboza
> >  wrote:
> >>
> >> We're going to change the handling of mvendorid/marchid/mimpid by the
> >> KVM driver. Since these are always present in all CPUs let's put the
> >> same validation for everyone.
> >>
> >> It doesn't make sense to allow 'mvendorid' to be different than it
> >> is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have
> >> any 'mvendorid' they want.
> >>
> >> Change 'mvendorid' to be a class property created via
> >> 'object_class_property_add', instead of using the DEFINE_PROP_UINT32()
> >> macro. This allow us to define a custom setter for it that will verify,
> >> for named CPUs, if mvendorid is different than it is already set by the
> >> CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is
> >> set to an invalid value:
> >>
> >> $ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2
> >> qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2:
> >>  Unable to change veyron-v1-riscv-cpu mvendorid (0x61f)
> >
> > Is this something we want to enforce? What if someone wanted to test
> > using the veyron-v1 CPU but they wanted to change some properties. I
> > don't see an advantage in not letting them do that
>
> The idea is to keep things simpler for us. As it is today we forbid users to
> enable/disable extensions for vendor CPUs. Doing the same thing for
> mvendorid/marchid/mimpid seems consistent with what we're already doing.
>
> Also, guest software might rely on vendor IDs from the CPU to take certain
> actions, and if the user is free to change the CPU ID from vendor CPUs the
> software will misbehave and the user can claim "I created a veyron-v1 CPU and
> the guest it's like like it's not". Allowing mvendorid and friends to be 
> changed
> doesn't do much for users (we forbid enabling/disabling extensions, so what's
> to gain from changing machine IDs?) and it can be a potential source of bugs.

Fair points. Ok, fine with me then :)

Alistair

>
>
>
> Thanks,
>
>
> Daniel
>
>
> >
> > Alistair
> >
> >>
> >> Signed-off-by: Daniel Henrique Barboza 
> >> ---
> >>   target/riscv/cpu.c | 31 ++-
> >>   1 file changed, 30 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> >> index 72f5433776..bcd69bb032 100644
> >> --- a/target/riscv/cpu.c
> >> +++ b/target/riscv/cpu.c
> >> @@ -1723,7 +1723,6 @@ static void riscv_cpu_add_user_properties(Object 
> >> *obj)
> >>   static Property riscv_cpu_properties[] = {
> >>   DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
> >>
> >> -DEFINE_PROP_UINT32("mvendorid", RISCVCPU, cfg.mvendorid, 0),
> >>   DEFINE_PROP_UINT64("marchid", RISCVCPU, cfg.marchid, 
> >> RISCV_CPU_MARCHID),
> >>   DEFINE_PROP_UINT64("mimpid", RISCVCPU, cfg.mimpid, RISCV_CPU_MIMPID),
> >>
> >> @@ -1810,6 +1809,32 @@ static const struct TCGCPUOps riscv_tcg_ops = {
> >>   #endif /* !CONFIG_USER_ONLY */
> >>   };
> >>
> >> +static bool riscv_cpu_is_dynamic(Object *cpu_obj)
> >> +{
> >> +return object_dynamic_cast(cpu_obj, TYPE_RISCV_DYNAMIC_CPU) != NULL;
> >> +}
> >> +
> >> +static void cpu_set_mvendorid(Object *obj, Visitor *v, const char *name,
> >> +  void *opaque, Error **errp)
> >> +{
> >> +bool dynamic_cpu = riscv_cpu_is_dynamic(obj);
> >> +RISCVCPU *cpu = RISCV_CPU(obj);
> >> +uint32_t prev_val = cpu->cfg.mvendorid;
> >> +uint32_t value;
> >> +
> >> +if (!visit_type_uint32(v, name, &value, errp)) {
> >> +return;
> >> +}
> >> +
> >> +if (!dynamic_cpu && prev_val != value) {
> >> +error_setg(errp, "Unable to change %s mvendorid (0x%x)",
> >> +   object_get_typename(obj), prev_val);
> >> +return;
> >> +}
> >> +
> >> +cpu->cfg.mvendorid = value;
> >> +}
> >> +
> >>   static void riscv_cpu_class_init(ObjectClass *c, void *data)
> >>   {
> >>   RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
> >> @@ -1841,6 +1866,10 @@ static void riscv_cpu_class_init(ObjectClass *c, 
> >> void *data)
> >>   cc->gdb_get_dynamic_xml = riscv_gdb_get_dynamic_xml;
> >>   cc->tcg_ops = &riscv_tcg_ops;
> >>
> >> +object_class_property_add(c, "mvendorid", "uint32", NULL,
> >> +  cpu_set_mvendorid,
> >> +  NULL, NULL);
> >> +
> >>   device_class_set_props(dc, riscv_cpu_properties);
> >>   }
> >>
> >> --
> >> 2.40.1
> >>
> >>

Re: [PATCH v6 1/9] migration: introduced 'MigrateAddress' in QAPI for migration wire protocol.

[Het Gala]

On 06/06/23 3:45 pm, Het Gala wrote:

This patch introduces well defined MigrateAddress struct and its related
child objects.

The existing argument of 'migrate' and 'migrate-incoming' QAPI - 'uri'
is of string type. The current migration flow follows double encoding
scheme for  fetching migration parameters such as 'uri' and this is
not an ideal design.

Motive for intoducing struct level design is to prevent double encoding
of QAPI arguments, as Qemu should be able to directly use the QAPI
arguments without any level of encoding.

Suggested-by: Aravind Retnakaran 
Signed-off-by: Het Gala 
Reviewed-by: Juan Quintela 
Reviewed-by: Daniel P. Berrangé 
---
  qapi/migration.json | 45 +
  1 file changed, 45 insertions(+)

diff --git a/qapi/migration.json b/qapi/migration.json
index 179af0c4d8..e61d25eba2 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1407,6 +1407,51 @@
  ##
  { 'command': 'migrate-continue', 'data': {'state': 'MigrationStatus'} }
  
+##

+# @MigrationAddressType:
+#
+# The migration stream transport mechanisms.
+#
+# @socket: Migrate via socket.
+#
+# @exec: Direct the migration stream to another process.
+#
+# @rdma: Migrate via RDMA.
+#
+# Since 8.1
+##
+{ 'enum': 'MigrationAddressType',
+  'data': ['socket', 'exec', 'rdma'] }
+
+##
+# @MigrationExecCommand:
+#
+# @args: list of commands for migraton stream execution to a file.
+#
+# Notes:
+#
+# 1. @args[0] needs to be the path to the new program.
+#
+# Since 8.1
+##
+{ 'struct': 'MigrationExecCommand',
+  'data': {'args': [ 'str' ] } }
+
+##
+# @MigrationAddress:
+#
+# Migration endpoint configuration.
+#
+# Since 8.1
+##
+{ 'union': 'MigrationAddress',
+  'base': { 'transport' : 'MigrationAddressType'},
+  'discriminator': 'transport',
+  'data': {
+'socket': 'SocketAddress',
+'exec': 'MigrationExecCommand',
+'rdma': 'InetSocketAddress' } }
+
  ##
  # @migrate:
  #


Hi maintainers, this is just a reminder mail for v6 patchset for 
modification the QAPI design for migration qapis - 'migrate' and 
'incoming-migrate'. From the last discussion, I have modified 
definitions specifically around QAPIs in patch 1 and 6, and have tried 
to make it short and consice and meaningful. Please have a look at it 
and suggest if any changes required. Tagging maintainers who have 
actively participated in the discussion in last few iterations : Markus, 
Daniel, Eric, Juan - but regardless other maintainers are also very well 
welcomed to share their opinions.


Regards,
Het Gala

Re: [PATCH v15 00/10] TCG code quality tracking

[Wu, Fei]

On 6/7/2023 8:24 PM, Fei Wu wrote:
> v15
> ---
> This is a large change:
> * remove all time related stuffs, including cmd 'info profile'
> * remove the per-TB flag, use global flag instead
> * remove tb_stats pause/filter, but add status
> * remove qemu_log changes, and use monitor_printf
> * use array instead of list for sorting
> * remove async_safe_run_on_cpu for cmd info tb-list & tb
> * use monitor_disas instead of regenerate TB, but **doesn't work yet**
> * other cleanups
> 
Hi Richard,

Could you please take a look at this series? I hope most of the comments
on v14 have been addressed.

Next revision I will change:
* add async_safe_run_on_cpu back in case of any concurrency issue
* add tbs->gpa_pc for monitor_disas, which requires
get_page_addr_code_hostp() return both ram_addr_t and gpa
* finalize the commit logs and documents

Thanks,
Fei.

> 
> Alex Bennée (1):
>   tb-stats: reset the tracked TBs on a tb_flush
> 
> Fei Wu (5):
>   accel/tcg: remove CONFIG_PROFILER
>   accel/tcg: add jit stats to TBStatistics
>   debug: add -d tb_stats to control TBStatistics
>   tb-stats: dump hot TBs at the end of the execution
>   docs: add tb-stats how to
> 
> Vanderson M. do Rosario (4):
>   accel/tcg: introduce TBStatistics structure
>   accel: collecting TB execution count
>   monitor: adding tb_stats hmp command
>   tb-stats: Adding info [tb-list|tb] commands to HMP (WIP)
> 
>  MAINTAINERS   |   1 +
>  accel/tcg/cpu-exec.c  |   6 +
>  accel/tcg/meson.build |   1 +
>  accel/tcg/monitor.c   | 184 +++--
>  accel/tcg/tb-context.h|   1 +
>  accel/tcg/tb-hash.h   |   7 +
>  accel/tcg/tb-maint.c  |  20 ++
>  accel/tcg/tb-stats.c  | 365 ++
>  accel/tcg/tcg-accel-ops.c |  10 -
>  accel/tcg/tcg-runtime.c   |   1 +
>  accel/tcg/translate-all.c | 110 ++
>  accel/tcg/translator.c|  30 +++
>  disas/disas.c |   2 +
>  docs/devel/tcg-tbstats.rst|  97 +
>  hmp-commands-info.hx  |  31 +--
>  hmp-commands.hx   |  16 ++
>  include/exec/exec-all.h   |   3 +
>  include/exec/gen-icount.h |   1 +
>  include/exec/tb-stats-dump.h  |  21 ++
>  include/exec/tb-stats-flags.h |  29 +++
>  include/exec/tb-stats.h   | 130 
>  include/monitor/hmp.h |   3 +
>  include/qemu/log.h|   1 +
>  include/qemu/timer.h  |   9 -
>  include/tcg/tcg.h |  26 +--
>  linux-user/exit.c |   2 +
>  meson.build   |   2 -
>  meson_options.txt |   2 -
>  qapi/machine.json |  18 --
>  scripts/meson-buildoptions.sh |   3 -
>  softmmu/runstate.c|  11 +-
>  stubs/meson.build |   1 +
>  stubs/tb-stats.c  |  36 
>  tcg/tcg.c | 237 +++---
>  tests/qtest/qmp-cmd-test.c|   3 -
>  util/log.c|  26 +++
>  36 files changed, 1093 insertions(+), 353 deletions(-)
>  create mode 100644 accel/tcg/tb-stats.c
>  create mode 100644 docs/devel/tcg-tbstats.rst
>  create mode 100644 include/exec/tb-stats-dump.h
>  create mode 100644 include/exec/tb-stats-flags.h
>  create mode 100644 include/exec/tb-stats.h
>  create mode 100644 stubs/tb-stats.c
> 

RE: [PATCH v3 5/5] intel_iommu: Optimize out some unnecessary UNMAP calls

[Duan, Zhenzhong]

>-Original Message-
>From: Peter Xu 
>Sent: Saturday, June 10, 2023 5:26 AM
>Subject: Re: [PATCH v3 5/5] intel_iommu: Optimize out some unnecessary
>UNMAP calls
>
>On Fri, Jun 09, 2023 at 05:49:06AM +, Duan, Zhenzhong wrote:
>> Seems vtd_page_walk_one() already works in above way, checking mapping
>> changes and calling kernel for changed entries?
>
>Agreed in most cases, but the path this patch modified is not?  E.g. it happens
>in rare cases where we simply want to unmap everything (e.g. on a system
>reset, or invalid context entry)?
Clear.

>
>That's also why I'm curious whether perf of this path matters at all (and
>assuming now we all agree that's the only goal now..), because afaiu it didn't
>really trigger in common paths.
I'll collect performance data and reply back.

Thanks
Zhenzhong

RE: [PATCH v3 4/5] intel_iommu: Fix address space unmap

[Duan, Zhenzhong]

>-Original Message-
>From: Peter Xu 
>Sent: Friday, June 9, 2023 9:37 PM
>To: Duan, Zhenzhong 
>Cc: qemu-devel@nongnu.org; m...@redhat.com; jasow...@redhat.com;
>pbonz...@redhat.com; richard.hender...@linaro.org; edua...@habkost.net;
>marcel.apfelb...@gmail.com; alex.william...@redhat.com;
>c...@redhat.com; da...@redhat.com; phi...@linaro.org;
>kwankh...@nvidia.com; c...@nvidia.com; Liu, Yi L ; Peng,
>Chao P 
>Subject: Re: [PATCH v3 4/5] intel_iommu: Fix address space unmap
>
>On Fri, Jun 09, 2023 at 03:31:46AM +, Duan, Zhenzhong wrote:
>>
>>
>> >-Original Message-
>> >From: Peter Xu 
>> >Sent: Thursday, June 8, 2023 9:48 PM
>> >To: Duan, Zhenzhong 
>> >Cc: qemu-devel@nongnu.org; m...@redhat.com; jasow...@redhat.com;
>> >pbonz...@redhat.com; richard.hender...@linaro.org;
>> >edua...@habkost.net; marcel.apfelb...@gmail.com;
>> >alex.william...@redhat.com; c...@redhat.com; da...@redhat.com;
>> >phi...@linaro.org; kwankh...@nvidia.com; c...@nvidia.com; Liu, Yi L
>> >; Peng, Chao P 
>> >Subject: Re: [PATCH v3 4/5] intel_iommu: Fix address space unmap
>> >
>> >On Thu, Jun 08, 2023 at 05:52:30PM +0800, Zhenzhong Duan wrote:
>> >> During address space unmap, corresponding IOVA tree entries are
>> >> also removed. But DMAMap is set beyond notifier's scope by 1, so in
>> >> theory there is possibility to remove a continuous entry above the
>> >> notifier's scope but falling in adjacent notifier's scope.
>> >
>> >This function is only called in "loop over all notifiers" case (or
>> >replay() that just got removed, but even so there'll be only 1
>> >notifier normally iiuc at least for vt-d), hopefully it means no bug
>> >exist (no Fixes needed, no backport needed either), but still worth fixing 
>> >it
>up.
>>
>> Not two notifiers as vtd-ir splits for vt-d?
>
>The two notifiers will all be attached to the same IOMMU mr, so
>IOMMU_NOTIFIER_FOREACH() will loop over them all always?
Yes.
>
>And this actually shouldn't matter, IMHO, as the IR split has the 0xfeeX
>hole only, so when notifying with end=0xfee0 (comparing to
>end=0xfedf) it shouldn't make a difference iiuc because there should have
>no iova entry at 0xfee0 anyway in the tree.
Clear.

Thanks
Zhenzhong

Re: [PATCH] elf2dmp: Don't abandon when Prcb is set to 0

[Akihiko Odaki]

On 2023/06/12 12:42, Viktor Prutyanov wrote:

Prcb may be set to 0 for some CPUs if the dump was taken before they
start. The dump may still contain valuable information for started CPUs
so don't abandon conversion in such a case.

Signed-off-by: Akihiko Odaki 
---
contrib/elf2dmp/main.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/contrib/elf2dmp/main.c b/contrib/elf2dmp/main.c
index d77b8f98f7..91c58e4424 100644
--- a/contrib/elf2dmp/main.c
+++ b/contrib/elf2dmp/main.c
@@ -312,6 +312,11 @@ static int fill_context(KDDEBUGGER_DATA64 *kdbg,
return 1;
}

+ if (!Prcb) {
+ eprintf("Context for CPU #%d is missing\n", i);
+ continue;
+ }
+
if (va_space_rw(vs, Prcb + kdbg->OffsetPrcbContext,
&Context, sizeof(Context), 0)) {
eprintf("Failed to read CPU #%d ContextFrame location\n", i);

--
2.40.1


Hi Akihiko,

How this fix can be tested?


It is a bit difficult to test it as you need to interrupt the very early 
stage of boot. I applied the following change to TCG so that it stops 
immediately after the first processor configures Prcb.


diff --git a/target/i386/tcg/sysemu/misc_helper.c 
b/target/i386/tcg/sysemu/misc_helper.c

index e1528b7f80..f68eba9cac 100644
--- a/target/i386/tcg/sysemu/misc_helper.c
+++ b/target/i386/tcg/sysemu/misc_helper.c
@@ -25,6 +25,9 @@
 #include "exec/address-spaces.h"
 #include "exec/exec-all.h"
 #include "tcg/helper-tcg.h"
+#include "exec/gdbstub.h"
+#include "hw/core/cpu.h"
+#include "sysemu/runstate.h"

 void helper_outb(CPUX86State *env, uint32_t port, uint32_t data)
 {
@@ -217,7 +220,10 @@ void helper_wrmsr(CPUX86State *env)
 env->segs[R_FS].base = val;
 break;
 case MSR_GSBASE:
+printf("%s: %" PRIx64 "\n", __func__, val);
 env->segs[R_GS].base = val;
+gdb_set_stop_cpu(current_cpu);
+vm_stop(RUN_STATE_PAUSED);
 break;
 case MSR_KERNELGSBASE:
 env->kernelgsbase = val;



NumberProcessors field is still set to qemu_elf.state_nr, how does WinDbg react 
to this?


If Prcb for processor 1 is missing, WinDbg outputs: KiProcessorBlock[1] 
is null.

You can still debug the started processors with no issue.

Regards,
Akihiko Odaki



Viktor

Re: [PATCH] sdl2: Check if window exists before updating it

[Akihiko Odaki]

On 2023/06/12 18:00, Marc-André Lureau wrote:

Hi

On Thu, Jun 8, 2023 at 4:56 PM Akihiko Odaki > wrote:


A console does not have a window if the surface is a placeholder and
the console is not the first one. sdl2 cannot update the texture in
such a case.

Add a proper check for window existence. Such a check is only necessary
for the "gl" implementation as the "2d" implementation checks for the
texture, which is set only if a window exists.

Fixes: c821a58ee7 ("ui/console: Pass placeholder surface to displays")
Reported-by: Antonio Caggiano mailto:quic_acagg...@quicinc.com>>
Signed-off-by: Akihiko Odaki mailto:akihiko.od...@daynix.com>>



Unless I am mistaken, this is fixed in git already:
commit b3a654d82ecf276b59a67b2fd688e11a0d8a0064
Author: Marc-André Lureau >

Date:   Thu May 11 11:42:17 2023 +0400

     ui/sdl2: fix surface_gl_update_texture: Assertion 'gls' failed

thanks

---
  ui/sdl2-gl.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
index 39cab8cde7..bbfa70eac3 100644
--- a/ui/sdl2-gl.c
+++ b/ui/sdl2-gl.c
@@ -67,6 +67,10 @@ void sdl2_gl_update(DisplayChangeListener *dcl,

      assert(scon->opengl);

+    if (!scon->real_window) {
+        return;
+    }
+
      SDL_GL_MakeCurrent(scon->real_window, scon->winctx);
      surface_gl_update_texture(scon->gls, scon->surface, x, y, w, h);
      scon->updates++;
-- 
2.40.1





--
Marc-André Lureau


I overlooked it. You are right. It is identical and there is no need for 
additional patch.


Regards,
Akihiko Odaki

Re: [PATCH 5/5] cmd646: move device-specific BMDMA registers to separate memory region

[Philippe Mathieu-Daudé]

On 12/6/23 21:28, Bernhard Beschow wrote:



Am 9. Juni 2023 18:51:19 UTC schrieb Mark Cave-Ayland 
:

The aim here is to eliminate any device-specific registers from the main BMDMA
bar memory region so it can potentially be moved into the shared PCI IDE device.

For each BMDMA bus create a new cmd646-bmdma-specific memory region representing
the device-specific BMDMA registers and then map them using aliases onto the
existing BMDMAState memory region.

Signed-off-by: Mark Cave-Ayland 
---
hw/ide/cmd646.c | 111 +++-
include/hw/ide/cmd646.h |   4 ++
2 files changed, 90 insertions(+), 25 deletions(-)




struct CMD646IDEState {
 PCIIDEState parent_obj;
+
+MemoryRegion bmdma_mem[2];
+MemoryRegion bmdma_mem_alias[2][2];


The added complexity of a two-dimensional alias array seems like a tough call 
for me. I'm not totally against it but I'm reluctant.


Alternative:

struct {
MemoryRegion mem;
MemoryRegion mem_alias[2];
} bmdma[2];


};

#endif

[PATCH v3 2/4] hw/misc/bcm2835_property: Use 'raspberrypi-fw-defs.h' definitions

[Philippe Mathieu-Daudé]

From: Sergey Kambalin 

Replace magic property values by a proper definition,
removing redundant comments.

Signed-off-by: Sergey Kambalin 
Message-Id: <20230531155258.8361-1-sergey.kamba...@auriga.com>
[PMD: Split from bigger patch: 2/4]
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/misc/bcm2835_property.c | 101 +++--
 1 file changed, 51 insertions(+), 50 deletions(-)

diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
index 251b3d865d..7d398a6f75 100644
--- a/hw/misc/bcm2835_property.c
+++ b/hw/misc/bcm2835_property.c
@@ -12,6 +12,7 @@
 #include "migration/vmstate.h"
 #include "hw/irq.h"
 #include "hw/misc/bcm2835_mbox_defs.h"
+#include "hw/misc/raspberrypi-fw-defs.h"
 #include "sysemu/dma.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
@@ -51,48 +52,48 @@ static void bcm2835_property_mbox_push(BCM2835PropertyState 
*s, uint32_t value)
 /* @(value + 8) : Request/response indicator */
 resplen = 0;
 switch (tag) {
-case 0x: /* End tag */
+case RPI_FWREQ_PROPERTY_END:
 break;
-case 0x0001: /* Get firmware revision */
+case RPI_FWREQ_GET_FIRMWARE_REVISION:
 stl_le_phys(&s->dma_as, value + 12, 346337);
 resplen = 4;
 break;
-case 0x00010001: /* Get board model */
+case RPI_FWREQ_GET_BOARD_MODEL:
 qemu_log_mask(LOG_UNIMP,
   "bcm2835_property: 0x%08x get board model NYI\n",
   tag);
 resplen = 4;
 break;
-case 0x00010002: /* Get board revision */
+case RPI_FWREQ_GET_BOARD_REVISION:
 stl_le_phys(&s->dma_as, value + 12, s->board_rev);
 resplen = 4;
 break;
-case 0x00010003: /* Get board MAC address */
+case RPI_FWREQ_GET_BOARD_MAC_ADDRESS:
 resplen = sizeof(s->macaddr.a);
 dma_memory_write(&s->dma_as, value + 12, s->macaddr.a, resplen,
  MEMTXATTRS_UNSPECIFIED);
 break;
-case 0x00010004: /* Get board serial */
+case RPI_FWREQ_GET_BOARD_SERIAL:
 qemu_log_mask(LOG_UNIMP,
   "bcm2835_property: 0x%08x get board serial NYI\n",
   tag);
 resplen = 8;
 break;
-case 0x00010005: /* Get ARM memory */
+case RPI_FWREQ_GET_ARM_MEMORY:
 /* base */
 stl_le_phys(&s->dma_as, value + 12, 0);
 /* size */
 stl_le_phys(&s->dma_as, value + 16, s->fbdev->vcram_base);
 resplen = 8;
 break;
-case 0x00010006: /* Get VC memory */
+case RPI_FWREQ_GET_VC_MEMORY:
 /* base */
 stl_le_phys(&s->dma_as, value + 12, s->fbdev->vcram_base);
 /* size */
 stl_le_phys(&s->dma_as, value + 16, s->fbdev->vcram_size);
 resplen = 8;
 break;
-case 0x00028001: /* Set power state */
+case RPI_FWREQ_SET_POWER_STATE:
 /* Assume that whatever device they asked for exists,
  * and we'll just claim we set it to the desired state
  */
@@ -103,26 +104,26 @@ static void 
bcm2835_property_mbox_push(BCM2835PropertyState *s, uint32_t value)
 
 /* Clocks */
 
-case 0x00030001: /* Get clock state */
+case RPI_FWREQ_GET_CLOCK_STATE:
 stl_le_phys(&s->dma_as, value + 16, 0x1);
 resplen = 8;
 break;
 
-case 0x00038001: /* Set clock state */
+case RPI_FWREQ_SET_CLOCK_STATE:
 qemu_log_mask(LOG_UNIMP,
   "bcm2835_property: 0x%08x set clock state NYI\n",
   tag);
 resplen = 8;
 break;
 
-case 0x00030002: /* Get clock rate */
-case 0x00030004: /* Get max clock rate */
-case 0x00030007: /* Get min clock rate */
+case RPI_FWREQ_GET_CLOCK_RATE:
+case RPI_FWREQ_GET_MAX_CLOCK_RATE:
+case RPI_FWREQ_GET_MIN_CLOCK_RATE:
 switch (ldl_le_phys(&s->dma_as, value + 12)) {
-case 1: /* EMMC */
+case RPI_FIRMWARE_EMMC_CLK_ID:
 stl_le_phys(&s->dma_as, value + 16, 5000);
 break;
-case 2: /* UART */
+case RPI_FIRMWARE_UART_CLK_ID:
 stl_le_phys(&s->dma_as, value + 16, 300);
 break;
 default:
@@ -132,9 +133,9 @@ static void bcm2835_property_mbox_push(BCM2835PropertyState 
*s, uint32_t value)
 resplen = 8;
 break;
 
-case 0x00038002: /* Set clock rate */
-case 0x00038004: /* Set max clock rate */
-case 0x00038007: /* Set min clock rate */
+case RPI_FWREQ_SET_CLOCK_RATE:
+case RPI_FWREQ_SET_MAX_CLOCK_RATE:
+case RPI_FWREQ_SET_MIN_CLOCK_RATE:
 qemu_log_mask(L

[PATCH v3 1/4] hw/arm/raspi: Import Linux raspi definitions as 'raspberrypi-fw-defs.h'

[Philippe Mathieu-Daudé]

From: Sergey Kambalin 

Signed-off-by: Sergey Kambalin 
Message-Id: <20230531155258.8361-1-sergey.kamba...@auriga.com>
[PMD: Split from bigger patch: 1/4]
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/misc/raspberrypi-fw-defs.h | 163 ++
 1 file changed, 163 insertions(+)
 create mode 100644 include/hw/misc/raspberrypi-fw-defs.h

diff --git a/include/hw/misc/raspberrypi-fw-defs.h 
b/include/hw/misc/raspberrypi-fw-defs.h
new file mode 100644
index 00..4551fe7450
--- /dev/null
+++ b/include/hw/misc/raspberrypi-fw-defs.h
@@ -0,0 +1,163 @@
+/*
+ * Raspberry Pi firmware definitions
+ *
+ * Copyright (C) 2022  Auriga LLC, based on Linux kernel
+ *   `include/soc/bcm2835/raspberrypi-firmware.h` (Copyright © 2015 Broadcom)
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef INCLUDE_HW_MISC_RASPBERRYPI_FW_DEFS_H_
+#define INCLUDE_HW_MISC_RASPBERRYPI_FW_DEFS_H_
+
+#include "qemu/osdep.h"
+
+enum rpi_firmware_property_tag {
+RPI_FWREQ_PROPERTY_END =   0,
+RPI_FWREQ_GET_FIRMWARE_REVISION =  0x0001,
+RPI_FWREQ_GET_FIRMWARE_VARIANT =   0x0002,
+RPI_FWREQ_GET_FIRMWARE_HASH =  0x0003,
+
+RPI_FWREQ_SET_CURSOR_INFO =0x8010,
+RPI_FWREQ_SET_CURSOR_STATE =   0x8011,
+
+RPI_FWREQ_GET_BOARD_MODEL =0x00010001,
+RPI_FWREQ_GET_BOARD_REVISION = 0x00010002,
+RPI_FWREQ_GET_BOARD_MAC_ADDRESS =  0x00010003,
+RPI_FWREQ_GET_BOARD_SERIAL =   0x00010004,
+RPI_FWREQ_GET_ARM_MEMORY = 0x00010005,
+RPI_FWREQ_GET_VC_MEMORY =  0x00010006,
+RPI_FWREQ_GET_CLOCKS = 0x00010007,
+RPI_FWREQ_GET_POWER_STATE =0x00020001,
+RPI_FWREQ_GET_TIMING = 0x00020002,
+RPI_FWREQ_SET_POWER_STATE =0x00028001,
+RPI_FWREQ_GET_CLOCK_STATE =0x00030001,
+RPI_FWREQ_GET_CLOCK_RATE = 0x00030002,
+RPI_FWREQ_GET_VOLTAGE =0x00030003,
+RPI_FWREQ_GET_MAX_CLOCK_RATE = 0x00030004,
+RPI_FWREQ_GET_MAX_VOLTAGE =0x00030005,
+RPI_FWREQ_GET_TEMPERATURE =0x00030006,
+RPI_FWREQ_GET_MIN_CLOCK_RATE = 0x00030007,
+RPI_FWREQ_GET_MIN_VOLTAGE =0x00030008,
+RPI_FWREQ_GET_TURBO =  0x00030009,
+RPI_FWREQ_GET_MAX_TEMPERATURE =0x0003000a,
+RPI_FWREQ_GET_STC =0x0003000b,
+RPI_FWREQ_ALLOCATE_MEMORY =0x0003000c,
+RPI_FWREQ_LOCK_MEMORY =0x0003000d,
+RPI_FWREQ_UNLOCK_MEMORY =  0x0003000e,
+RPI_FWREQ_RELEASE_MEMORY = 0x0003000f,
+RPI_FWREQ_EXECUTE_CODE =   0x00030010,
+RPI_FWREQ_EXECUTE_QPU =0x00030011,
+RPI_FWREQ_SET_ENABLE_QPU = 0x00030012,
+RPI_FWREQ_GET_DISPMANX_RESOURCE_MEM_HANDLE =   0x00030014,
+RPI_FWREQ_GET_EDID_BLOCK = 0x00030020,
+RPI_FWREQ_GET_CUSTOMER_OTP =   0x00030021,
+RPI_FWREQ_GET_EDID_BLOCK_DISPLAY = 0x00030023,
+RPI_FWREQ_GET_DOMAIN_STATE =   0x00030030,
+RPI_FWREQ_GET_THROTTLED =  0x00030046,
+RPI_FWREQ_GET_CLOCK_MEASURED = 0x00030047,
+RPI_FWREQ_NOTIFY_REBOOT =  0x00030048,
+RPI_FWREQ_SET_CLOCK_STATE =0x00038001,
+RPI_FWREQ_SET_CLOCK_RATE = 0x00038002,
+RPI_FWREQ_SET_VOLTAGE =0x00038003,
+RPI_FWREQ_SET_MAX_CLOCK_RATE = 0x00038004,
+RPI_FWREQ_SET_MIN_CLOCK_RATE = 0x00038007,
+RPI_FWREQ_SET_TURBO =  0x00038009,
+RPI_FWREQ_SET_CUSTOMER_OTP =   0x00038021,
+RPI_FWREQ_SET_DOMAIN_STATE =   0x00038030,
+RPI_FWREQ_GET_GPIO_STATE = 0x00030041,
+RPI_FWREQ_SET_GPIO_STATE = 0x00038041,
+RPI_FWREQ_SET_SDHOST_CLOCK =   0x00038042,
+RPI_FWREQ_GET_GPIO_CONFIG =0x00030043,
+RPI_FWREQ_SET_GPIO_CONFIG =0x00038043,
+RPI_FWREQ_GET_PERIPH_REG = 0x00030045,
+RPI_FWREQ_SET_PERIPH_REG = 0x00038045,
+RPI_FWREQ_GET_POE_HAT_VAL =0x00030049,
+RPI_FWREQ_SET_POE_HAT_VAL =0x00038049,
+RPI_FW

[PATCH v3 0/4] hw/arm/raspi: Use named constants in BCM props

[Philippe Mathieu-Daudé]

v2: 
https://lore.kernel.org/qemu-devel/20230612115950.5002-1-sergey.kamba...@auriga.com/

This is a respin of Sergey's patch but
- split in multiple patches
- removing redundant comments

Sergey Kambalin (4):
  hw/arm/raspi: Import Linux raspi definitions as
'raspberrypi-fw-defs.h'
  hw/misc/bcm2835_property: Use 'raspberrypi-fw-defs.h' definitions
  hw/misc/bcm2835_property: Replace magic frequency values by
definitions
  hw/misc/bcm2835_property: Handle CORE_CLK_ID firmware property

 include/hw/arm/raspi_platform.h   |   6 +
 include/hw/misc/raspberrypi-fw-defs.h | 163 ++
 hw/misc/bcm2835_property.c| 112 +-
 3 files changed, 228 insertions(+), 53 deletions(-)
 create mode 100644 include/hw/misc/raspberrypi-fw-defs.h

-- 
2.38.1

[RFC PATCH v3 3/4] hw/misc/bcm2835_property: Replace magic frequency values by definitions

[Philippe Mathieu-Daudé]

From: Sergey Kambalin 

Signed-off-by: Sergey Kambalin 
Message-Id: <20230531155258.8361-1-sergey.kamba...@auriga.com>
[PMD: Split from bigger patch: 4/4]
Signed-off-by: Philippe Mathieu-Daudé 
---
FIXME: RPI_FIRMWARE_DEFAULT_CLK_RATE is raspi1-specific... Good enough for now?
---
 include/hw/arm/raspi_platform.h | 5 +
 hw/misc/bcm2835_property.c  | 8 +---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/include/hw/arm/raspi_platform.h b/include/hw/arm/raspi_platform.h
index 4a56dd4b89..83f2588fc5 100644
--- a/include/hw/arm/raspi_platform.h
+++ b/include/hw/arm/raspi_platform.h
@@ -170,4 +170,9 @@
 #define INTERRUPT_ILLEGAL_TYPE06
 #define INTERRUPT_ILLEGAL_TYPE17
 
+/* Clock rates */
+#define RPI_FIRMWARE_EMMC_CLK_RATE5000
+#define RPI_FIRMWARE_UART_CLK_RATE300
+#define RPI_FIRMWARE_DEFAULT_CLK_RATE 7
+
 #endif
diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
index 7d398a6f75..2e4fe969bf 100644
--- a/hw/misc/bcm2835_property.c
+++ b/hw/misc/bcm2835_property.c
@@ -17,6 +17,7 @@
 #include "qemu/log.h"
 #include "qemu/module.h"
 #include "trace.h"
+#include "hw/arm/raspi_platform.h"
 
 /* https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface */
 
@@ -121,13 +122,14 @@ static void 
bcm2835_property_mbox_push(BCM2835PropertyState *s, uint32_t value)
 case RPI_FWREQ_GET_MIN_CLOCK_RATE:
 switch (ldl_le_phys(&s->dma_as, value + 12)) {
 case RPI_FIRMWARE_EMMC_CLK_ID:
-stl_le_phys(&s->dma_as, value + 16, 5000);
+stl_le_phys(&s->dma_as, value + 16, 
RPI_FIRMWARE_EMMC_CLK_RATE);
 break;
 case RPI_FIRMWARE_UART_CLK_ID:
-stl_le_phys(&s->dma_as, value + 16, 300);
+stl_le_phys(&s->dma_as, value + 16, 
RPI_FIRMWARE_UART_CLK_RATE);
 break;
 default:
-stl_le_phys(&s->dma_as, value + 16, 7);
+stl_le_phys(&s->dma_as, value + 16,
+RPI_FIRMWARE_DEFAULT_CLK_RATE);
 break;
 }
 resplen = 8;
-- 
2.38.1

[RFC PATCH v3 4/4] hw/misc/bcm2835_property: Handle CORE_CLK_ID firmware property

[Philippe Mathieu-Daudé]

From: Sergey Kambalin 

Signed-off-by: Sergey Kambalin 
Message-Id: <20230531155258.8361-1-sergey.kamba...@auriga.com>
[PMD: Split from bigger patch: 3/4]
Signed-off-by: Philippe Mathieu-Daudé 
---
TOCHECK: seems raspi3-specific freq. Use a per-soc freq? Good enough for now?
---
 include/hw/arm/raspi_platform.h | 1 +
 hw/misc/bcm2835_property.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/include/hw/arm/raspi_platform.h b/include/hw/arm/raspi_platform.h
index 83f2588fc5..92a317950a 100644
--- a/include/hw/arm/raspi_platform.h
+++ b/include/hw/arm/raspi_platform.h
@@ -173,6 +173,7 @@
 /* Clock rates */
 #define RPI_FIRMWARE_EMMC_CLK_RATE5000
 #define RPI_FIRMWARE_UART_CLK_RATE300
+#define RPI_FIRMWARE_CORE_CLK_RATE35000
 #define RPI_FIRMWARE_DEFAULT_CLK_RATE 7
 
 #endif
diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
index 2e4fe969bf..4ed9faa54a 100644
--- a/hw/misc/bcm2835_property.c
+++ b/hw/misc/bcm2835_property.c
@@ -127,6 +127,9 @@ static void bcm2835_property_mbox_push(BCM2835PropertyState 
*s, uint32_t value)
 case RPI_FIRMWARE_UART_CLK_ID:
 stl_le_phys(&s->dma_as, value + 16, 
RPI_FIRMWARE_UART_CLK_RATE);
 break;
+case RPI_FIRMWARE_CORE_CLK_ID:
+stl_le_phys(&s->dma_as, value + 16, 
RPI_FIRMWARE_CORE_CLK_RATE);
+break;
 default:
 stl_le_phys(&s->dma_as, value + 16,
 RPI_FIRMWARE_DEFAULT_CLK_RATE);
-- 
2.38.1

Re: [PATCH v2] Use named constants in BCM props

[Philippe Mathieu-Daudé]

On 12/6/23 13:59, Sergey Kambalin wrote:

ping

- PI_FIRMWARE_*_RATE constsnts were moved to raspberrypi-fw-defs.h
   (seems more suitable place for them)
- inclusion of "qemu/osdep.h" has been removed
- year in copyright header has been updated

Signed-off-by: Sergey Kambalin 
---
  hw/misc/bcm2835_property.c| 120 ++-
  include/hw/arm/raspi_platform.h   |   6 +
  include/hw/misc/raspberrypi-fw-defs.h | 163 ++
  3 files changed, 236 insertions(+), 53 deletions(-)
  create mode 100644 include/hw/misc/raspberrypi-fw-defs.h




diff --git a/include/hw/arm/raspi_platform.h b/include/hw/arm/raspi_platform.h
index 4a56dd4b89..92a317950a 100644
--- a/include/hw/arm/raspi_platform.h
+++ b/include/hw/arm/raspi_platform.h
@@ -170,4 +170,10 @@
  #define INTERRUPT_ILLEGAL_TYPE06
  #define INTERRUPT_ILLEGAL_TYPE17
  
+/* Clock rates */

+#define RPI_FIRMWARE_EMMC_CLK_RATE5000


OK.


+#define RPI_FIRMWARE_UART_CLK_RATE300


OK.


+#define RPI_FIRMWARE_CORE_CLK_RATE35000


Seems VC4 frequency range, adapted for raspi3 (BCM2837).

IIUC the VC6 (raspi4) is clocked at 500MHz.


+#define RPI_FIRMWARE_DEFAULT_CLK_RATE 7


Seems VC4 freq for raspi1 (BCM2835)

Likely we don't want to use a default, but the correct per-soc
value...

Re: [PATCH] imx_serial: set wake bit when we receive a data byte

[Philippe Mathieu-Daudé]

Hi Martin,

On 8/6/23 17:41, Martin Kaiser wrote:

The linux kernel added a flood check for rx data recently in commmit
496a4471b7c3 ("serial: imx: work-around for hardware RX flood"). This
check uses the wake bit in the uart status register 2. The wake bit
indicates that the receiver detected a start bit. If the kernel sees a
number of rx interrupts without the wake bit being set, it treats this as
spurious data and resets the uart port. imx_serial does never set the
wake bit and triggers the kernel's flood check.

This patch adds support for the wake bit. wake is set when we receive a
new character (it's not set for break events). It seems that wake is
cleared by the kernel driver, the hardware does not have to clear it
automatically after data was read.

Signed-off-by: Martin Kaiser 
---
  hw/char/imx_serial.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
index ee1375e26d..44125d5f47 100644
--- a/hw/char/imx_serial.c
+++ b/hw/char/imx_serial.c
@@ -321,6 +321,9 @@ static void imx_put_data(void *opaque, uint32_t value)
  
  static void imx_receive(void *opaque, const uint8_t *buf, int size)

  {
+IMXSerialState *s = (IMXSerialState *)opaque;
+
+s->usr2 |= USR2_WAKE;
  imx_put_data(opaque, *buf);
  }
  


Shouldn't we mask this bit for interruptions now?

-- >8 --
diff --git a/include/hw/char/imx_serial.h b/include/hw/char/imx_serial.h
index 91c9894ad5..b823f94519 100644
--- a/include/hw/char/imx_serial.h
+++ b/include/hw/char/imx_serial.h
@@ -71,6 +71,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(IMXSerialState, IMX_SERIAL)

 #define UCR4_DREN   BIT(0)/* Receive Data Ready interrupt 
enable */

 #define UCR4_TCEN   BIT(3)/* TX complete interrupt enable */
+#define UCR4_WKEN   BIT(7)/* WAKE interrupt enable */

 #define UTS1_TXEMPTY(1<<6)
 #define UTS1_RXEMPTY(1<<5)
diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
index ee1375e26d..c8ec247350 100644
--- a/hw/char/imx_serial.c
+++ b/hw/char/imx_serial.c
@@ -80,7 +80,7 @@ static void imx_update(IMXSerialState *s)
  * TCEN and TXDC are both bit 3
  * RDR and DREN are both bit 0
  */
-mask |= s->ucr4 & (UCR4_TCEN | UCR4_DREN);
+mask |= s->ucr4 & (UCR4_WKEN | UCR4_TCEN | UCR4_DREN);

 usr2 = s->usr2 & mask;
---

[Bug 1180923] Re: unused memory filled with 0x00 instead of 0xFF

[Evren]

I am using Qemu 8.0.0 and this issue happens only when kvm is enabled, tcg 
initialized the unused bytes to 0xFF as a real machine and works normally, so a 
question in my mind, does kvm use those umb area for increased performance?
If emm386 M5 is used for using area D000-D7FF as frame page, emm386 gives a 
warning that there is an option rom in this location but it still uses this 
area, seems like a workaround, i do not know if it will have any side effect

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1180923

Title:
  unused memory filled with 0x00 instead of 0xFF

Status in QEMU:
  Expired

Bug description:
  Qemu, ever since it was made (so, since 2003), has this problem in DOS
  (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the
  memory available when the memory is filled with 0x00 but when it is
  filled with 0xFF it gets recognized properly, where should I patch
  qemu to solve this memory problem?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1180923/+subscriptions

Re: [RFC 4/6] migration: Deprecate -incoming

[Peter Xu]

On Mon, Jun 12, 2023 at 10:51:08PM +0200, Juan Quintela wrote:
> Peter Xu  wrote:
> > On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote:
> >> Only "defer" is recommended.  After setting all migation parameters,
> >> start incoming migration with "migrate-incoming uri" command.
> >> 
> >> Signed-off-by: Juan Quintela 
> >> ---
> >>  docs/about/deprecated.rst | 7 +++
> >>  softmmu/vl.c  | 2 ++
> >>  2 files changed, 9 insertions(+)
> >> 
> >> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> >> index 47e98dc95e..518672722d 100644
> >> --- a/docs/about/deprecated.rst
> >> +++ b/docs/about/deprecated.rst
> >> @@ -447,3 +447,10 @@ The new way to modify migration is using migration 
> >> parameters.
> >>  ``blk`` functionality can be acchieved using
> >>  ``migrate_set_parameter block-incremental true``.
> >>  
> >> +``-incoming uri`` (since 8.1)
> >> +'
> >> +
> >> +Everything except ``-incoming defer`` are deprecated.  This allows to
> >> +setup parameters before launching the proper migration with
> >> +``migrate-incoming uri``.
> >> +
> >> diff --git a/softmmu/vl.c b/softmmu/vl.c
> >> index b0b96f67fa..7fe865ab59 100644
> >> --- a/softmmu/vl.c
> >> +++ b/softmmu/vl.c
> >> @@ -2651,6 +2651,8 @@ void qmp_x_exit_preconfig(Error **errp)
> >>  if (incoming) {
> >>  Error *local_err = NULL;
> >>  if (strcmp(incoming, "defer") != 0) {
> >> +warn_report("-incoming %s is deprecated, use -incoming defer 
> >> and "
> >> +" set the uri with migrate-incoming.", incoming);
> >
> > I still use uri for all my scripts, alongside with "-global migration.xxx"
> > and it works.
> 
> You know what you are doing (TM).
> And remember that we don't support -gobal migration.x-foo.
> Yes, I know, we should drop the "x-" prefixes.

I hope they'll always be there. :) They're pretty handy for tests, when we
want to boot a VM without the need to script the sequences of qmp cmds.

Yes, we probably should just always drop the x-.  We can always declare
debugging purpose for all -global migration.* fields.

> 
> > Shall we just leave it there?  Or is deprecating it helps us in any form?
> 
> See the patches two weeks ago when people complained that lisen(.., num)
> was too low.  And there are other parameters that work the same way
> (that I convenientely had forgotten).  So the easiest way to get things
> right is to use "defer" always.  Using -incoming "uri" should only be
> for people that "know what they are doing", so we had to ways to do it:
> - review all migration options and see which ones work without defer
>   and document it
> - deprecate everything that is not defer.
> 
> Anything else is not going to be very user unfriendly.
> What do you think.

IIRC Wei Wang had a series just for that, so after that patchset applied we
should have fixed all issues cleanly?  Is there one more thing that's not
working right there?

> 
> Later, Juan.
> 
> PD.  This series are RFC for multiple reasons O:-)

Happy to know the rest (besides which I know will break my script :).

-- 
Peter Xu

Re: [RFC 4/6] migration: Deprecate -incoming

[Juan Quintela]

Peter Xu  wrote:
> On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote:
>> Only "defer" is recommended.  After setting all migation parameters,
>> start incoming migration with "migrate-incoming uri" command.
>> 
>> Signed-off-by: Juan Quintela 
>> ---
>>  docs/about/deprecated.rst | 7 +++
>>  softmmu/vl.c  | 2 ++
>>  2 files changed, 9 insertions(+)
>> 
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 47e98dc95e..518672722d 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -447,3 +447,10 @@ The new way to modify migration is using migration 
>> parameters.
>>  ``blk`` functionality can be acchieved using
>>  ``migrate_set_parameter block-incremental true``.
>>  
>> +``-incoming uri`` (since 8.1)
>> +'
>> +
>> +Everything except ``-incoming defer`` are deprecated.  This allows to
>> +setup parameters before launching the proper migration with
>> +``migrate-incoming uri``.
>> +
>> diff --git a/softmmu/vl.c b/softmmu/vl.c
>> index b0b96f67fa..7fe865ab59 100644
>> --- a/softmmu/vl.c
>> +++ b/softmmu/vl.c
>> @@ -2651,6 +2651,8 @@ void qmp_x_exit_preconfig(Error **errp)
>>  if (incoming) {
>>  Error *local_err = NULL;
>>  if (strcmp(incoming, "defer") != 0) {
>> +warn_report("-incoming %s is deprecated, use -incoming defer 
>> and "
>> +" set the uri with migrate-incoming.", incoming);
>
> I still use uri for all my scripts, alongside with "-global migration.xxx"
> and it works.

You know what you are doing (TM).
And remember that we don't support -gobal migration.x-foo.
Yes, I know, we should drop the "x-" prefixes.

> Shall we just leave it there?  Or is deprecating it helps us in any form?

See the patches two weeks ago when people complained that lisen(.., num)
was too low.  And there are other parameters that work the same way
(that I convenientely had forgotten).  So the easiest way to get things
right is to use "defer" always.  Using -incoming "uri" should only be
for people that "know what they are doing", so we had to ways to do it:
- review all migration options and see which ones work without defer
  and document it
- deprecate everything that is not defer.

Anything else is not going to be very user unfriendly.
What do you think.

Later, Juan.

PD.  This series are RFC for multiple reasons O:-)

Re: [PATCH] hw/i386/vmmouse: use the new input api

[Lucas Chollet]

Hi Marc-André,


Hi Lucas

On Thu, Jun 8, 2023 at 9:49 PM Lucas Chollet  
wrote:


No functional changes intended.

Signed-off-by: Lucas Chollet 
---
 hw/i386/vmmouse.c | 95
+++
 1 file changed, 71 insertions(+), 24 deletions(-)


The patch diff isn't great, and there is a risk of regressions. I 
wonder if input-legacy is really meant to be deprecated (after 10y it 
is still around).


I had the same conclusion but as I'm not familiar with QEMU development, 
I thought that you guys would quickly tell me if it's not worth.




Otherwise, the patch looks ok to me, except some question below:


diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c
index a56c185f15..bdddbb64ac 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -24,7 +24,7 @@

 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "ui/console.h"
+#include "ui/input.h"
 #include "hw/i386/vmport.h"
 #include "hw/input/i8042.h"
 #include "hw/qdev-properties.h"
@@ -61,7 +61,10 @@ struct VMMouseState {
     uint16_t nb_queue;
     uint16_t status;
     uint8_t absolute;
-    QEMUPutMouseEntry *entry;
+    int32_t last_x;
+    int32_t last_y;
+    int32_t last_buttons;
+    QemuInputHandlerState *entry;
     ISAKBDState *i8042;
 };

@@ -91,33 +94,72 @@ static uint32_t
vmmouse_get_status(VMMouseState *s)
     return (s->status << 16) | s->nb_queue;
 }

-static void vmmouse_mouse_event(void *opaque, int x, int y, int
dz, int buttons_state)
+static void vmmouse_mouse_event(DeviceState *dev, QemuConsole *src,
+                                InputEvent *evt)
 {
-    VMMouseState *s = opaque;
-    int buttons = 0;
+    static const int bmap[INPUT_BUTTON__MAX] = {
+        [INPUT_BUTTON_LEFT]   = 0x20,
+        [INPUT_BUTTON_MIDDLE] = 0x08,
+        [INPUT_BUTTON_RIGHT]  = 0x10,
+    };
+
+    VMMouseState *s = VMMOUSE(dev);
+    InputMoveEvent *move;
+    InputBtnEvent *btn;
+
+    int32_t dz = 0;

     if (s->nb_queue > (VMMOUSE_QUEUE_SIZE - 4))
         return;

-    DPRINTF("vmmouse_mouse_event(%d, %d, %d, %d)\n",
-            x, y, dz, buttons_state);
+    switch (evt->type) {
+    case INPUT_EVENT_KIND_REL:
+        move = evt->u.rel.data;
+        if (move->axis == INPUT_AXIS_X) {
+            s->last_x += move->value;
+        } else if (move->axis == INPUT_AXIS_Y) {
+            s->last_y -= move->value;
+        }
+        break;

-    if ((buttons_state & MOUSE_EVENT_LBUTTON))
-        buttons |= 0x20;
-    if ((buttons_state & MOUSE_EVENT_RBUTTON))
-        buttons |= 0x10;
-    if ((buttons_state & MOUSE_EVENT_MBUTTON))
-        buttons |= 0x08;
+    case INPUT_EVENT_KIND_ABS:
+        move = evt->u.rel.data;
+        if (move->axis == INPUT_AXIS_X) {
+            s->last_x = move->value;
+        } else if (move->axis == INPUT_AXIS_Y) {
+            s->last_y = move->value;
+        }
+        break;

-    if (s->absolute) {
-        x <<= 1;
-        y <<= 1;
+    case INPUT_EVENT_KIND_BTN:
+        btn = evt->u.btn.data;
+        if (btn->down) {
+            s->last_buttons |= bmap[btn->button];
+            if (btn->button == INPUT_BUTTON_WHEEL_UP) {
+                dz--;
+            } else if (btn->button == INPUT_BUTTON_WHEEL_DOWN) {
+                dz++;
+            }
+
+        } else {
+          s->last_buttons &= ~bmap[btn->button];
+        }
+        break;
+
+    default:
+        /* keep gcc happy */
+        break;
     }

-    s->queue[s->nb_queue++] = buttons;
-    s->queue[s->nb_queue++] = x;
-    s->queue[s->nb_queue++] = y;
+    s->queue[s->nb_queue++] = s->last_buttons;
+    s->queue[s->nb_queue++] = s->absolute ? s->last_x << 1 :
s->last_x;
+    s->queue[s->nb_queue++] = s->absolute ? s->last_y << 1 :
s->last_y;
     s->queue[s->nb_queue++] = dz;
+}
+
+static void vmmouse_mouse_sync(DeviceState *dev)
+{
+    VMMouseState *s = VMMOUSE(dev);

     /* need to still generate PS2 events to notify driver to
        read from queue */
@@ -127,11 +169,18 @@ static void vmmouse_mouse_event(void
*opaque, int x, int y, int dz, int buttons_
 static void vmmouse_remove_handler(VMMouseState *s)
 {
     if (s->entry) {
-        qemu_remove_mouse_event_handler(s->entry);
+        qemu_input_handler_unregister(s->entry);
         s->entry = NULL;
     }
 }

+static QemuInputHandler vm_mouse_handler = {
+    .name  = "vmmouse",
+    .mask  = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_ABS,
+    .event = vmmouse_mouse_event,
+    .sync  = vmmouse_mouse_sync,
+};
+

Re: [PATCH V2] migration: file URI

[Peter Xu]

On Mon, Jun 12, 2023 at 03:39:34PM -0400, Steven Sistare wrote:
> On 6/12/2023 2:44 PM, Peter Xu wrote:
> > Hi, Steve,
> > 
> > On Wed, Jun 07, 2023 at 11:38:59AM -0700, Steve Sistare wrote:
> >> Extend the migration URI to support file:.  This can be used for
> >> any migration scenario that does not require a reverse path.  It can be 
> >> used
> >> as an alternative to 'exec:cat > file' in minimized containers that do not
> >> contain /bin/sh, and it is easier to use than the fd: URI.  It can
> >> be used in HMP commands, and as a qemu command-line parameter.
> > 
> > I have similar question on the fixed-ram work,
> 
> Sorry, what is the "fixed-ram work"?

https://lore.kernel.org/all/20230330180336.2791-1-faro...@suse.de

It has similar requirement to migrate to a file, though slightly different
use case.

> 
> > on whether we should assume
> > the vm stopped before doing so.  Again, it leaves us space for
> > optimizations on top without breaking anyone.
> 
> I do not assume the vm is stopped.  The migration code will stop the vm
> in migration_iteration_finish.
> 
> > The other thing is considering a very busy guest, migration may not even
> > converge for "file:" URI (the same to other URIs) but I think that doesn't
> > make much sense to not converge for a "file:" URI.  The user might be very
> > confused too.
> 
> The file URI is mainly intended for the case where guest ram is backed by 
> shared memory 
> and preserved in place, in which case writes are not tracked and convergence 
> is not an
> issue.  If not shared memory, the user should be advised to stop the machine 
> first.
> I should document these notes in qemu-options and/or migration.json.

My question was whether we should treat "file:" differently from most of
other URIs.  It makes the URI slightly tricky for sure, but it also does
make sense to me because "file:" implies more than the rest URIs, where
we're sure about the consequence of the migration (vm stops), in that case
keeping vm live makes it less performant, and also weird.

It doesn't need to be special in memory type being shared, e.g. what if
there's a device that contains a lot of data to migrate in the future?
Assuming "shared memory will always migrate very fast" may not hold true.

Do you think it makes more sense to just always stop VM when migrating to
file URI?  Then if someone tries to restart the VM or cancel the migration,
we always do both (cancel migration, then start VM).

-- 
Peter Xu

Re: [RFC 4/6] migration: Deprecate -incoming

[Peter Xu]

On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote:
> Only "defer" is recommended.  After setting all migation parameters,
> start incoming migration with "migrate-incoming uri" command.
> 
> Signed-off-by: Juan Quintela 
> ---
>  docs/about/deprecated.rst | 7 +++
>  softmmu/vl.c  | 2 ++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 47e98dc95e..518672722d 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -447,3 +447,10 @@ The new way to modify migration is using migration 
> parameters.
>  ``blk`` functionality can be acchieved using
>  ``migrate_set_parameter block-incremental true``.
>  
> +``-incoming uri`` (since 8.1)
> +'
> +
> +Everything except ``-incoming defer`` are deprecated.  This allows to
> +setup parameters before launching the proper migration with
> +``migrate-incoming uri``.
> +
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index b0b96f67fa..7fe865ab59 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -2651,6 +2651,8 @@ void qmp_x_exit_preconfig(Error **errp)
>  if (incoming) {
>  Error *local_err = NULL;
>  if (strcmp(incoming, "defer") != 0) {
> +warn_report("-incoming %s is deprecated, use -incoming defer and 
> "
> +" set the uri with migrate-incoming.", incoming);

I still use uri for all my scripts, alongside with "-global migration.xxx"
and it works.

Shall we just leave it there?  Or is deprecating it helps us in any form?

-- 
Peter Xu

Re: [PATCH V2] migration: file URI

[Steven Sistare]

On 6/12/2023 2:44 PM, Peter Xu wrote:
> Hi, Steve,
> 
> On Wed, Jun 07, 2023 at 11:38:59AM -0700, Steve Sistare wrote:
>> Extend the migration URI to support file:.  This can be used for
>> any migration scenario that does not require a reverse path.  It can be used
>> as an alternative to 'exec:cat > file' in minimized containers that do not
>> contain /bin/sh, and it is easier to use than the fd: URI.  It can
>> be used in HMP commands, and as a qemu command-line parameter.
> 
> I have similar question on the fixed-ram work,

Sorry, what is the "fixed-ram work"?

> on whether we should assume
> the vm stopped before doing so.  Again, it leaves us space for
> optimizations on top without breaking anyone.

I do not assume the vm is stopped.  The migration code will stop the vm
in migration_iteration_finish.

> The other thing is considering a very busy guest, migration may not even
> converge for "file:" URI (the same to other URIs) but I think that doesn't
> make much sense to not converge for a "file:" URI.  The user might be very
> confused too.

The file URI is mainly intended for the case where guest ram is backed by 
shared memory 
and preserved in place, in which case writes are not tracked and convergence is 
not an
issue.  If not shared memory, the user should be advised to stop the machine 
first.
I should document these notes in qemu-options and/or migration.json.

- Steve

[RFC 4/6] migration: Deprecate -incoming

[Juan Quintela]

Only "defer" is recommended.  After setting all migation parameters,
start incoming migration with "migrate-incoming uri" command.

Signed-off-by: Juan Quintela 
---
 docs/about/deprecated.rst | 7 +++
 softmmu/vl.c  | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 47e98dc95e..518672722d 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -447,3 +447,10 @@ The new way to modify migration is using migration 
parameters.
 ``blk`` functionality can be acchieved using
 ``migrate_set_parameter block-incremental true``.
 
+``-incoming uri`` (since 8.1)
+'
+
+Everything except ``-incoming defer`` are deprecated.  This allows to
+setup parameters before launching the proper migration with
+``migrate-incoming uri``.
+
diff --git a/softmmu/vl.c b/softmmu/vl.c
index b0b96f67fa..7fe865ab59 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2651,6 +2651,8 @@ void qmp_x_exit_preconfig(Error **errp)
 if (incoming) {
 Error *local_err = NULL;
 if (strcmp(incoming, "defer") != 0) {
+warn_report("-incoming %s is deprecated, use -incoming defer and "
+" set the uri with migrate-incoming.", incoming);
 qmp_migrate_incoming(incoming, &local_err);
 if (local_err) {
 error_reportf_err(local_err, "-incoming %s: ", incoming);
-- 
2.40.1

[RFC 2/6] migration: migrate 'inc' command option is deprecated.

[Juan Quintela]

Use 'migrate_set_parameter block_incremental true' instead.

Signed-off-by: Juan Quintela 
---
 docs/about/deprecated.rst |  7 +++
 qapi/migration.json   | 11 +--
 migration/migration.c |  5 +
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index e1aa0eafc8..c75a3a8f5a 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -433,3 +433,10 @@ Migration
 ``skipped`` field in Migration stats has been deprecated.  It hasn't
 been used for more than 10 years.
 
+``inc`` migrate command option (since 8.1)
+''
+
+The new way to modify migration is using migration parameters.
+``inc`` functionality can be acchieved using
+``migrate_set_parameter block-incremental true``.
+
diff --git a/qapi/migration.json b/qapi/migration.json
index bcae193733..4ee28df6da 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1424,13 +1424,19 @@
 #
 # @blk: do block migration (full disk copy)
 #
-# @inc: incremental disk copy migration
+# @inc: incremental disk copy migration.  This option is deprecated.
+#Use 'migrate_set_parameter block-incremetantal true' instead.
 #
 # @detach: this argument exists only for compatibility reasons and is
 # ignored by QEMU
 #
 # @resume: resume one paused migration, default "off". (since 3.0)
 #
+# Features:
+#
+# @deprecated: option @inc is better set with
+# 'migrate_set_parameter block-incremental true'.
+#
 # Returns: nothing on success
 #
 # Since: 0.14
@@ -1452,7 +1458,8 @@
 # <- { "return": {} }
 ##
 { 'command': 'migrate',
-  'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool',
+  'data': {'uri': 'str', '*blk': 'bool',
+   '*inc': { 'type': 'bool', 'features': ['deprecated'] },
'*detach': 'bool', '*resume': 'bool' } }
 
 ##
diff --git a/migration/migration.c b/migration/migration.c
index dc05c6f6ea..7ebce7c7bf 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1544,6 +1544,11 @@ static bool migrate_prepare(MigrationState *s, bool blk, 
bool blk_inc,
 {
 Error *local_err = NULL;
 
+if (blk_inc) {
+warn_report("-inc migrate option is deprecated, use"
+"'migrate_set_parameter block-incremental true' instead.");
+}
+
 if (resume) {
 if (s->state != MIGRATION_STATUS_POSTCOPY_PAUSED) {
 error_setg(errp, "Cannot resume if there is no "
-- 
2.40.1

[RFC 0/6] Migration deprecated parts

[Juan Quintela]

Hi this series describe the migration parts that have to be deprecated.

- It is an rfc because I doubt that I did the deprecation process right. Hello 
Markus O:-)

- skipped field: It is older than me, I have never know what it stands
  for.  As far as I know it has always been zero.

- inc/blk migrate command options.  They are only used by block
  migration (that I deprecate on the following patch).  And they are really bad.
  grep must_remove_block_options.

- block migration.  block jobs, whatever they are called this week are
  way more flexible.  Current code works, but we broke it here and
  there, and really nobody has stand up to maintain it.  It is quite
  contained and can be left there.  Is anyone really using it?

- old compression method.  It don't work.  See last try from Lukas to
  make a test that works reliabely.  I failed with the same task years
  ago.  It is really slow, and if compression is good for you, multifd
  + zlib is going to perform/compress way more.

  I don't know what to do with this code, really.

  * Remove it for this release?  It don't work, and haven't work
reliabely in quite a few time.

  * Deprecate it and remove in another couple of releases, i.e. normal
deprecation.

  * Ideas?

- -incoming 

  if you need to set parameters (multifd cames to mind, and preempt has
  the same problem), you really needs to use defer.  So what should we do here?

  This part is not urget, because management apps have a working
  option that are already using "defer", and the code simplifacation
  if we remove it is not so big.  So we can leave it until 9.0 or
  whatever we think fit.

What do you think?

Later, Juan.

Juan Quintela (6):
  migration: skipped field is really obsolete.
  migration: migrate 'inc' command option is deprecated.
  migration: migrate 'blk' command option is deprecated.
  migration: Deprecate -incoming 
  migration: Deprecate block migration
  migration: Deprecated old compression method

 docs/about/deprecated.rst |  45 
 qapi/migration.json   | 141 +++---
 migration/block.c |   2 +
 migration/migration.c |  10 +++
 migration/options.c   |  20 ++
 softmmu/vl.c  |   2 +
 6 files changed, 181 insertions(+), 39 deletions(-)


base-commit: 5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc
prerequisite-patch-id: 99c8bffa9428838925e330eb2881bab476122579
prerequisite-patch-id: 77ba427fd916aeb395e95aa0e7190f84e98e96ab
prerequisite-patch-id: 9983d46fa438d7075a37be883529e37ae41e4228
prerequisite-patch-id: 207f7529924b12dcb57f6557d6db6f79ceb2d682
prerequisite-patch-id: 5ad1799a13845dbf893a28a202b51a6b50d95d90
prerequisite-patch-id: c51959aacd6d65ee84fcd4f1b2aed3dd6f6af879
prerequisite-patch-id: da9dbb6799b2da002c0896574334920097e4c50a
prerequisite-patch-id: c1110ffafbaf5465fb277a20db809372291f7846
prerequisite-patch-id: 8307c92bedd07446214b35b40206eb6793a7384d
prerequisite-patch-id: 0a6106cd4a508d5e700a7ff6c25edfdd03c8ca3d
prerequisite-patch-id: 83205051de22382e75bf4acdf69e59315801fa0d
prerequisite-patch-id: 8c9b3cba89d555c071a410041e6da41806106a7e
prerequisite-patch-id: 0ff62a33b9a242226ccc1f5424a516de803c9fe5
prerequisite-patch-id: 25b8ae1ebe09ace14457c454cfcb23077c37346c
prerequisite-patch-id: 466ea91d5be41fe345dacd4d17bbbe5ce13118c2
prerequisite-patch-id: d1045858f9729ac62eccf2e83ebf95cfebae2cb5
prerequisite-patch-id: 0276ec02073bda5426de39e2f2e81eef080b4f54
prerequisite-patch-id: 7afb4450a163cc1a63ea23831c50214966969131
prerequisite-patch-id: 06c053ce4f41db9675bd1778ae8f6a483641fcef
prerequisite-patch-id: 13ea05d54d741ed08b3bfefa1fc8bedb9c81c782
prerequisite-patch-id: 99c4e2b7101bc8c4b9515129a1bbe6f068053dbf
prerequisite-patch-id: 1e393a196dc7a1ee75f3cc3cebbb591c5422102f
prerequisite-patch-id: 2cf497b41f5024ede0a224b1f5b172226067a534
prerequisite-patch-id: 2a70276ed61d33fc4f3b52560753c05d1cd413be
prerequisite-patch-id: 17ec40f4388b62ba8bf3ac1546c6913f5d1f6079
prerequisite-patch-id: dba969ce9d6cf69c1319661a7d81b1c1c719804d
prerequisite-patch-id: 8d800cda87167314f07320bdb3df936c323e4a40
prerequisite-patch-id: 25d4aaf54ea66f30e426fa38bdd4e0f47303c513
prerequisite-patch-id: 082c9d8584c1daff1e827e44ee3047178e7004a7
prerequisite-patch-id: 0ef73900899425ae2f00751347afdce3739aa954
prerequisite-patch-id: e7db4730b791b71aaf417ee0f65fb6304566aaf8
prerequisite-patch-id: 62d7f28f8196039507ffe362f97723395d7bb704
prerequisite-patch-id: ea8de47bcb54e33bcc67e59e9ed752a4d1fad703
prerequisite-patch-id: 497893ef92e1ea56bd8605e6990a05cb4c7f9293
prerequisite-patch-id: 3dc869c80ee568449bbfa2a9bc427524d0e8970b
prerequisite-patch-id: 52c14b6fb14ed4ccd685385a9fbc6297b762c0ef
prerequisite-patch-id: 23de8371e9e3277c374a47f9bd10de209a22fdd5
prerequisite-patch-id: d21f036dd106af3375fb920bf0a557fe2b86d98e
prerequisite-patch-id: ca717076e9de83d6ce370f7374c4729a9f586fae
prerequisite-patch-id: a235b6ab3237155f2b39e8e10d47ddd250f6b6cc
prerequisite-patch-id: 6db2aa3d8a5804c85dd171864f5140fadf5f72da
prerequisite-patch-i

[RFC 5/6] migration: Deprecate block migration

[Juan Quintela]

It is obsolete.  It is better to use driver_mirror+NBD instead.

CC: Kevin Wolf 
CC: Eric Blake 
CC: Stefan Hajnoczi 
CC: Hanna Czenczek 

Signed-off-by: Juan Quintela 

---

Can any of you give one example of how to use driver_mirror+NBD for
deprecated.rst?

Thanks, Juan.
---
 docs/about/deprecated.rst |  6 ++
 qapi/migration.json   | 29 +
 migration/block.c |  2 ++
 migration/options.c   |  7 +++
 4 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 518672722d..173c5ba5cb 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -454,3 +454,9 @@ Everything except ``-incoming defer`` are deprecated.  This 
allows to
 setup parameters before launching the proper migration with
 ``migrate-incoming uri``.
 
+block migration (since 8.1)
+'''
+
+Block migration is too inflexible.  It needs to migrate all block
+devices or none.  Use driver_mirror+NBD instead.
+
diff --git a/qapi/migration.json b/qapi/migration.json
index b71e00737e..a8497de48d 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -258,11 +258,16 @@
 # blocked.  Present and non-empty when migration is blocked.
 # (since 6.0)
 #
+# Features:
+#
+# @deprecated: @disk migration is deprecated.  Use driver_mirror+NBD
+# instead.
+#
 # Since: 0.14
 ##
 { 'struct': 'MigrationInfo',
   'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats',
-   '*disk': 'MigrationStats',
+   '*disk': { 'type': 'MigrationStats', 'features': ['deprecated'] },
'*vfio': 'VfioStats',
'*xbzrle-cache': 'XBZRLECacheStats',
'*total-time': 'int',
@@ -497,6 +502,9 @@
 #
 # Features:
 #
+# @deprecated: @block migration is deprecated.  Use driver_mirror+NBD
+# instead.
+#
 # @unstable: Members @x-colo and @x-ignore-shared are experimental.
 #
 # Since: 1.2
@@ -506,7 +514,8 @@
'compress', 'events', 'postcopy-ram',
{ 'name': 'x-colo', 'features': [ 'unstable' ] },
'release-ram',
-   'block', 'return-path', 'pause-before-switchover', 'multifd',
+   { 'name': 'block', 'features': [ 'deprecated' ] },
+   'return-path', 'pause-before-switchover', 'multifd',
'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
{ 'name': 'x-ignore-shared', 'features': [ 'unstable' ] },
'validate-uuid', 'background-snapshot',
@@ -789,6 +798,9 @@
 #
 # Features:
 #
+# @deprecated: Member @block-incremental is obsolete. Use
+# driver_mirror+NBD instead.
+#
 # @unstable: Member @x-checkpoint-delay is experimental.
 #
 # Since: 2.4
@@ -803,7 +815,7 @@
'tls-creds', 'tls-hostname', 'tls-authz', 'max-bandwidth',
'downtime-limit',
{ 'name': 'x-checkpoint-delay', 'features': [ 'unstable' ] },
-   'block-incremental',
+   { 'name': 'block-incremental', 'features': [ 'deprecated' ] },
'multifd-channels',
'xbzrle-cache-size', 'max-postcopy-bandwidth',
'max-cpu-throttle', 'multifd-compression',
@@ -945,6 +957,9 @@
 #
 # Features:
 #
+# @deprecated: Member @block-incremental is obsolete. Use
+# driver_mirror+NBD instead.
+#
 # @unstable: Member @x-checkpoint-delay is experimental.
 #
 # TODO: either fuse back into MigrationParameters, or make
@@ -972,7 +987,8 @@
 '*downtime-limit': 'uint64',
 '*x-checkpoint-delay': { 'type': 'uint32',
  'features': [ 'unstable' ] },
-'*block-incremental': 'bool',
+'*block-incremental': { 'type': 'bool',
+'features': [ 'deprecated' ] },
 '*multifd-channels': 'uint8',
 '*xbzrle-cache-size': 'size',
 '*max-postcopy-bandwidth': 'size',
@@ -1137,6 +1153,9 @@
 #
 # Features:
 #
+# @deprecated: Member @block-incremental is obsolete. Use
+# driver_mirror+NBD instead.
+#
 # @unstable: Member @x-checkpoint-delay is experimental.
 #
 # Since: 2.4
@@ -1161,6 +1180,8 @@
 '*downtime-limit': 'uint64',
 '*x-checkpoint-delay': { 'type': 'uint32',
  'features': [ 'unstable' ] },
+'*block-incremental': { 'type': 'bool',
+'features': [ 'deprecated' ] },
 '*block-incremental': 'bool',
 '*multifd-channels': 'uint8',
 '*xbzrle-cache-size': 'size',
diff --git a/migration/block.c b/migration/block.c
index b9580a6c7e..2521a22269 100644
--- a/migration/block.c
+++ b/migration/block.c
@@ -722,6 +722,8 @@ static int block_save_setup(QEMUFile *f, void *opaque)
 trace_migration_block_save("setup", block_mig_state.submitted,
block_mig_state.transferred);
 
+warn_report("block migration is deprecated.  Use mirror jobs instead.");
+
 qemu_

[RFC 1/6] migration: skipped field is really obsolete.

[Juan Quintela]

Has return zero for more than 10 years.  Just mark it deprecated.

Signed-off-by: Juan Quintela 
---
 docs/about/deprecated.rst | 10 ++
 qapi/migration.json   | 12 ++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..e1aa0eafc8 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -423,3 +423,13 @@ both, older and future versions of QEMU.
 The ``blacklist`` config file option has been renamed to ``block-rpcs``
 (to be in sync with the renaming of the corresponding command line
 option).
+
+Migration
+-
+
+``skipped`` MigrationStats field (since 8.1)
+
+
+``skipped`` field in Migration stats has been deprecated.  It hasn't
+been used for more than 10 years.
+
diff --git a/qapi/migration.json b/qapi/migration.json
index cb7cd3e578..bcae193733 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -23,7 +23,8 @@
 #
 # @duplicate: number of duplicate (zero) pages (since 1.2)
 #
-# @skipped: number of skipped zero pages (since 1.5)
+# @skipped: number of skipped zero pages. Don't use, only provided for
+# compatibility (since 1.5)
 #
 # @normal: number of normal pages (since 1.2)
 #
@@ -62,11 +63,18 @@
 # between 0 and @dirty-sync-count * @multifd-channels.  (since
 # 7.1)
 #
+# Features:
+#
+# @deprecated: Member @skipped has not been used for a long time.
+#
 # Since: 0.14
+#
 ##
 { 'struct': 'MigrationStats',
   'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
-   'duplicate': 'int', 'skipped': 'int', 'normal': 'int',
+   'duplicate': 'int',
+   'skipped': { 'type': 'int', 'features': ['deprecated'] },
+   'normal': 'int',
'normal-bytes': 'int', 'dirty-pages-rate': 'int',
'mbps': 'number', 'dirty-sync-count': 'int',
'postcopy-requests': 'int', 'page-size': 'int',
-- 
2.40.1

[RFC 6/6] migration: Deprecated old compression method

[Juan Quintela]

Signed-off-by: Juan Quintela 
---
 docs/about/deprecated.rst |  8 
 qapi/migration.json   | 92 ---
 migration/options.c   | 13 ++
 3 files changed, 79 insertions(+), 34 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 173c5ba5cb..fe7f2bbde8 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -460,3 +460,11 @@ block migration (since 8.1)
 Block migration is too inflexible.  It needs to migrate all block
 devices or none.  Use driver_mirror+NBD instead.
 
+old compression method (since 8.1)
+''
+
+Compression method fails too much.  Too many races.  We are going to
+remove it if nobody fixes it.  For starters, migration-test
+compression tests are disabled becase they hand randomly.  If you need
+compression, use multifd compression methods.
+
diff --git a/qapi/migration.json b/qapi/migration.json
index a8497de48d..40a8b5d124 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -244,6 +244,7 @@
 #
 # @compression: migration compression statistics, only returned if
 # compression feature is on and status is 'active' or 'completed'
+# It is obsolete and deprecated.  Use multifd compression methods.
 # (Since 3.1)
 #
 # @socket-address: Only used for tcp, to know what the real port is
@@ -261,7 +262,8 @@
 # Features:
 #
 # @deprecated: @disk migration is deprecated.  Use driver_mirror+NBD
-# instead.
+# instead. @compression is obsolete use multifd compression
+# methods instead.
 #
 # Since: 0.14
 ##
@@ -279,7 +281,7 @@
'*blocked-reasons': ['str'],
'*postcopy-blocktime': 'uint32',
'*postcopy-vcpu-blocktime': ['uint32'],
-   '*compression': 'CompressionStats',
+   '*compression': { 'type': 'CompressionStats', 'features': 
['deprecated'] },
'*socket-address': ['SocketAddress'] } }
 
 ##
@@ -432,7 +434,8 @@
 # compress and xbzrle are both on, compress only takes effect in
 # the ram bulk stage, after that, it will be disabled and only
 # xbzrle takes effect, this can help to minimize migration
-# traffic.  The feature is disabled by default.  (since 2.4 )
+# traffic.  The feature is disabled by default.  Obsolete.  Use
+# multifd compression methods if needed. (since 2.4 )
 #
 # @events: generate events for each migration state change (since 2.4
 # )
@@ -503,6 +506,7 @@
 # Features:
 #
 # @deprecated: @block migration is deprecated.  Use driver_mirror+NBD
+# instead. @compress is obsolete use multifd compression methods
 # instead.
 #
 # @unstable: Members @x-colo and @x-ignore-shared are experimental.
@@ -511,7 +515,8 @@
 ##
 { 'enum': 'MigrationCapability',
   'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
-   'compress', 'events', 'postcopy-ram',
+   { 'name': 'compress', 'features': [ 'deprecated' ] },
+   'events', 'postcopy-ram',
{ 'name': 'x-colo', 'features': [ 'unstable' ] },
'release-ram',
{ 'name': 'block', 'features': [ 'deprecated' ] },
@@ -671,22 +676,24 @@
 # migration, the compression level is an integer between 0 and 9,
 # where 0 means no compression, 1 means the best compression
 # speed, and 9 means best compression ratio which will consume
-# more CPU.
+# more CPU. Obsolete, see multifd compression if needed.
 #
 # @compress-threads: Set compression thread count to be used in live
 # migration, the compression thread count is an integer between 1
-# and 255.
+# and 255. Obsolete, see multifd compression if needed.
 #
 # @compress-wait-thread: Controls behavior when all compression
 # threads are currently busy.  If true (default), wait for a free
 # compression thread to become available; otherwise, send the page
-# uncompressed.  (Since 3.1)
+# uncompressed. Obsolete, see multifd compression if
+# needed. (Since 3.1)
 #
 # @decompress-threads: Set decompression thread count to be used in
 # live migration, the decompression thread count is an integer
 # between 1 and 255. Usually, decompression is at least 4 times as
 # fast as compression, so set the decompress-threads to the number
-# about 1/4 of compress-threads is adequate.
+# about 1/4 of compress-threads is adequate. Obsolete, see multifd
+# compression if needed.
 #
 # @throttle-trigger-threshold: The ratio of bytes_dirty_period and
 # bytes_xfer_period to trigger throttling.  It is expressed as
@@ -799,7 +806,9 @@
 # Features:
 #
 # @deprecated: Member @block-incremental is obsolete. Use
-# driver_mirror+NBD instead.
+# driver_mirror+NBD instead. Compression is obsolete, so members
+# @compress-level, @compress-threads, @decompress-threads and
+# @compress-wait-thread should not be used.
 #
 # @unstable: Member @x-checkpoint-delay is experimental.
 #
@@ -808,8 +817,11 @@
 { 'enum': 'Migra

[RFC 3/6] migration: migrate 'blk' command option is deprecated.

[Juan Quintela]

Use 'migrate_set_capability block true' instead.

Signed-off-by: Juan Quintela 
---
 docs/about/deprecated.rst |  7 +++
 qapi/migration.json   | 11 +++
 migration/migration.c |  5 +
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index c75a3a8f5a..47e98dc95e 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -440,3 +440,10 @@ The new way to modify migration is using migration 
parameters.
 ``inc`` functionality can be acchieved using
 ``migrate_set_parameter block-incremental true``.
 
+``blk`` migrate command option (since 8.1)
+''
+
+The new way to modify migration is using migration parameters.
+``blk`` functionality can be acchieved using
+``migrate_set_parameter block-incremental true``.
+
diff --git a/qapi/migration.json b/qapi/migration.json
index 4ee28df6da..b71e00737e 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1422,7 +1422,8 @@
 #
 # @uri: the Uniform Resource Identifier of the destination VM
 #
-# @blk: do block migration (full disk copy)
+# @blk: do block migration (full disk copy). This option is deprecated.
+#Use 'migrate_set_capability block true' instead.
 #
 # @inc: incremental disk copy migration.  This option is deprecated.
 #Use 'migrate_set_parameter block-incremetantal true' instead.
@@ -1434,8 +1435,9 @@
 #
 # Features:
 #
-# @deprecated: option @inc is better set with
-# 'migrate_set_parameter block-incremental true'.
+# @deprecated: options @inc and @blk are better set with
+# 'migrate_set_parameter block-incremental true' and
+# 'migrate_set_capability block true' respectively.
 #
 # Returns: nothing on success
 #
@@ -1458,7 +1460,8 @@
 # <- { "return": {} }
 ##
 { 'command': 'migrate',
-  'data': {'uri': 'str', '*blk': 'bool',
+  'data': {'uri': 'str',
+   '*blk': { 'type': 'bool', 'features': ['deprecated'] },
'*inc': { 'type': 'bool', 'features': ['deprecated'] },
'*detach': 'bool', '*resume': 'bool' } }
 
diff --git a/migration/migration.c b/migration/migration.c
index 7ebce7c7bf..b7d5f6b96c 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1549,6 +1549,11 @@ static bool migrate_prepare(MigrationState *s, bool blk, 
bool blk_inc,
 "'migrate_set_parameter block-incremental true' instead.");
 }
 
+if (blk) {
+warn_report("-blk migrate option is deprecated, use"
+"'migrate_set_capability block true' instead.");
+}
+
 if (resume) {
 if (s->state != MIGRATION_STATUS_POSTCOPY_PAUSED) {
 error_setg(errp, "Cannot resume if there is no "
-- 
2.40.1

Re: [PATCH 5/5] cmd646: move device-specific BMDMA registers to separate memory region

[Bernhard Beschow]

Am 9. Juni 2023 18:51:19 UTC schrieb Mark Cave-Ayland 
:
>The aim here is to eliminate any device-specific registers from the main BMDMA
>bar memory region so it can potentially be moved into the shared PCI IDE 
>device.
>
>For each BMDMA bus create a new cmd646-bmdma-specific memory region 
>representing
>the device-specific BMDMA registers and then map them using aliases onto the
>existing BMDMAState memory region.
>
>Signed-off-by: Mark Cave-Ayland 
>---
> hw/ide/cmd646.c | 111 +++-
> include/hw/ide/cmd646.h |   4 ++
> 2 files changed, 90 insertions(+), 25 deletions(-)
>
>diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
>index 9103da581f..dd495f2e1b 100644
>--- a/hw/ide/cmd646.c
>+++ b/hw/ide/cmd646.c
>@@ -90,7 +90,6 @@ static uint64_t bmdma_read(void *opaque, hwaddr addr,
>unsigned size)
> {
> BMDMAState *bm = opaque;
>-PCIDevice *pci_dev = PCI_DEVICE(bm->pci_dev);
> uint32_t val;
> 
> if (size != 1) {
>@@ -101,19 +100,9 @@ static uint64_t bmdma_read(void *opaque, hwaddr addr,
> case 0:
> val = bm->cmd;
> break;
>-case 1:
>-val = pci_dev->config[MRDMODE];
>-break;
> case 2:
> val = bm->status;
> break;
>-case 3:
>-if (bm == &bm->pci_dev->bmdma[0]) {
>-val = pci_dev->config[UDIDETCR0];
>-} else {
>-val = pci_dev->config[UDIDETCR1];
>-}
>-break;
> default:
> val = 0xff;
> break;
>@@ -127,7 +116,6 @@ static void bmdma_write(void *opaque, hwaddr addr,
> uint64_t val, unsigned size)
> {
> BMDMAState *bm = opaque;
>-PCIDevice *pci_dev = PCI_DEVICE(bm->pci_dev);
> 
> if (size != 1) {
> return;
>@@ -138,23 +126,10 @@ static void bmdma_write(void *opaque, hwaddr addr,
> case 0:
> bmdma_cmd_writeb(bm, val);
> break;
>-case 1:
>-pci_dev->config[MRDMODE] =
>-(pci_dev->config[MRDMODE] & ~0x30) | (val & 0x30);
>-cmd646_update_dma_interrupts(pci_dev);
>-cmd646_update_irq(pci_dev);
>-break;
> case 2:
> bm->status = (val & 0x60) | (bm->status & 1) |
>  (bm->status & ~val & 0x06);
> break;
>-case 3:
>-if (bm == &bm->pci_dev->bmdma[0]) {
>-pci_dev->config[UDIDETCR0] = val;
>-} else {
>-pci_dev->config[UDIDETCR1] = val;
>-}
>-break;
> }
> }
> 
>@@ -181,6 +156,91 @@ static void bmdma_setup_bar(PCIIDEState *d)
> }
> }
> 
>+static uint64_t cmd646_bmdma_read(void *opaque, hwaddr addr, unsigned size)
>+{
>+BMDMAState *bm = opaque;
>+PCIDevice *pci_dev = PCI_DEVICE(bm->pci_dev);
>+uint32_t val;
>+
>+if (size != 1) {
>+return ((uint64_t)1 << (size * 8)) - 1;
>+}
>+
>+switch (addr & 3) {
>+case 1:
>+val = pci_dev->config[MRDMODE];
>+break;
>+case 3:
>+if (bm == &bm->pci_dev->bmdma[0]) {
>+val = pci_dev->config[UDIDETCR0];
>+} else {
>+val = pci_dev->config[UDIDETCR1];
>+}
>+break;
>+default:
>+val = 0xff;
>+break;
>+}
>+
>+trace_bmdma_read_cmd646(addr, val);
>+return val;
>+}
>+
>+static void cmd646_bmdma_write(void *opaque, hwaddr addr, uint64_t val,
>+   unsigned size)
>+{
>+BMDMAState *bm = opaque;
>+PCIDevice *pci_dev = PCI_DEVICE(bm->pci_dev);
>+
>+if (size != 1) {
>+return;
>+}
>+
>+trace_bmdma_write_cmd646(addr, val);
>+switch (addr & 3) {
>+case 1:
>+pci_dev->config[MRDMODE] =
>+(pci_dev->config[MRDMODE] & ~0x30) | (val & 0x30);
>+cmd646_update_dma_interrupts(pci_dev);
>+cmd646_update_irq(pci_dev);
>+break;
>+case 3:
>+if (bm == &bm->pci_dev->bmdma[0]) {
>+pci_dev->config[UDIDETCR0] = val;
>+} else {
>+pci_dev->config[UDIDETCR1] = val;
>+}
>+break;
>+}
>+}
>+
>+static const MemoryRegionOps cmd646_bmdma_ops = {
>+.read = cmd646_bmdma_read,
>+.write = cmd646_bmdma_write,
>+};
>+
>+static void cmd646_bmdma_setup(PCIIDEState *d)
>+{
>+CMD646IDEState *s = CMD646_IDE(d);
>+BMDMAState *bm;
>+int i;
>+
>+/* Setup aliases for device-specific BMDMA registers */
>+for (i = 0; i < 2; i++) {

I'd use `ARRAY_SIZE()` instead of the hardcoded constant here.

>+bm = &d->bmdma[i];
>+memory_region_init_io(&s->bmdma_mem[i], OBJECT(d), &cmd646_bmdma_ops,
>+  bm, "cmd646-bmdma", 4);
>+memory_region_init_alias(&s->bmdma_mem_alias[i][0], OBJECT(d),
>+ "cmd646-bmdma[1]", &s->bmdma_mem[i], 0x1, 1);
>+memory_region_add_subregion(&bm->extra_io, 0x1,
>+&s->bmdma_mem_alias[i][0]);
>+memory_region_init_alias(&s->bmdma_mem_alias[i][1], OBJECT

Re: [PATCH 15/15] hw/i386/pc_piix: Move i440fx' realize near its qdev_new()

[Bernhard Beschow]

Am 12. Juni 2023 15:21:19 UTC schrieb Igor Mammedov :
>On Mon, 12 Jun 2023 16:51:55 +0200
>Igor Mammedov  wrote:
>
>> On Sun, 11 Jun 2023 12:34:12 +0200
>> Bernhard Beschow  wrote:
>> 
>> > I440FX realization is currently mixed with PIIX3 creation. Furthermore, it 
>> > is
>> > common practice to only set properties between a device's qdev_new() and
>> > qdev_realize(). Clean up to resolve both issues.
>> > 
>> > Since I440FX spawns a PCI bus let's also move the pci_bus initialization 
>> > there.
>> > 
>> > Note that when running `qemu-system-x86_64 -M pc -S` before and after this
>> > patch, `info mtree` in the QEMU console doesn't show any differences 
>> > except that
>> > the ordering is different.
>> > 
>> > Signed-off-by: Bernhard Beschow 
>> > ---
>> >  hw/i386/pc_piix.c | 57 ---
>> >  1 file changed, 29 insertions(+), 28 deletions(-)
>> > 
>> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> > index 22173b122b..23b9725c94 100644
>> > --- a/hw/i386/pc_piix.c
>> > +++ b/hw/i386/pc_piix.c
>> > @@ -126,7 +126,6 @@ static void pc_init1(MachineState *machine,
>> >  MemoryRegion *rom_memory;
>> >  ram_addr_t lowmem;
>> >  uint64_t hole64_size;
>> > -Object *i440fx_host;
>> >  
>> >  /*
>> >   * Calculate ram split, for memory below and above 4G.  It's a bit
>> > @@ -198,17 +197,43 @@ static void pc_init1(MachineState *machine,
>> >  }
>> >  
>> >  if (pcmc->pci_enabled) {
>> > +Object *phb;
>> > +
>> >  pci_memory = g_new(MemoryRegion, 1);
>> >  memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
>> >  rom_memory = pci_memory;
>> > -i440fx_host = OBJECT(qdev_new(host_type));
>> > -hole64_size = object_property_get_uint(i440fx_host,
>> > +
>> > +phb = OBJECT(qdev_new(host_type));
>> > +object_property_add_child(OBJECT(machine), "i440fx", phb);
>> > +object_property_set_link(phb, PCI_HOST_PROP_RAM_MEM,
>> > + OBJECT(ram_memory), &error_fatal);
>> > +object_property_set_link(phb, PCI_HOST_PROP_PCI_MEM,
>> > + OBJECT(pci_memory), &error_fatal);
>> > +object_property_set_link(phb, PCI_HOST_PROP_SYSTEM_MEM,
>> > + OBJECT(system_memory), &error_fatal);
>> > +object_property_set_link(phb, PCI_HOST_PROP_IO_MEM,
>> > + OBJECT(system_io), &error_fatal);
>> > +object_property_set_uint(phb, PCI_HOST_BELOW_4G_MEM_SIZE,
>> > + x86ms->below_4g_mem_size, &error_fatal);
>> > +object_property_set_uint(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
>> > + x86ms->above_4g_mem_size, &error_fatal);
>> > +object_property_set_str(phb, I440FX_HOST_PROP_PCI_TYPE, pci_type,
>> > +&error_fatal);
>> > +sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
>> > +
>> > +pci_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
>> > +pci_bus_map_irqs(pci_bus,
>> > + xen_enabled() ? xen_pci_slot_get_pirq
>> > +   : pc_pci_slot_get_pirq);
>> > +pcms->bus = pci_bus;
>> > +
>> > +hole64_size = object_property_get_uint(phb,
>> > 
>> > PCI_HOST_PROP_PCI_HOLE64_SIZE,
>> > &error_abort);  
>> 
>> before patch memory region links were set after the original
>> regions were initialized by pc_memory_init(), but after this
>> patch you 1st set links and only later pc_memory_init().
>> I doesn't look to me as a safe thing to do.
>
>or maybe it doesn't matter, but still I have hard time
>convincing myself that it is so. 

AFAICS both pc_memory_init() and i440fx_pcihost_realize() rely on 
memory_region_init*() having been called on these pointers already. All they 
seem to do is adding their sub regions. The order in which this happens seems 
to be irrelevant, otherwise we'd see changes in the QOM console calls I guess.

>
>> 
>> >  } else {  
>> 
>> 
>> >  pci_memory = NULL;
>> >  rom_memory = system_memory;
>> > -i440fx_host = NULL;
>> > +pci_bus = NULL;
>> >  hole64_size = 0;  
>> 
>> is it possible to turn these into initializers, and get rid of 
>> 'else'  branch?

Sure, this is possible. I'd add another patch before this one.

Best regards,
Bernhard
>> 
>> >  }
>> >  
>> > @@ -243,29 +268,6 @@ static void pc_init1(MachineState *machine,
>> >  PIIX3State *piix3;
>> >  PCIDevice *pci_dev;
>> >  
>> > -object_property_add_child(OBJECT(machine), "i440fx", i440fx_host);
>> > -object_property_set_link(i440fx_host, PCI_HOST_PROP_RAM_MEM,
>> > - OBJECT(ram_memory), &error_fatal);
>> > -object_property_set_link(i440fx_host

Re: [Libguestfs] [PATCH v4 09/24] nbd: Replace bool structured_reply with mode enum

[Eric Blake]

On Mon, Jun 12, 2023 at 06:07:59PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 08.06.23 16:56, Eric Blake wrote:
> > The upcoming patches for 64-bit extensions requires various points in
> > the protocol to make decisions based on what was negotiated.  While we
> > could easily add a 'bool extended_headers' alongside the existing
> > 'bool structured_reply', this does not scale well if more modes are
> > added in the future.  Better is to expose the mode enum added in the
> > previous patch out to a wider use in the code base.
> > 
> > Where the code previously checked for structured_reply being set or
> > clear, it now prefers checking for an inequality; this works because
> > the nodes are in a continuum of increasing abilities, and allows us to
> > touch fewer places if we ever insert other modes in the middle of the
> > enum.  There should be no semantic change in this patch.
> > 
> > Signed-off-by: Eric Blake 
> > ---
> > 
> > v4: new patch, expanding enum idea from v3 4/14
> > ---
> 
> [..]
> 
> > diff --git a/nbd/server.c b/nbd/server.c
> > index 8486b64b15d..bade4f7990c 100644
> > --- a/nbd/server.c
> > +++ b/nbd/server.c

> > @@ -1261,13 +1262,13 @@ static int nbd_negotiate_options(NBDClient *client, 
> > Error **errp)
> >   case NBD_OPT_STRUCTURED_REPLY:
> >   if (length) {
> >   ret = nbd_reject_length(client, false, errp);
> > -} else if (client->structured_reply) {
> > +} else if (client->mode >= NBD_MODE_STRUCTURED) {
> >   ret = nbd_negotiate_send_rep_err(
> >   client, NBD_REP_ERR_INVALID, errp,
> >   "structured reply already negotiated");
> >   } else {
> >   ret = nbd_negotiate_send_rep(client, NBD_REP_ACK, 
> > errp);
> > -client->structured_reply = true;
> > +client->mode = NBD_MODE_STRUCTURED;
> 
> Hmm. in all other cases in server code client.mode remains zero = OLDSTYLE, 
> which is not quite correct.

Good catch.  Consider this squashed in (note that as a server we NEVER
talk NBD_MODE_OLDSTYLE - we ripped that out back in commit 7f7dfe2a;
but whether we end up on EXPORT_NAME or SIMPLE depends on the client's
response to our initial flag advertisement.  The only reason I didn't
spot it sooner is that in the server, all subsequent checks of
client->mode grouped OLDSTYLE, EXPORT_NAME, and SIMPLE into the same
handling.

diff --git a/nbd/server.c b/nbd/server.c
index bade4f7990c..bc6858cafe6 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1123,10 +1123,12 @@ static int nbd_negotiate_options(NBDClient *client, 
Error **errp)
 if (nbd_read32(client->ioc, &flags, "flags", errp) < 0) {
 return -EIO;
 }
+client->mode = NBD_MODE_EXPORT_NAME;
 trace_nbd_negotiate_options_flags(flags);
 if (flags & NBD_FLAG_C_FIXED_NEWSTYLE) {
 fixedNewstyle = true;
 flags &= ~NBD_FLAG_C_FIXED_NEWSTYLE;
+client->mode = NBD_MODE_SIMPLE;
 }
 if (flags & NBD_FLAG_C_NO_ZEROES) {
 no_zeroes = true;


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [PATCH 11/15] hw/pci-host/i440fx: Add PCI_HOST_PROP_IO_MEM property

[Bernhard Beschow]

Am 12. Juni 2023 10:31:48 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 11/6/23 12:34, Bernhard Beschow wrote:
>> Introduce the property in anticipation of QOM'ification; Q35 has the same
>> property.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   hw/pci-host/i440fx.c | 14 ++
>>   1 file changed, 10 insertions(+), 4 deletions(-)
>
>
>> @@ -51,6 +50,7 @@ struct I440FXState {
>>   /*< public >*/
>> MemoryRegion *system_memory;
>> +MemoryRegion *address_space_io;
>
>"io_mem" like the property? (this is not an AddressSpace)

Agreed. I'd name it "io_memory" to be consistent with above attribute.

Best regards,
Bernhard

>
>>   MemoryRegion *pci_address_space;
>
>(pre-existing misleading name)
>
>>   MemoryRegion *ram_memory;
>>   Range pci_hole;
>

Re: [PATCH 13/16] target/riscv/kvm.c: add multi-letter extension KVM properties

[Daniel Henrique Barboza]

On 6/7/23 08:48, Andrew Jones wrote:

On Tue, May 30, 2023 at 04:46:20PM -0300, Daniel Henrique Barboza wrote:

Let's add KVM user properties for the multi-letter extensions that KVM
currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc,
svinval and svpbmt.

As with the recently added MISA properties we're also going to add a
'user_set' flag in each of them. The flag will be set only if the user
chose an option that's different from the host and will require extra
handling from the KVM driver.

However, multi-letter CPUs have more cases to cover than MISA
extensions, so we're adding an extra 'supported' flag as well. This flag
will reflect if a given extension is supported by KVM, i.e. KVM knows
how to handle it. This is determined during KVM extension discovery in
kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any
other error different from EINVAL will cause an abort.


I wish that was ENOENT, but I suppose that ship sailed.



The 'supported' flag will then be used later on to give an exception for
users that are disabling multi-letter extensions that are unknown to
KVM.

Signed-off-by: Daniel Henrique Barboza 
---
  target/riscv/kvm.c | 136 +
  1 file changed, 136 insertions(+)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index bb1dafe263..b4193a10d8 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -202,6 +202,99 @@ static void kvm_riscv_update_cpu_misa_ext(RISCVCPU *cpu, 
CPUState *cs)
  }
  }
  
+typedef struct RISCVCPUMultiExtConfig {

+const char *name;


No description? I'd prefer we use the same cfg struct for single-letter
and multi-letter extensions. We can use a union to overlap cpu_cfg_offset
and misa_bit.


+int kvm_reg_id;
+int cpu_cfg_offset;
+bool supported;
+bool user_set;
+} RISCVCPUMultiExtConfig;
+
+#define CPUCFG(_prop) offsetof(struct RISCVCPUConfig, _prop)
+
+/*
+ * KVM ISA Multi-letter extensions. We care about the order
+ * since it'll be used to create the ISA string later on.
+ * We follow the same ordering rules of isa_edata_arr[]
+ * from target/riscv/cpu.c.
+ */
+static RISCVCPUMultiExtConfig kvm_multi_ext_cfgs[] = {
+{.name = "zicbom", .kvm_reg_id = KVM_RISCV_ISA_EXT_ZICBOM,
+ .cpu_cfg_offset = CPUCFG(ext_icbom)},
+{.name = "zicboz", .kvm_reg_id = KVM_RISCV_ISA_EXT_ZICBOZ,
+ .cpu_cfg_offset = CPUCFG(ext_icboz)},
+{.name = "zihintpause", .kvm_reg_id = KVM_RISCV_ISA_EXT_ZIHINTPAUSE,
+ .cpu_cfg_offset = CPUCFG(ext_zihintpause)},
+{.name = "zbb", .kvm_reg_id = KVM_RISCV_ISA_EXT_ZBB,
+ .cpu_cfg_offset = CPUCFG(ext_zbb)},
+{.name = "ssaia", .kvm_reg_id = KVM_RISCV_ISA_EXT_SSAIA,
+ .cpu_cfg_offset = CPUCFG(ext_ssaia)},
+{.name = "sstc", .kvm_reg_id = KVM_RISCV_ISA_EXT_SSTC,
+ .cpu_cfg_offset = CPUCFG(ext_sstc)},
+{.name = "svinval", .kvm_reg_id = KVM_RISCV_ISA_EXT_SVINVAL,
+ .cpu_cfg_offset = CPUCFG(ext_svinval)},
+{.name = "svpbmt", .kvm_reg_id = KVM_RISCV_ISA_EXT_SVPBMT,
+ .cpu_cfg_offset = CPUCFG(ext_svpbmt)},


As pointed out in the last patch, it'd be nice to share names (and
descriptions) with TCG.


+};
+
+static void kvm_cpu_cfg_set(RISCVCPU *cpu, RISCVCPUMultiExtConfig *multi_ext,
+uint32_t val)
+{
+int cpu_cfg_offset = multi_ext->cpu_cfg_offset;
+bool *ext_enabled = (void *)&cpu->cfg + cpu_cfg_offset;
+
+*ext_enabled = val;
+}
+
+static uint32_t kvm_cpu_cfg_get(RISCVCPU *cpu,
+RISCVCPUMultiExtConfig *multi_ext)
+{
+int cpu_cfg_offset = multi_ext->cpu_cfg_offset;
+bool *ext_enabled = (void *)&cpu->cfg + cpu_cfg_offset;
+
+return *ext_enabled;
+}
+
+static void kvm_cpu_set_multi_ext_cfg(Object *obj, Visitor *v,
+  const char *name,
+  void *opaque, Error **errp)
+{
+RISCVCPUMultiExtConfig *multi_ext_cfg = opaque;
+RISCVCPU *cpu = RISCV_CPU(obj);
+bool value, host_val;
+
+if (!visit_type_bool(v, name, &value, errp)) {
+return;
+}
+
+host_val = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
+
+/*
+ * Ignore if the user is setting the same value
+ * as the host.
+ */
+if (value == host_val) {
+return;
+}
+
+if (!multi_ext_cfg->supported) {
+/*
+ * Error out if the user is trying to enable an
+ * extension that KVM doesn't support. Ignore
+ * option otherwise.
+ */
+if (value) {
+error_setg(errp, "KVM does not support disabling extension %s",
+   multi_ext_cfg->name);
+}
+
+return;
+}
+
+multi_ext_cfg->user_set = true;
+kvm_cpu_cfg_set(cpu, multi_ext_cfg, value);
+}
+
  static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj)
  {
  int i;
@@ -216,6 +309,15 @@ static void kvm_riscv_add_cpu_user_properties(Object 
*cpu_obj)
  object_property_set_description(cpu_obj

[PATCH] migration.json: Don't use space before colon

[Juan Quintela]

So all the file is consistent.

Signed-off-by: Juan Quintela 
---
 qapi/migration.json | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/qapi/migration.json b/qapi/migration.json
index 179af0c4d8..cb7cd3e578 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -67,13 +67,13 @@
 { 'struct': 'MigrationStats',
   'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
'duplicate': 'int', 'skipped': 'int', 'normal': 'int',
-   'normal-bytes': 'int', 'dirty-pages-rate' : 'int',
-   'mbps' : 'number', 'dirty-sync-count' : 'int',
-   'postcopy-requests' : 'int', 'page-size' : 'int',
-   'multifd-bytes' : 'uint64', 'pages-per-second' : 'uint64',
-   'precopy-bytes' : 'uint64', 'downtime-bytes' : 'uint64',
-   'postcopy-bytes' : 'uint64',
-   'dirty-sync-missed-zero-copy' : 'uint64' } }
+   'normal-bytes': 'int', 'dirty-pages-rate': 'int',
+   'mbps': 'number', 'dirty-sync-count': 'int',
+   'postcopy-requests': 'int', 'page-size': 'int',
+   'multifd-bytes': 'uint64', 'pages-per-second': 'uint64',
+   'precopy-bytes': 'uint64', 'downtime-bytes': 'uint64',
+   'postcopy-bytes': 'uint64',
+   'dirty-sync-missed-zero-copy': 'uint64' } }
 
 ##
 # @XBZRLECacheStats:
@@ -264,7 +264,7 @@
'*cpu-throttle-percentage': 'int',
'*error-desc': 'str',
'*blocked-reasons': ['str'],
-   '*postcopy-blocktime' : 'uint32',
+   '*postcopy-blocktime': 'uint32',
'*postcopy-vcpu-blocktime': ['uint32'],
'*compression': 'CompressionStats',
'*socket-address': ['SocketAddress'] } }
@@ -516,7 +516,7 @@
 # Since: 1.2
 ##
 { 'struct': 'MigrationCapabilityStatus',
-  'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } }
+  'data': { 'capability': 'MigrationCapability', 'state': 'bool' } }
 
 ##
 # @migrate-set-capabilities:
@@ -1567,7 +1567,7 @@
 # Since: 2.9
 ##
 { 'command': 'xen-set-replication',
-  'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' },
+  'data': { 'enable': 'bool', 'primary': 'bool', '*failover': 'bool' },
   'if': 'CONFIG_REPLICATION' }
 
 ##

base-commit: 5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc
prerequisite-patch-id: 99c8bffa9428838925e330eb2881bab476122579
prerequisite-patch-id: 77ba427fd916aeb395e95aa0e7190f84e98e96ab
prerequisite-patch-id: 9983d46fa438d7075a37be883529e37ae41e4228
prerequisite-patch-id: 207f7529924b12dcb57f6557d6db6f79ceb2d682
prerequisite-patch-id: 5ad1799a13845dbf893a28a202b51a6b50d95d90
prerequisite-patch-id: c51959aacd6d65ee84fcd4f1b2aed3dd6f6af879
prerequisite-patch-id: da9dbb6799b2da002c0896574334920097e4c50a
prerequisite-patch-id: c1110ffafbaf5465fb277a20db809372291f7846
prerequisite-patch-id: 8307c92bedd07446214b35b40206eb6793a7384d
prerequisite-patch-id: 0a6106cd4a508d5e700a7ff6c25edfdd03c8ca3d
prerequisite-patch-id: 83205051de22382e75bf4acdf69e59315801fa0d
prerequisite-patch-id: 8c9b3cba89d555c071a410041e6da41806106a7e
prerequisite-patch-id: 0ff62a33b9a242226ccc1f5424a516de803c9fe5
prerequisite-patch-id: 25b8ae1ebe09ace14457c454cfcb23077c37346c
prerequisite-patch-id: 466ea91d5be41fe345dacd4d17bbbe5ce13118c2
prerequisite-patch-id: d1045858f9729ac62eccf2e83ebf95cfebae2cb5
prerequisite-patch-id: 0276ec02073bda5426de39e2f2e81eef080b4f54
prerequisite-patch-id: 7afb4450a163cc1a63ea23831c50214966969131
prerequisite-patch-id: 06c053ce4f41db9675bd1778ae8f6a483641fcef
prerequisite-patch-id: 13ea05d54d741ed08b3bfefa1fc8bedb9c81c782
prerequisite-patch-id: 99c4e2b7101bc8c4b9515129a1bbe6f068053dbf
prerequisite-patch-id: 1e393a196dc7a1ee75f3cc3cebbb591c5422102f
prerequisite-patch-id: 2cf497b41f5024ede0a224b1f5b172226067a534
prerequisite-patch-id: 2a70276ed61d33fc4f3b52560753c05d1cd413be
prerequisite-patch-id: 17ec40f4388b62ba8bf3ac1546c6913f5d1f6079
prerequisite-patch-id: dba969ce9d6cf69c1319661a7d81b1c1c719804d
prerequisite-patch-id: 8d800cda87167314f07320bdb3df936c323e4a40
prerequisite-patch-id: 25d4aaf54ea66f30e426fa38bdd4e0f47303c513
prerequisite-patch-id: 082c9d8584c1daff1e827e44ee3047178e7004a7
prerequisite-patch-id: 0ef73900899425ae2f00751347afdce3739aa954
prerequisite-patch-id: e7db4730b791b71aaf417ee0f65fb6304566aaf8
prerequisite-patch-id: 62d7f28f8196039507ffe362f97723395d7bb704
prerequisite-patch-id: ea8de47bcb54e33bcc67e59e9ed752a4d1fad703
prerequisite-patch-id: 497893ef92e1ea56bd8605e6990a05cb4c7f9293
prerequisite-patch-id: 3dc869c80ee568449bbfa2a9bc427524d0e8970b
prerequisite-patch-id: 52c14b6fb14ed4ccd685385a9fbc6297b762c0ef
prerequisite-patch-id: 23de8371e9e3277c374a47f9bd10de209a22fdd5
prerequisite-patch-id: d21f036dd106af3375fb920bf0a557fe2b86d98e
prerequisite-patch-id: ca717076e9de83d6ce370f7374c4729a9f586fae
prerequisite-patch-id: a235b6ab3237155f2b39e8e10d47ddd250f6b6cc
prerequisite-patch-id: 6db2aa3d8a5804c85dd171864f5140fadf5f72da
prerequisite-patch-id: a799b883f4cb41c34ad074220293f372c

Re: [PATCH v4 06/24] nbd/client: Simplify cookie vs. index computation

[Eric Blake]

On Mon, Jun 12, 2023 at 05:27:19PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 08.06.23 16:56, Eric Blake wrote:
> > Our code relies on a sentinel cookie value of zero for deciding when a
> > packet has been handled, as well as relying on array indices between 0
> > and MAX_NBD_REQUESTS-1 for dereferencing purposes.  As long as we can
> > symmetrically convert between two forms, there is no reason to go with
> > the odd choice of using XOR with a random pointer, when we can instead
> > simplify the mappings with a mere offset of 1.
> 
> Should we go further and use (uint64)-1 as a sentinel cookie value, and just 
> use index as a cookie?  Or, using zero cookie in a wire looks too asymmetric?

I thought about that too, but in the end I decided it would require
auditing more lines of code to make sure I was catching all places
where we currently expected a zero sentinel (where some of those uses
are not obvious, because of things like hiding behind g_new0).  And
there is indeed the argument that if data corruption is going to
happen, it's harder to tell if an all-zero field on the wire was
intentional than a non-zero field.

> 
> > 
> > Signed-off-by: Eric Blake 
> 
> Reviewed-by: Vladimir Sementsov-Ogievskiy 

Thanks; for now, I'll just leave this one as-is.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [PATCH 2/2] hw/char/parallel-isa: Export struct ISAParallelState

[Mark Cave-Ayland]

On 12/06/2023 11:06, BALATON Zoltan wrote:


On Mon, 12 Jun 2023, Bernhard Beschow wrote:

Am 11. Juni 2023 13:15:58 UTC schrieb BALATON Zoltan :

On Sun, 11 Jun 2023, Bernhard Beschow wrote:

Allows the struct to be embedded directly into device models without additional
allocation.

Suggested-by: Mark Cave-Ayland 


Patches missing SoB, checkpatch should have cought this.


Thanks for catching again. Fixed in v2.



I don't see any of the machines or device models actually embedding 
ISAParallelState or ParallelState so don't know what this patch is trying to 
achieve. Please post the whole series with the patches that this is a preparation 
for so we can se where this leads.


No further plans from my side.


Then IMO these patches are not needed. Keeping the struct definitions in parallel.c 
ensures they are not accessed by anything else and keeps the object encapsulation. I 
don't see a point for moving the defs to a header if nothing wants to use them. This 
is done for other devices to allow them to be embedded in other devices but if that's 
not the case here then why this series? (The TYPE_ISA_PARALLEL #define seems to be 
already in include/hw/chsr/parallel.h so if you only want to use that like in the 
series you've referenced in the cover letter then that can be done without these 
patches.)


The TYPE_ISA_PARALLEL constant was only moved there in commit 963e94a97b 
("hw/char/parallel: Move TYPE_ISA_PARALLEL to the header file") but having each 
separate type defined in its own file is how we've done things for some time: there 
is nothing new here.


In particular it is done this way so that ParallelState could be used on a non-ISA 
bus, and to allow users who are security conscious to compile out particular devices 
as needed.



ATB,

Mark.

Re: [PATCH 2/5] cmd646: create separate header and QOM type for CMD646_IDE

[Mark Cave-Ayland]

On 12/06/2023 10:21, Bernhard Beschow wrote:


Am 9. Juni 2023 18:51:16 UTC schrieb Mark Cave-Ayland 
:

This will enable CMD646-specific fields to be added to CMD6464IDEState in
future.

Signed-off-by: Mark Cave-Ayland 
---
hw/ide/cmd646.c |  4 +++-
include/hw/ide/cmd646.h | 38 ++
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 include/hw/ide/cmd646.h

diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index 20f1e41d57..a3e227fba7 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -33,6 +33,7 @@
#include "sysemu/reset.h"

#include "hw/ide/pci.h"
+#include "hw/ide/cmd646.h"
#include "trace.h"

/* CMD646 specific */
@@ -339,9 +340,10 @@ static void cmd646_ide_class_init(ObjectClass *klass, void 
*data)
}

static const TypeInfo cmd646_ide_info = {
-.name  = "cmd646-ide",
+.name  = TYPE_CMD646_IDE,
 .parent= TYPE_PCI_IDE,
 .class_init= cmd646_ide_class_init,
+.instance_size = sizeof(CMD646IDEState),
};

static void cmd646_ide_register_types(void)
diff --git a/include/hw/ide/cmd646.h b/include/hw/ide/cmd646.h
new file mode 100644
index 00..4780b1132c
--- /dev/null
+++ b/include/hw/ide/cmd646.h
@@ -0,0 +1,38 @@
+/*
+ * QEMU IDE Emulation: PCI cmd646 support.
+ *
+ * Copyright (c) 2003 Fabrice Bellard
+ * Copyright (c) 2006 Openedhand Ltd.
+ *
+ * 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.
+ */
+
+#ifndef HW_IDE_CMD646_H
+#define HW_IDE_CMD646_H
+
+#define TYPE_CMD646_IDE "cmd646-ide"
+OBJECT_DECLARE_SIMPLE_TYPE(CMD646IDEState, CMD646_IDE)
+
+#include "hw/ide/pci.h"
+
+struct CMD646IDEState {
+PCIIDEState parent_obj;


No public / private sections here? From the naming this attribute is often 
considered private and the rest public. I guess what this scheme communicates 
is that `parent_obj` should be accessed via `IDE_PCI()` only.


Whilst the public/private comments were included in the original QOM documentation, 
it's not something that tends to be used now. These days people are looking to use 
interfaces such as SysBus to indicated which MemoryRegions and IRQs are "public", but 
certainly the detail is still up for active discussion.


The QOM cast macros will allow the object referenced to be converted to any of the 
parent types directly, so indeed there should be no direct references to parent_obj.



ATB,

Mark.

Re: [PATCH 03/16] target/riscv/cpu.c: restrict 'mvendorid' value

[Daniel Henrique Barboza]

On 6/12/23 00:56, Alistair Francis wrote:

On Wed, May 31, 2023 at 5:49 AM Daniel Henrique Barboza
 wrote:


We're going to change the handling of mvendorid/marchid/mimpid by the
KVM driver. Since these are always present in all CPUs let's put the
same validation for everyone.

It doesn't make sense to allow 'mvendorid' to be different than it
is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have
any 'mvendorid' they want.

Change 'mvendorid' to be a class property created via
'object_class_property_add', instead of using the DEFINE_PROP_UINT32()
macro. This allow us to define a custom setter for it that will verify,
for named CPUs, if mvendorid is different than it is already set by the
CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is
set to an invalid value:

$ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2
qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2:
 Unable to change veyron-v1-riscv-cpu mvendorid (0x61f)


Is this something we want to enforce? What if someone wanted to test
using the veyron-v1 CPU but they wanted to change some properties. I
don't see an advantage in not letting them do that


The idea is to keep things simpler for us. As it is today we forbid users to
enable/disable extensions for vendor CPUs. Doing the same thing for
mvendorid/marchid/mimpid seems consistent with what we're already doing.

Also, guest software might rely on vendor IDs from the CPU to take certain
actions, and if the user is free to change the CPU ID from vendor CPUs the
software will misbehave and the user can claim "I created a veyron-v1 CPU and
the guest it's like like it's not". Allowing mvendorid and friends to be changed
doesn't do much for users (we forbid enabling/disabling extensions, so what's
to gain from changing machine IDs?) and it can be a potential source of bugs.



Thanks,


Daniel




Alistair



Signed-off-by: Daniel Henrique Barboza 
---
  target/riscv/cpu.c | 31 ++-
  1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 72f5433776..bcd69bb032 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -1723,7 +1723,6 @@ static void riscv_cpu_add_user_properties(Object *obj)
  static Property riscv_cpu_properties[] = {
  DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),

-DEFINE_PROP_UINT32("mvendorid", RISCVCPU, cfg.mvendorid, 0),
  DEFINE_PROP_UINT64("marchid", RISCVCPU, cfg.marchid, RISCV_CPU_MARCHID),
  DEFINE_PROP_UINT64("mimpid", RISCVCPU, cfg.mimpid, RISCV_CPU_MIMPID),

@@ -1810,6 +1809,32 @@ static const struct TCGCPUOps riscv_tcg_ops = {
  #endif /* !CONFIG_USER_ONLY */
  };

+static bool riscv_cpu_is_dynamic(Object *cpu_obj)
+{
+return object_dynamic_cast(cpu_obj, TYPE_RISCV_DYNAMIC_CPU) != NULL;
+}
+
+static void cpu_set_mvendorid(Object *obj, Visitor *v, const char *name,
+  void *opaque, Error **errp)
+{
+bool dynamic_cpu = riscv_cpu_is_dynamic(obj);
+RISCVCPU *cpu = RISCV_CPU(obj);
+uint32_t prev_val = cpu->cfg.mvendorid;
+uint32_t value;
+
+if (!visit_type_uint32(v, name, &value, errp)) {
+return;
+}
+
+if (!dynamic_cpu && prev_val != value) {
+error_setg(errp, "Unable to change %s mvendorid (0x%x)",
+   object_get_typename(obj), prev_val);
+return;
+}
+
+cpu->cfg.mvendorid = value;
+}
+
  static void riscv_cpu_class_init(ObjectClass *c, void *data)
  {
  RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
@@ -1841,6 +1866,10 @@ static void riscv_cpu_class_init(ObjectClass *c, void 
*data)
  cc->gdb_get_dynamic_xml = riscv_gdb_get_dynamic_xml;
  cc->tcg_ops = &riscv_tcg_ops;

+object_class_property_add(c, "mvendorid", "uint32", NULL,
+  cpu_set_mvendorid,
+  NULL, NULL);
+
  device_class_set_props(dc, riscv_cpu_properties);
  }

--
2.40.1

Re: [PATCH v2 0/2] Export struct ISAParallelState

[Mark Cave-Ayland]

On 12/06/2023 09:12, Bernhard Beschow wrote:


This series incorporates rebased versions of the ISAParallelState patches of
[1] as requested by Mark.

v2:
* Add forgotten SoB tags (Zoltan, Phil)

Changes since [1]:
* Don't export register definitions (Phil)
* Rephrase commit message of second patch (Zoltan)

[1] https://patchew.org/QEMU/20230521123049.312349-1-shen...@gmail.com/

Bernhard Beschow (2):
   hw/char/parallel: Export struct ParallelState
   hw/char/parallel-isa: Export struct ISAParallelState

  include/hw/char/parallel-isa.h | 46 ++
  include/hw/char/parallel.h | 21 +++-
  hw/char/parallel-isa.c |  1 +
  hw/char/parallel.c | 32 +--
  hw/i386/pc_piix.c  |  2 +-
  hw/i386/pc_q35.c   |  2 +-
  hw/isa/isa-superio.c   |  1 +
  hw/sparc64/sun4u.c |  2 +-
  8 files changed, 72 insertions(+), 35 deletions(-)
  create mode 100644 include/hw/char/parallel-isa.h


Reviewed-by: Mark Cave-Ayland 


ATB,

Mark.

Re: [PATCH V2] migration: file URI

[Peter Xu]

Hi, Steve,

On Wed, Jun 07, 2023 at 11:38:59AM -0700, Steve Sistare wrote:
> Extend the migration URI to support file:.  This can be used for
> any migration scenario that does not require a reverse path.  It can be used
> as an alternative to 'exec:cat > file' in minimized containers that do not
> contain /bin/sh, and it is easier to use than the fd: URI.  It can
> be used in HMP commands, and as a qemu command-line parameter.

I have similar question on the fixed-ram work, on whether we should assume
the vm stopped before doing so.  Again, it leaves us space for
optimizations on top without breaking anyone.

The other thing is considering a very busy guest, migration may not even
converge for "file:" URI (the same to other URIs) but I think that doesn't
make much sense to not converge for a "file:" URI.  The user might be very
confused too.

-- 
Peter Xu

Re: [PULL 26/42] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r

[Mark Cave-Ayland]

On 12/06/2023 16:20, Jonathan Cameron via wrote:


On Tue,  6 Jun 2023 10:47:58 +0100
Peter Maydell  wrote:


From: Richard Henderson 

Round len_align to 16 instead of 8, handling an odd 8-byte as part
of the tail.  Use MO_ATOM_NONE to indicate that all of these memory
ops have only byte atomicity.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
Message-id: 20230530191438.411344-8-richard.hender...@linaro.org
Signed-off-by: Peter Maydell 


Early in debugging but a git bisect pointed at this patch causing:

ERROR:../../tcg/tcg.c:4317:temp_load: code should not be reached
Bail out! ERROR:../../tcg/tcg.c:4317:temp_load: code should not be reached
Aborted

Just after Run /sbin/init arm64 / virt running on an x86 host.
cpu max.

Just reverting this patch results in length check failures.
I reverted as follows


revert: Revert "target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r"
revert: Revert "target/arm: Sink gen_mte_check1 into load/store_exclusive"
revert: Revert "target/arm: Load/store integer pair with one tcg operation"
revert: Revert "target/arm: Hoist finalize_memop out of do_gpr_{ld, st}"
revert: Revert "target/arm: Hoist finalize_memop out of do_fp_{ld, st}"
revert: Revert "target/arm: Pass memop to gen_mte_check1*"
revert: Revert "target/arm: Pass single_memop to gen_mte_checkN"
revert: Revert "target/arm: Check alignment in helper_mte_check"
revert: Revert "target/arm: Add SCTLR.nAA to TBFLAG_A64"
revert: Revert "target/arm: Relax ordered/atomic alignment checks for LSE2"
revert: Revert "target/arm: Move mte check for store-exclusive"

and all is good - obviously that's probably massive overkill.

Jonathan


Could this possibly be the same as 
https://gitlab.com/qemu-project/qemu/-/issues/1704?


ATB,

Mark.

Re: [PATCH][RESEND v5 3/3] Add a Hyper-V Dynamic Memory Protocol driver (hv-balloon)

[David Hildenbrand]

On 12.06.23 16:00, Maciej S. Szmigiero wrote:

From: "Maciej S. Szmigiero" 

This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and inserting pieces of extra RAM
into it on demand from a provided memory backend.

One of advantages of these over ACPI-based PC DIMM hotplug is that such
memory can be hotplugged in much smaller granularity because the ACPI DIMM
slot limit does not apply.

In order to enable hot-adding additional memory a new memory backend needs
to be created and provided to the driver via the "memdev" parameter.
This can be achieved by, for example, adding
"-object memory-backend-ram,id=mem1,size=32G" to the QEMU command line and
then instantiating the driver with "memdev=mem1" parameter.

In contrast with ACPI DIMM hotplug where one can only request to unplug a
whole DIMM stick this driver allows removing memory from guest in single
page (4k) units via ballooning.

The actual resizing is done via ballooning interface (for example, via
the "balloon" HMP command)
This includes resizing the guest past its boot size - that is, hot-adding
additional memory in granularity limited only by the guest alignment
requirements.

After a VM reboot the guest is back to its original (boot) size.

In the future, the guest boot memory size might be changed on reboot
instead, taking into account the effective size that VM had before that
reboot (much like Hyper-V does).

For performance reasons, the guest-released memory is tracked in a few
range trees, as a series of (start, count) ranges.
Each time a new page range is inserted into such tree its neighbors are
checked as candidates for possible merging with it.

Besides performance reasons, the Dynamic Memory protocol itself uses page
ranges as the data structure in its messages, so relevant pages need to be
merged into such ranges anyway.

One has to be careful when tracking the guest-released pages, since the
guest can maliciously report returning pages outside its current address
space, which later clash with the address range of newly added memory.
Similarly, the guest can report freeing the same page twice.

The above design results in much better ballooning performance than when
using virtio-balloon with the same guest: 230 GB / minute with this driver
versus 70 GB / minute with virtio-balloon.

During a ballooning operation most of time is spent waiting for the guest
to come up with newly freed page ranges, processing the received ranges on
the host side (in QEMU and KVM) is nearly instantaneous.

The unballoon operation is also pretty much instantaneous:
thanks to the merging of the ballooned out page ranges 200 GB of memory can
be returned to the guest in about 1 second.
With virtio-balloon this operation takes about 2.5 minutes.

These tests were done against a Windows Server 2019 guest running on a
Xeon E5-2699, after dirtying the whole memory inside guest before each
balloon operation.

Using a range tree instead of a bitmap to track the removed memory also
means that the solution scales well with the guest size: even a 1 TB range
takes just a few bytes of such metadata.

Since the required GTree operations aren't present in every Glib version
a check for them was added to the meson build script, together with new
"--enable-hv-balloon" and "--disable-hv-balloon" configure arguments.
If these GTree operations are missing in the system's Glib version this
driver will be skipped during QEMU build.

An optional "status-report=on" device parameter requests memory status
events from the guest (typically sent every second), which allow the host
to learn both the guest memory available and the guest memory in use
counts.
They are emitted externally as "HV_BALLOON_STATUS_REPORT" QMP events.

The driver is named hv-balloon since the Linux kernel client driver for
the Dynamic Memory Protocol is named as such and to follow the naming
pattern established by the virtio-balloon driver.
The whole protocol runs over Hyper-V VMBus.

The driver was tested against Windows Server 2012 R2, Windows Server 2016
and Windows Server 2019 guests and obeys the guest alignment requirements
reported to the host via DM_CAPABILITIES_REPORT message.

Signed-off-by: Maciej S. Szmigiero 
---
  Kconfig.host  |3 +
  hw/hyperv/Kconfig |5 +
  hw/hyperv/hv-balloon.c| 2040 +
  hw/hyperv/meson.build |1 +
  hw/hyperv/trace-events|   16 +
  meson.build   |   28 +-
  meson_options.txt |2 +
  qapi/machine.json |   25 +
  scripts/meson-buildoptions.sh |3 +
  9 files changed, 2122 insertions(+), 1 deletion(-)
  create mode 100644 hw/hyperv/hv-balloon.c

diff --git a/Kconfig.host b/Kconfig.host
index d763d892693c..2ee71578f38f 100644
--- a/Kconfig.host
+++ b/Kconfig.host
@@ -46,3 +46,6 @@ config FUZZ
  config VFIO_USER_SERVER_ALLOWED
  bool
  imply VFIO_USER_SERVER
+
+config HV_BALLO

Re: Fwd: QEMU AVR Patch - Correct handling of AVR interrupts

[Adecy]

Hello Phil,

I believe I have resolved the problem.

However, I didn't managed to make git send-email work yet. So please find
the patch attached.

Best regards,

Le lun. 12 juin 2023 à 14:53, Philippe Mathieu-Daudé  a
écrit :

> Hi Lucas,
>
> On 8/6/23 23:03, Adecy wrote:
> > -- Forwarded message -
> > De : *Adecy* mailto:ld.ad...@gmail.com>>
> > Date: jeu. 1 juin 2023 à 21:34
> > Subject: QEMU AVR Patch - Correct handling of AVR interrupts
> > To: mailto:qemu-triv...@nongnu.org>>
> >
> >
> > Hello,
> >
> > I would like to submit the attached patch.
>
> Unfortunately your patch doesn't apply cleanly:
>
> Applying: Fix handling of AVR interrupts above 33 by switching ctz32 to
> ctz64
> error: patch failed: target/avr/helper.c:45
> error: target/avr/helper.c: patch does not apply
> Patch failed at 0001 Fix handling of AVR interrupts above 33 by
> switching ctz32 to ctz64
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> You can find help on how to send your patch here:
>
> https://www.qemu.org/docs/master/devel/submitting-a-patch.html#submitting-your-patches
>
> Thanks,
>
> Phil.
>
>


0001-Fix-handling-of-AVR-interrupts-above-33.patch
Description: Binary data

Re: [PATCH v4 11/24] nbd: Add types for extended headers

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

Add the constants and structs necessary for later patches to start
implementing the NBD_OPT_EXTENDED_HEADERS extension in both the client
and server, matching recent upstream nbd.git (through commit
e6f3b94a934).  This patch does not change any existing behavior, but
merely sets the stage for upcoming patches.

This patch does not change the status quo that neither the client nor
server use a packed-struct representation for the request header.
While most of the patch adds new types, there is also some churn for
renaming the existing NBDExtent to NBDExtent32 to contrast it with
NBDExtent64, which I thought was a nicer name than NBDExtentExt.

Signed-off-by: Eric Blake



Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH v4 10/24] nbd/client: Pass mode through to nbd_send_request

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

Once the 64-bit headers extension is enabled, the data layout we send
over the wire for a client request depends on the mode negotiated with
the server.  Rather than adding a parameter to nbd_send_request, we
can add a member to struct NBDRequest, since it already does not
reflect on-wire format.  Some callers initialize it directly; many
others rely on a common initialization point during
nbd_co_send_request().  At this point, there is no semantic change.

Signed-off-by: Eric Blake


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH 15/15] hw/i386/pc_piix: Move i440fx' realize near its qdev_new()

[Igor Mammedov]

On Mon, 12 Jun 2023 16:51:55 +0200
Igor Mammedov  wrote:

> On Sun, 11 Jun 2023 12:34:12 +0200
> Bernhard Beschow  wrote:
> 
> > I440FX realization is currently mixed with PIIX3 creation. Furthermore, it 
> > is
> > common practice to only set properties between a device's qdev_new() and
> > qdev_realize(). Clean up to resolve both issues.
> > 
> > Since I440FX spawns a PCI bus let's also move the pci_bus initialization 
> > there.
> > 
> > Note that when running `qemu-system-x86_64 -M pc -S` before and after this
> > patch, `info mtree` in the QEMU console doesn't show any differences except 
> > that
> > the ordering is different.
> > 
> > Signed-off-by: Bernhard Beschow 
> > ---
> >  hw/i386/pc_piix.c | 57 ---
> >  1 file changed, 29 insertions(+), 28 deletions(-)
> > 
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index 22173b122b..23b9725c94 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -126,7 +126,6 @@ static void pc_init1(MachineState *machine,
> >  MemoryRegion *rom_memory;
> >  ram_addr_t lowmem;
> >  uint64_t hole64_size;
> > -Object *i440fx_host;
> >  
> >  /*
> >   * Calculate ram split, for memory below and above 4G.  It's a bit
> > @@ -198,17 +197,43 @@ static void pc_init1(MachineState *machine,
> >  }
> >  
> >  if (pcmc->pci_enabled) {
> > +Object *phb;
> > +
> >  pci_memory = g_new(MemoryRegion, 1);
> >  memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
> >  rom_memory = pci_memory;
> > -i440fx_host = OBJECT(qdev_new(host_type));
> > -hole64_size = object_property_get_uint(i440fx_host,
> > +
> > +phb = OBJECT(qdev_new(host_type));
> > +object_property_add_child(OBJECT(machine), "i440fx", phb);
> > +object_property_set_link(phb, PCI_HOST_PROP_RAM_MEM,
> > + OBJECT(ram_memory), &error_fatal);
> > +object_property_set_link(phb, PCI_HOST_PROP_PCI_MEM,
> > + OBJECT(pci_memory), &error_fatal);
> > +object_property_set_link(phb, PCI_HOST_PROP_SYSTEM_MEM,
> > + OBJECT(system_memory), &error_fatal);
> > +object_property_set_link(phb, PCI_HOST_PROP_IO_MEM,
> > + OBJECT(system_io), &error_fatal);
> > +object_property_set_uint(phb, PCI_HOST_BELOW_4G_MEM_SIZE,
> > + x86ms->below_4g_mem_size, &error_fatal);
> > +object_property_set_uint(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
> > + x86ms->above_4g_mem_size, &error_fatal);
> > +object_property_set_str(phb, I440FX_HOST_PROP_PCI_TYPE, pci_type,
> > +&error_fatal);
> > +sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
> > +
> > +pci_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
> > +pci_bus_map_irqs(pci_bus,
> > + xen_enabled() ? xen_pci_slot_get_pirq
> > +   : pc_pci_slot_get_pirq);
> > +pcms->bus = pci_bus;
> > +
> > +hole64_size = object_property_get_uint(phb,
> > 
> > PCI_HOST_PROP_PCI_HOLE64_SIZE,
> > &error_abort);  
> 
> before patch memory region links were set after the original
> regions were initialized by pc_memory_init(), but after this
> patch you 1st set links and only later pc_memory_init().
> I doesn't look to me as a safe thing to do.

or maybe it doesn't matter, but still I have hard time
convincing myself that it is so. 

> 
> >  } else {  
> 
> 
> >  pci_memory = NULL;
> >  rom_memory = system_memory;
> > -i440fx_host = NULL;
> > +pci_bus = NULL;
> >  hole64_size = 0;  
> 
> is it possible to turn these into initializers, and get rid of 
> 'else'  branch?
> 
> >  }
> >  
> > @@ -243,29 +268,6 @@ static void pc_init1(MachineState *machine,
> >  PIIX3State *piix3;
> >  PCIDevice *pci_dev;
> >  
> > -object_property_add_child(OBJECT(machine), "i440fx", i440fx_host);
> > -object_property_set_link(i440fx_host, PCI_HOST_PROP_RAM_MEM,
> > - OBJECT(ram_memory), &error_fatal);
> > -object_property_set_link(i440fx_host, PCI_HOST_PROP_PCI_MEM,
> > - OBJECT(pci_memory), &error_fatal);
> > -object_property_set_link(i440fx_host, PCI_HOST_PROP_SYSTEM_MEM,
> > - OBJECT(system_memory), &error_fatal);
> > -object_property_set_link(i440fx_host, PCI_HOST_PROP_IO_MEM,
> > - OBJECT(system_io), &error_fatal);
> > -object_property_set_uint(i440fx_host, PCI_HOST_BELOW_4G_MEM_SIZE,
> > - x86ms->below_4g_mem_size, &error_fatal);
> > 

Re: [PULL 26/42] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r

[Jonathan Cameron via]

On Tue,  6 Jun 2023 10:47:58 +0100
Peter Maydell  wrote:

> From: Richard Henderson 
> 
> Round len_align to 16 instead of 8, handling an odd 8-byte as part
> of the tail.  Use MO_ATOM_NONE to indicate that all of these memory
> ops have only byte atomicity.
> 
> Reviewed-by: Peter Maydell 
> Signed-off-by: Richard Henderson 
> Message-id: 20230530191438.411344-8-richard.hender...@linaro.org
> Signed-off-by: Peter Maydell 

Early in debugging but a git bisect pointed at this patch causing:

ERROR:../../tcg/tcg.c:4317:temp_load: code should not be reached
Bail out! ERROR:../../tcg/tcg.c:4317:temp_load: code should not be reached
Aborted

Just after Run /sbin/init arm64 / virt running on an x86 host.
cpu max.

Just reverting this patch results in length check failures.
I reverted as follows


revert: Revert "target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r"
revert: Revert "target/arm: Sink gen_mte_check1 into load/store_exclusive"
revert: Revert "target/arm: Load/store integer pair with one tcg operation"
revert: Revert "target/arm: Hoist finalize_memop out of do_gpr_{ld, st}"
revert: Revert "target/arm: Hoist finalize_memop out of do_fp_{ld, st}"
revert: Revert "target/arm: Pass memop to gen_mte_check1*"
revert: Revert "target/arm: Pass single_memop to gen_mte_checkN"
revert: Revert "target/arm: Check alignment in helper_mte_check"
revert: Revert "target/arm: Add SCTLR.nAA to TBFLAG_A64"
revert: Revert "target/arm: Relax ordered/atomic alignment checks for LSE2"
revert: Revert "target/arm: Move mte check for store-exclusive"

and all is good - obviously that's probably massive overkill.

Jonathan

> ---
>  target/arm/tcg/translate-sve.c | 95 +-
>  1 file changed, 70 insertions(+), 25 deletions(-)
> 
> diff --git a/target/arm/tcg/translate-sve.c b/target/arm/tcg/translate-sve.c
> index d9d5810ddea..57051a4729a 100644
> --- a/target/arm/tcg/translate-sve.c
> +++ b/target/arm/tcg/translate-sve.c
> @@ -4167,11 +4167,12 @@ TRANS_FEAT(UCVTF_dd, aa64_sve, gen_gvec_fpst_arg_zpz,
>  void gen_sve_ldr(DisasContext *s, TCGv_ptr base, int vofs,
>   int len, int rn, int imm)
>  {
> -int len_align = QEMU_ALIGN_DOWN(len, 8);
> -int len_remain = len % 8;
> -int nparts = len / 8 + ctpop8(len_remain);
> +int len_align = QEMU_ALIGN_DOWN(len, 16);
> +int len_remain = len % 16;
> +int nparts = len / 16 + ctpop8(len_remain);
>  int midx = get_mem_index(s);
>  TCGv_i64 dirty_addr, clean_addr, t0, t1;
> +TCGv_i128 t16;
>  
>  dirty_addr = tcg_temp_new_i64();
>  tcg_gen_addi_i64(dirty_addr, cpu_reg_sp(s, rn), imm);
> @@ -4188,10 +4189,16 @@ void gen_sve_ldr(DisasContext *s, TCGv_ptr base, int 
> vofs,
>  int i;
>  
>  t0 = tcg_temp_new_i64();
> -for (i = 0; i < len_align; i += 8) {
> -tcg_gen_qemu_ld_i64(t0, clean_addr, midx, MO_LEUQ);
> +t1 = tcg_temp_new_i64();
> +t16 = tcg_temp_new_i128();
> +
> +for (i = 0; i < len_align; i += 16) {
> +tcg_gen_qemu_ld_i128(t16, clean_addr, midx,
> + MO_LE | MO_128 | MO_ATOM_NONE);
> +tcg_gen_extr_i128_i64(t0, t1, t16);
>  tcg_gen_st_i64(t0, base, vofs + i);
> -tcg_gen_addi_i64(clean_addr, clean_addr, 8);
> +tcg_gen_st_i64(t1, base, vofs + i + 8);
> +tcg_gen_addi_i64(clean_addr, clean_addr, 16);
>  }
>  } else {
>  TCGLabel *loop = gen_new_label();
> @@ -4200,14 +4207,21 @@ void gen_sve_ldr(DisasContext *s, TCGv_ptr base, int 
> vofs,
>  tcg_gen_movi_ptr(i, 0);
>  gen_set_label(loop);
>  
> -t0 = tcg_temp_new_i64();
> -tcg_gen_qemu_ld_i64(t0, clean_addr, midx, MO_LEUQ);
> -tcg_gen_addi_i64(clean_addr, clean_addr, 8);
> +t16 = tcg_temp_new_i128();
> +tcg_gen_qemu_ld_i128(t16, clean_addr, midx,
> + MO_LE | MO_128 | MO_ATOM_NONE);
> +tcg_gen_addi_i64(clean_addr, clean_addr, 16);
>  
>  tp = tcg_temp_new_ptr();
>  tcg_gen_add_ptr(tp, base, i);
> -tcg_gen_addi_ptr(i, i, 8);
> +tcg_gen_addi_ptr(i, i, 16);
> +
> +t0 = tcg_temp_new_i64();
> +t1 = tcg_temp_new_i64();
> +tcg_gen_extr_i128_i64(t0, t1, t16);
> +
>  tcg_gen_st_i64(t0, tp, vofs);
> +tcg_gen_st_i64(t1, tp, vofs + 8);
>  
>  tcg_gen_brcondi_ptr(TCG_COND_LTU, i, len_align, loop);
>  }
> @@ -4216,6 +4230,16 @@ void gen_sve_ldr(DisasContext *s, TCGv_ptr base, int 
> vofs,
>   * Predicate register loads can be any multiple of 2.
>   * Note that we still store the entire 64-bit unit into cpu_env.
>   */
> +if (len_remain >= 8) {
> +t0 = tcg_temp_new_i64();
> +tcg_gen_qemu_ld_i64(t0, clean_addr, midx, MO_LEUQ | MO_ATOM_NONE);
> +tcg_gen_st_i64(t0, base, vofs + len_align);
> +len_remain -= 8;
> +len_align += 8;
> +if (len_remain) {

Re: [PATCH v4 09/24] nbd: Replace bool structured_reply with mode enum

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

The upcoming patches for 64-bit extensions requires various points in
the protocol to make decisions based on what was negotiated.  While we
could easily add a 'bool extended_headers' alongside the existing
'bool structured_reply', this does not scale well if more modes are
added in the future.  Better is to expose the mode enum added in the
previous patch out to a wider use in the code base.

Where the code previously checked for structured_reply being set or
clear, it now prefers checking for an inequality; this works because
the nodes are in a continuum of increasing abilities, and allows us to
touch fewer places if we ever insert other modes in the middle of the
enum.  There should be no semantic change in this patch.

Signed-off-by: Eric Blake 
---

v4: new patch, expanding enum idea from v3 4/14
---


[..]


diff --git a/nbd/server.c b/nbd/server.c
index 8486b64b15d..bade4f7990c 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -143,7 +143,7 @@ struct NBDClient {

  uint32_t check_align; /* If non-zero, check for aligned client requests */

-bool structured_reply;
+NBDMode mode;
  NBDExportMetaContexts export_meta;

  uint32_t opt; /* Current option being negotiated */
@@ -502,7 +502,7 @@ static int nbd_negotiate_handle_export_name(NBDClient 
*client, bool no_zeroes,
  }

  myflags = client->exp->nbdflags;
-if (client->structured_reply) {
+if (client->mode >= NBD_MODE_STRUCTURED) {
  myflags |= NBD_FLAG_SEND_DF;
  }
  trace_nbd_negotiate_new_style_size_flags(client->exp->size, myflags);
@@ -687,7 +687,7 @@ static int nbd_negotiate_handle_info(NBDClient *client, 
Error **errp)

  /* Send NBD_INFO_EXPORT always */
  myflags = exp->nbdflags;
-if (client->structured_reply) {
+if (client->mode >= NBD_MODE_STRUCTURED) {
  myflags |= NBD_FLAG_SEND_DF;
  }
  trace_nbd_negotiate_new_style_size_flags(exp->size, myflags);
@@ -985,7 +985,8 @@ static int nbd_negotiate_meta_queries(NBDClient *client,
  size_t i;
  size_t count = 0;

-if (client->opt == NBD_OPT_SET_META_CONTEXT && !client->structured_reply) {
+if (client->opt == NBD_OPT_SET_META_CONTEXT &&
+client->mode < NBD_MODE_STRUCTURED) {
  return nbd_opt_invalid(client, errp,
 "request option '%s' when structured reply "
 "is not negotiated",
@@ -1261,13 +1262,13 @@ static int nbd_negotiate_options(NBDClient *client, 
Error **errp)
  case NBD_OPT_STRUCTURED_REPLY:
  if (length) {
  ret = nbd_reject_length(client, false, errp);
-} else if (client->structured_reply) {
+} else if (client->mode >= NBD_MODE_STRUCTURED) {
  ret = nbd_negotiate_send_rep_err(
  client, NBD_REP_ERR_INVALID, errp,
  "structured reply already negotiated");
  } else {
  ret = nbd_negotiate_send_rep(client, NBD_REP_ACK, errp);
-client->structured_reply = true;
+client->mode = NBD_MODE_STRUCTURED;


Hmm. in all other cases in server code client.mode remains zero = OLDSTYLE, 
which is not quite correct.


  }
  break;

@@ -1907,7 +1908,9 @@ static int coroutine_fn 
nbd_co_send_simple_reply(NBDClient *client,
  };

  assert(!len || !nbd_err);
-assert(!client->structured_reply || request->type != NBD_CMD_READ);
+assert(client->mode < NBD_MODE_STRUCTURED ||
+   (client->mode == NBD_MODE_STRUCTURED &&
+request->type != NBD_CMD_READ));
  trace_nbd_co_send_simple_reply(request->cookie, nbd_err,
 nbd_err_lookup(nbd_err), len);
  set_be_simple_reply(&reply, nbd_err, request->cookie);
@@ -2409,7 +2412,7 @@ static int coroutine_fn 
nbd_co_receive_request(NBDRequestData *req, NBDRequest *
client->check_align);
  }
  valid_flags = NBD_CMD_FLAG_FUA;


[..]

--
Best regards,
Vladimir

Re: [PATCH v2] hw/vfio/pci-quirks: Support alternate offset for GPUDirect Cliques

[Alex Williamson]

On Mon, 12 Jun 2023 16:07:33 +0200
Cédric Le Goater  wrote:

> On 6/8/23 20:05, Alex Williamson wrote:
> > NVIDIA Turing and newer GPUs implement the MSI-X capability at the offset
> > previously reserved for use by hypervisors to implement the GPUDirect
> > Cliques capability.  A revised specification provides an alternate
> > location.  Add a config space walk to the quirk to check for conflicts,
> > allowing us to fall back to the new location or generate an error at the
> > quirk setup rather than when the real conflicting capability is added
> > should there be no available location.
> > 
> > Signed-off-by: Alex Williamson 
> > ---
> >   hw/vfio/pci-quirks.c | 41 -
> >   1 file changed, 40 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
> > index f0147a050aaa..0ed2fcd53152 100644
> > --- a/hw/vfio/pci-quirks.c
> > +++ b/hw/vfio/pci-quirks.c
> > @@ -1490,6 +1490,9 @@ void vfio_setup_resetfn_quirk(VFIOPCIDevice *vdev)
> >* +-+-+
> >*
> >* https://lists.gnu.org/archive/html/qemu-devel/2017-08/pdfUda5iEpgOS.pdf
> > + *
> > + * Specification for Turning and later GPU architectures:  
> 
> s/Turning/Turing/
> 
> I will fix that.

Yes, thanks!
 
> > + * https://lists.gnu.org/archive/html/qemu-devel/2023-06/pdf142OR4O4c2.pdf
> >*/
> >   static void get_nv_gpudirect_clique_id(Object *obj, Visitor *v,
> >  const char *name, void *opaque,
> > @@ -1530,7 +1533,9 @@ const PropertyInfo qdev_prop_nv_gpudirect_clique = {
> >   static int vfio_add_nv_gpudirect_cap(VFIOPCIDevice *vdev, Error **errp)
> >   {
> >   PCIDevice *pdev = &vdev->pdev;
> > -int ret, pos = 0xC8;
> > +int ret, pos;
> > +bool c8_conflict = false, d4_conflict = false;
> > +uint8_t tmp;
> >   
> >   if (vdev->nv_gpudirect_clique == 0xFF) {
> >   return 0;
> > @@ -1547,6 +1552,40 @@ static int vfio_add_nv_gpudirect_cap(VFIOPCIDevice 
> > *vdev, Error **errp)
> >   return -EINVAL;
> >   }
> >   
> > +/*
> > + * Per the updated specification above, it's recommended to use offset
> > + * D4h for Turing and later GPU architectures due to a conflict of the
> > + * MSI-X capability at C8h.  We don't know how to determine the GPU  
> 
> There is a way :
> 
># nvidia-smi -q | grep Architecture
>Product Architecture  : Turing

There are a few problems with that:

 1) nvidia-smi is a proprietary tool.

 2) Using nvidia-smi, or even the PCI IDs database, would require
ongoing maintenance to update the string or IDs for future
architectures.

 3) nvidia-smi requires the device to be managed by the nvidia driver,
which becomes and chicken and egg problem when we require the
device to be managed by a vfio compatible driver by this point.

> but it must be vendor specific and the proposed solution is as good.
> 
> Reviewed-by: Cédric Le Goater 

Thanks!

Alex

> > + * architecture, instead we walk the capability chain to mark conflicts
> > + * and choose one or error based on the result.
> > + *
> > + * NB. Cap list head in pdev->config is already cleared, read from 
> > device.
> > + */
> > +ret = pread(vdev->vbasedev.fd, &tmp, 1,
> > +vdev->config_offset + PCI_CAPABILITY_LIST);
> > +if (ret != 1 || !tmp) {
> > +error_setg(errp, "NVIDIA GPUDirect Clique ID: error getting cap 
> > list");
> > +return -EINVAL;
> > +}
> > +
> > +do {
> > +if (tmp == 0xC8) {
> > +c8_conflict = true;
> > +} else if (tmp == 0xD4) {
> > +d4_conflict = true;
> > +}
> > +tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT];
> > +} while (tmp);
> > +
> > +if (!c8_conflict) {
> > +pos = 0xC8;
> > +} else if (!d4_conflict) {
> > +pos = 0xD4;
> > +} else {
> > +error_setg(errp, "NVIDIA GPUDirect Clique ID: invalid config 
> > space");
> > +return -EINVAL;
> > +}
> > +
> >   ret = pci_add_capability(pdev, PCI_CAP_ID_VNDR, pos, 8, errp);
> >   if (ret < 0) {
> >   error_prepend(errp, "Failed to add NVIDIA GPUDirect cap: ");  
> 

Re: [PATCH V9 00/46] Live Update

[Michael Galaxy]

Hi Steve,


On 6/7/23 12:37, Steven Sistare wrote:

On 6/7/2023 11:55 AM, Michael Galaxy wrote:

Another option could be to expose "-migrate-mode-disable" (instead of enable) 
and just enable all 3 modes by default,
since we are already required to switch from "normal" mode to a CPR-specific 
mode when it is time to do a live update,
if the intention is to preserve the capability to completely prevent a running 
QEMU from using these modes
before the VM starts up.

- Michael

On 6/6/23 17:15, Michael Galaxy wrote:

Hi Steve,

In the current design you have, we have to specify both the command line parameter 
"-migrate-mode-enable cpr-reboot"
*and* issue the monitor command "migrate_set_parameter mode cpr-${mode}".

Is it possible to opt-in to the CPR mode just once over the monitor instead of 
having to specify it twice on the command line?
This would also match the live migration model: You do not need to necessarily "opt 
in" to live migration mode through
a command line parameter, you simply request it when you need to. Can CPR 
behave the same way?

This would also make switching over to a CPR-capable version of QEMU much 
simpler and would even make it work for
existing libvirt-managed guests as their command line parameters would no 
longer need to change. This would allow us to
simply power-off and power-on existing VMs to make them CPR-capable and then 
work on a libvirt patch later when
we're ready to do so.


Comments?

Hi Michael,
   Requiring -migrate-enable-mode allows qemu to initialize objects
differently, if necessary, so that migration for a mode is not blocked.
See callers of migrate_mode_enabled.  There is only one so far, in
ram_block_add.  If the mode is cpr-exec, then it creates anonymous ram
blocks using memfd_create, else using MAP_ANON.  In the V7 series, this
was controlled by a '-machine memfd-alloc=on' option.

migrate-enable-mode is more future proof for the user.  If something new must
initialize differently to support cpr, then it adds a call to 
migrate_mode_enabled,
and the command line remains the same.  However, I could be persuaded to go 
either way.



OK, so it is cpr-exec that needs this option (because of ram block 
allocation), not really cpr-reboot.
Could the option then be made to only be required for cpr-exec and not 
cpr-reboot, then,

since cpr-reboot doesn't require that consideration?



A secondary reason for -migrate-enable-mode is to support the only-cpr-capable
option.  It needs to know which mode will be used, in order to check a
mode-specific blocker list.


Still, only-cpr-capable is also optional. If and only if one needs this 
option, the mode could be
specified as part of the option itself, rather than requiring an extra 
command line parameter, no?


Further, in many clouds (including ours), our VM-management is 
generational with the
development of the software versioning, so we *always* run tests and 
know whether or not a VM is CPR-capable.


If it is not CPR-capable, we would never run the VM in the first place, 
which means we would never

really use that option at all.

I do see the appeal of the option, but could we simplify it, since it is 
opt-in?


- Michael




- Steve

Re: [SPAM] [PATCH v3] 9pfs: deprecate 'proxy' backend

[Greg Kurz]

Hi Christian,

On Sat, 10 Jun 2023 15:39:44 +0200
Christian Schoenebeck  wrote:

> As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
> bad shape. Using the 'proxy' backend was already discouraged for safety
> reasons before and we recommended to use the 'local' backend instead,
> but now it is time to officially deprecate the 'proxy' backend.
> 

For the records :

The 'proxy' backend is an old thing that predates vhost-user. It
really turns QEMU into a proxy : all requests go to QEMU, which
forwads them to the helper and the other way around for responses.
Data is copied both ways. All of this severely damages latency.

If someone really wants to offload 9p stuff to a separate process,
they should come up with a vhost-user-9p implementation. The whole
server would be offloaded, possibly sharing most of the code with
the in-QEMU server, QEMU wouldn't be involved anymore in the I/Os.
No more copies.

> Signed-off-by: Christian Schoenebeck 
> ---
>  v2 -> v3:
>  * Fix copy wasted typo (-> 'backend').
> 
>  MAINTAINERS|  7 +++
>  docs/about/deprecated.rst  | 17 +
>  docs/tools/virtfs-proxy-helper.rst |  3 +++
>  fsdev/qemu-fsdev.c |  5 +
>  fsdev/virtfs-proxy-helper.c|  5 +
>  hw/9pfs/9p-proxy.c |  5 +
>  hw/9pfs/9p-proxy.h |  5 +
>  meson.build|  2 +-
>  qemu-options.hx|  6 +-
>  softmmu/vl.c   |  5 +
>  10 files changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 436b3f0afe..185d694b2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2118,13 +2118,20 @@ S: Odd Fixes
>  W: https://wiki.qemu.org/Documentation/9p
>  F: hw/9pfs/
>  X: hw/9pfs/xen-9p*
> +X: hw/9pfs/9p-proxy*
>  F: fsdev/
> +X: fsdev/virtfs-proxy-helper.c
>  F: docs/tools/virtfs-proxy-helper.rst
>  F: tests/qtest/virtio-9p-test.c
>  F: tests/qtest/libqos/virtio-9p*
>  T: git https://gitlab.com/gkurz/qemu.git 9p-next
>  T: git https://github.com/cschoenebeck/qemu.git 9p.next
>  
> +virtio-9p-proxy
> +F: hw/9pfs/9p-proxy*
> +F: fsdev/virtfs-proxy-helper.c
> +S: Obsolete
> +
>  virtio-blk
>  M: Stefan Hajnoczi 
>  L: qemu-bl...@nongnu.org
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 0743459862..9b2c780365 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -343,6 +343,23 @@ the addition of volatile memory support, it is now 
> necessary to distinguish
>  between persistent and volatile memory backends.  As such, memdev is 
> deprecated
>  in favor of persistent-memdev.
>  
> +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
> +^^
> +
> +The 9p ``proxy`` filesystem backend driver has been deprecated and will be
> +removed in a future version of QEMU. Please use ``-fsdev local`` or
> +``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
> +
> +The 9p ``proxy`` backend was originally developed as an alternative to the 9p
> +``local`` backend. The idea was to enhance security by dispatching actual low
> +level filesystem operations from 9p server (QEMU process) over to a separate
> +process (the virtfs-proxy-helper binary). However this alternative never 
> gained
> +momentum. The proxy backend is much slower than the local backend, hasn't 
> seen
> +any development in years, and showed to be less secure, especially due to the
> +fact that its helper daemon must be run as root, whereas with the local 
> backend
> +QEMU is typically run as unprivileged user and allows to tighten behaviour by
> +mapping permissions et al.
> +
>  
>  Block device options
>  
> diff --git a/docs/tools/virtfs-proxy-helper.rst 
> b/docs/tools/virtfs-proxy-helper.rst
> index 6cdeedf8e9..bd310ebb07 100644
> --- a/docs/tools/virtfs-proxy-helper.rst
> +++ b/docs/tools/virtfs-proxy-helper.rst
> @@ -9,6 +9,9 @@ Synopsis
>  Description
>  ---
>  
> +NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
> +removed, along with this daemon, in a future version of QEMU!
> +
>  Pass-through security model in QEMU 9p server needs root privilege to do
>  few file operations (like chown, chmod to any mode/uid:gid).  There are two
>  issues in pass-through security model:
> diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
> index 3da64e9f72..242f54ab49 100644
> --- a/fsdev/qemu-fsdev.c
> +++ b/fsdev/qemu-fsdev.c
> @@ -133,6 +133,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
>  }
>  
>  if (fsdriver) {
> +if (strncmp(fsdriver, "proxy", 5) == 0) {
> +warn_report("'-fsdev proxy' is deprecated, use '-fsdev local' "
> +"instead");
> +}
> +
>  for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
>  if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
>  break;
> diff -

Re: [PATCH v2 03/38] tests/multiarch: Add test-aes

[Alex Bennée]

Richard Henderson  writes:

> Use a shared driver and backends for i386, aarch64, ppc64, riscv64.
>
> Signed-off-by: Richard Henderson 
> ---
>  tests/tcg/aarch64/test-aes.c|  58 
>  tests/tcg/i386/test-aes.c   |  68 +
>  tests/tcg/ppc64/test-aes.c  | 116 +++
>  tests/tcg/riscv64/test-aes.c|  76 ++
>  tests/tcg/multiarch/test-aes-main.c.inc | 183
> 

I find it odd the file with the main function is the c.inc and the per
guest impl's are the plain .c files. Is it possible to have it the other
way around? If we have a fallback library function for aes then we could
enable the test for all targets (a true multiarch test) with some having CPU 
specific
accelerations where available.

But if that's too hard to do:

Acked-by: Alex Bennée 


>  tests/tcg/aarch64/Makefile.target   |   4 +
>  tests/tcg/i386/Makefile.target  |   4 +
>  tests/tcg/ppc64/Makefile.target |   1 +
>  tests/tcg/riscv64/Makefile.target   |   4 +
>  9 files changed, 514 insertions(+)
>  create mode 100644 tests/tcg/aarch64/test-aes.c
>  create mode 100644 tests/tcg/i386/test-aes.c
>  create mode 100644 tests/tcg/ppc64/test-aes.c
>  create mode 100644 tests/tcg/riscv64/test-aes.c
>  create mode 100644 tests/tcg/multiarch/test-aes-main.c.inc
>
> diff --git a/tests/tcg/aarch64/test-aes.c b/tests/tcg/aarch64/test-aes.c
> new file mode 100644
> index 00..2cd324f09b
> --- /dev/null
> +++ b/tests/tcg/aarch64/test-aes.c
> @@ -0,0 +1,58 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include "../multiarch/test-aes-main.c.inc"
> +
> +bool test_SB_SR(uint8_t *o, const uint8_t *i)
> +{
> +/* aese also adds round key, so supply zero. */
> +asm("ld1 { v0.16b }, [%1]\n\t"
> +"movi v1.16b, #0\n\t"
> +"aese v0.16b, v1.16b\n\t"
> +"st1 { v0.16b }, [%0]"
> +: : "r"(o), "r"(i) : "v0", "v1", "memory");
> +return true;
> +}
> +
> +bool test_MC(uint8_t *o, const uint8_t *i)
> +{
> +asm("ld1 { v0.16b }, [%1]\n\t"
> +"aesmc v0.16b, v0.16b\n\t"
> +"st1 { v0.16b }, [%0]"
> +: : "r"(o), "r"(i) : "v0", "memory");
> +return true;
> +}
> +
> +bool test_SB_SR_MC_AK(uint8_t *o, const uint8_t *i, const uint8_t *k)
> +{
> +return false;
> +}
> +
> +bool test_ISB_ISR(uint8_t *o, const uint8_t *i)
> +{
> +/* aesd also adds round key, so supply zero. */
> +asm("ld1 { v0.16b }, [%1]\n\t"
> +"movi v1.16b, #0\n\t"
> +"aesd v0.16b, v1.16b\n\t"
> +"st1 { v0.16b }, [%0]"
> +: : "r"(o), "r"(i) : "v0", "v1", "memory");
> +return true;
> +}
> +
> +bool test_IMC(uint8_t *o, const uint8_t *i)
> +{
> +asm("ld1 { v0.16b }, [%1]\n\t"
> +"aesimc v0.16b, v0.16b\n\t"
> +"st1 { v0.16b }, [%0]"
> +: : "r"(o), "r"(i) : "v0", "memory");
> +return true;
> +}
> +
> +bool test_ISB_ISR_AK_IMC(uint8_t *o, const uint8_t *i, const uint8_t *k)
> +{
> +return false;
> +}
> +
> +bool test_ISB_ISR_IMC_AK(uint8_t *o, const uint8_t *i, const uint8_t *k)
> +{
> +return false;
> +}
> diff --git a/tests/tcg/i386/test-aes.c b/tests/tcg/i386/test-aes.c
> new file mode 100644
> index 00..199395e6cc
> --- /dev/null
> +++ b/tests/tcg/i386/test-aes.c
> @@ -0,0 +1,68 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include "../multiarch/test-aes-main.c.inc"
> +#include 
> +
> +static bool test_SB_SR(uint8_t *o, const uint8_t *i)
> +{
> +__m128i vi = _mm_loadu_si128((const __m128i_u *)i);
> +
> +/* aesenclast also adds round key, so supply zero. */
> +vi = _mm_aesenclast_si128(vi, _mm_setzero_si128());
> +
> +_mm_storeu_si128((__m128i_u *)o, vi);
> +return true;
> +}
> +
> +static bool test_MC(uint8_t *o, const uint8_t *i)
> +{
> +return false;
> +}
> +
> +static bool test_SB_SR_MC_AK(uint8_t *o, const uint8_t *i, const uint8_t *k)
> +{
> +__m128i vi = _mm_loadu_si128((const __m128i_u *)i);
> +__m128i vk = _mm_loadu_si128((const __m128i_u *)k);
> +
> +vi = _mm_aesenc_si128(vi, vk);
> +
> +_mm_storeu_si128((__m128i_u *)o, vi);
> +return true;
> +}
> +
> +static bool test_ISB_ISR(uint8_t *o, const uint8_t *i)
> +{
> +__m128i vi = _mm_loadu_si128((const __m128i_u *)i);
> +
> +/* aesdeclast also adds round key, so supply zero. */
> +vi = _mm_aesdeclast_si128(vi, _mm_setzero_si128());
> +
> +_mm_storeu_si128((__m128i_u *)o, vi);
> +return true;
> +}
> +
> +static bool test_IMC(uint8_t *o, const uint8_t *i)
> +{
> +__m128i vi = _mm_loadu_si128((const __m128i_u *)i);
> +
> +vi = _mm_aesimc_si128(vi);
> +
> +_mm_storeu_si128((__m128i_u *)o, vi);
> +return true;
> +}
> +
> +static bool test_ISB_ISR_AK_IMC(uint8_t *o, const uint8_t *i, const uint8_t 
> *k)
> +{
> +return false;
> +}
> +
> +static bool test_ISB_ISR_IMC_AK(uint8_t *o, const uint8_t *i, const uint8_t 
> *k)
> +{
> +__m128i vi = _mm_loadu_si128((con

Re: [PATCH 15/15] hw/i386/pc_piix: Move i440fx' realize near its qdev_new()

[Igor Mammedov]

On Sun, 11 Jun 2023 12:34:12 +0200
Bernhard Beschow  wrote:

> I440FX realization is currently mixed with PIIX3 creation. Furthermore, it is
> common practice to only set properties between a device's qdev_new() and
> qdev_realize(). Clean up to resolve both issues.
> 
> Since I440FX spawns a PCI bus let's also move the pci_bus initialization 
> there.
> 
> Note that when running `qemu-system-x86_64 -M pc -S` before and after this
> patch, `info mtree` in the QEMU console doesn't show any differences except 
> that
> the ordering is different.
> 
> Signed-off-by: Bernhard Beschow 
> ---
>  hw/i386/pc_piix.c | 57 ---
>  1 file changed, 29 insertions(+), 28 deletions(-)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 22173b122b..23b9725c94 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -126,7 +126,6 @@ static void pc_init1(MachineState *machine,
>  MemoryRegion *rom_memory;
>  ram_addr_t lowmem;
>  uint64_t hole64_size;
> -Object *i440fx_host;
>  
>  /*
>   * Calculate ram split, for memory below and above 4G.  It's a bit
> @@ -198,17 +197,43 @@ static void pc_init1(MachineState *machine,
>  }
>  
>  if (pcmc->pci_enabled) {
> +Object *phb;
> +
>  pci_memory = g_new(MemoryRegion, 1);
>  memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
>  rom_memory = pci_memory;
> -i440fx_host = OBJECT(qdev_new(host_type));
> -hole64_size = object_property_get_uint(i440fx_host,
> +
> +phb = OBJECT(qdev_new(host_type));
> +object_property_add_child(OBJECT(machine), "i440fx", phb);
> +object_property_set_link(phb, PCI_HOST_PROP_RAM_MEM,
> + OBJECT(ram_memory), &error_fatal);
> +object_property_set_link(phb, PCI_HOST_PROP_PCI_MEM,
> + OBJECT(pci_memory), &error_fatal);
> +object_property_set_link(phb, PCI_HOST_PROP_SYSTEM_MEM,
> + OBJECT(system_memory), &error_fatal);
> +object_property_set_link(phb, PCI_HOST_PROP_IO_MEM,
> + OBJECT(system_io), &error_fatal);
> +object_property_set_uint(phb, PCI_HOST_BELOW_4G_MEM_SIZE,
> + x86ms->below_4g_mem_size, &error_fatal);
> +object_property_set_uint(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
> + x86ms->above_4g_mem_size, &error_fatal);
> +object_property_set_str(phb, I440FX_HOST_PROP_PCI_TYPE, pci_type,
> +&error_fatal);
> +sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
> +
> +pci_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
> +pci_bus_map_irqs(pci_bus,
> + xen_enabled() ? xen_pci_slot_get_pirq
> +   : pc_pci_slot_get_pirq);
> +pcms->bus = pci_bus;
> +
> +hole64_size = object_property_get_uint(phb,
> PCI_HOST_PROP_PCI_HOLE64_SIZE,
> &error_abort);

before patch memory region links were set after the original
regions were initialized by pc_memory_init(), but after this
patch you 1st set links and only later pc_memory_init().
I doesn't look to me as a safe thing to do.

>  } else {


>  pci_memory = NULL;
>  rom_memory = system_memory;
> -i440fx_host = NULL;
> +pci_bus = NULL;
>  hole64_size = 0;

is it possible to turn these into initializers, and get rid of 
'else'  branch?

>  }
>  
> @@ -243,29 +268,6 @@ static void pc_init1(MachineState *machine,
>  PIIX3State *piix3;
>  PCIDevice *pci_dev;
>  
> -object_property_add_child(OBJECT(machine), "i440fx", i440fx_host);
> -object_property_set_link(i440fx_host, PCI_HOST_PROP_RAM_MEM,
> - OBJECT(ram_memory), &error_fatal);
> -object_property_set_link(i440fx_host, PCI_HOST_PROP_PCI_MEM,
> - OBJECT(pci_memory), &error_fatal);
> -object_property_set_link(i440fx_host, PCI_HOST_PROP_SYSTEM_MEM,
> - OBJECT(system_memory), &error_fatal);
> -object_property_set_link(i440fx_host, PCI_HOST_PROP_IO_MEM,
> - OBJECT(system_io), &error_fatal);
> -object_property_set_uint(i440fx_host, PCI_HOST_BELOW_4G_MEM_SIZE,
> - x86ms->below_4g_mem_size, &error_fatal);
> -object_property_set_uint(i440fx_host, PCI_HOST_ABOVE_4G_MEM_SIZE,
> - x86ms->above_4g_mem_size, &error_fatal);
> -object_property_set_str(i440fx_host, I440FX_HOST_PROP_PCI_TYPE,
> -pci_type, &error_fatal);
> -sysbus_realize_and_unref(SYS_BUS_DEVICE(i440fx_host), &error_fatal);
> -
> - 

Re: [PATCH v4 08/24] nbd: Use enum for various negotiation modes

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

Deciphering the hard-coded list of integer return values from
nbd_start_negotiate() will only get more confusing when adding support
for 64-bit extended headers.  Better is to name things in an enum.
Although the function in question is private to client.c, putting the
enum in a public header and including an enum-to-string conversion
will allow its use in more places in upcoming patches.

The enum is intentionally laid out so that operators like <= can be
used to group multiple modes with similar characteristics, and where
the least powerful mode has value 0, even though this patch does not
exploit that.  No semantic change intended.

Signed-off-by: Eric Blake



Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH v4 06/24] nbd/client: Simplify cookie vs. index computation

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

Our code relies on a sentinel cookie value of zero for deciding when a
packet has been handled, as well as relying on array indices between 0
and MAX_NBD_REQUESTS-1 for dereferencing purposes.  As long as we can
symmetrically convert between two forms, there is no reason to go with
the odd choice of using XOR with a random pointer, when we can instead
simplify the mappings with a mere offset of 1.


Should we go further and use (uint64)-1 as a sentinel cookie value, and just 
use index as a cookie?  Or, using zero cookie in a wire looks too asymmetric?



Signed-off-by: Eric Blake 


Reviewed-by: Vladimir Sementsov-Ogievskiy 


---

v4: new patch
---
  block/nbd.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index be3c46c6fee..5322e66166c 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -50,8 +50,8 @@
  #define EN_OPTSTR ":exportname="
  #define MAX_NBD_REQUESTS16

-#define COOKIE_TO_INDEX(bs, cookie) ((cookie) ^ (uint64_t)(intptr_t)(bs))
-#define INDEX_TO_COOKIE(bs, index)  ((index)  ^ (uint64_t)(intptr_t)(bs))


That looked like some security trick to hide real indices. But I don't think 
that index of request in a list is a secret information.


+#define COOKIE_TO_INDEX(cookie) ((cookie) - 1)
+#define INDEX_TO_COOKIE(index)  ((index) + 1)



[..]

--
Best regards,
Vladimir

Re: [PATCH v4 05/24] nbd: s/handle/cookie/ to match NBD spec

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

Externally, libnbd exposed the 64-bit opaque marker for each client
NBD packet as the "cookie", because it was less confusing when
contrasted with 'struct nbd_handle *' holding all libnbd state.  It
also avoids confusion between the nown 'handle' as a way to identify a
packet and the verb 'handle' for reacting to things like signals.
Upstream NBD changed their spec to favor the name "cookie" based on
libnbd's recommendations[1], so we can do likewise.

[1]https://github.com/NetworkBlockDevice/nbd/commit/ca4392eb2b

Signed-off-by: Eric Blake


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH v2] hw/vfio/pci-quirks: Support alternate offset for GPUDirect Cliques

[Cédric Le Goater]

On 6/8/23 20:05, Alex Williamson wrote:

NVIDIA Turing and newer GPUs implement the MSI-X capability at the offset
previously reserved for use by hypervisors to implement the GPUDirect
Cliques capability.  A revised specification provides an alternate
location.  Add a config space walk to the quirk to check for conflicts,
allowing us to fall back to the new location or generate an error at the
quirk setup rather than when the real conflicting capability is added
should there be no available location.

Signed-off-by: Alex Williamson 
---
  hw/vfio/pci-quirks.c | 41 -
  1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index f0147a050aaa..0ed2fcd53152 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -1490,6 +1490,9 @@ void vfio_setup_resetfn_quirk(VFIOPCIDevice *vdev)
   * +-+-+
   *
   * https://lists.gnu.org/archive/html/qemu-devel/2017-08/pdfUda5iEpgOS.pdf
+ *
+ * Specification for Turning and later GPU architectures:


s/Turning/Turing/

I will fix that.


+ * https://lists.gnu.org/archive/html/qemu-devel/2023-06/pdf142OR4O4c2.pdf
   */
  static void get_nv_gpudirect_clique_id(Object *obj, Visitor *v,
 const char *name, void *opaque,
@@ -1530,7 +1533,9 @@ const PropertyInfo qdev_prop_nv_gpudirect_clique = {
  static int vfio_add_nv_gpudirect_cap(VFIOPCIDevice *vdev, Error **errp)
  {
  PCIDevice *pdev = &vdev->pdev;
-int ret, pos = 0xC8;
+int ret, pos;
+bool c8_conflict = false, d4_conflict = false;
+uint8_t tmp;
  
  if (vdev->nv_gpudirect_clique == 0xFF) {

  return 0;
@@ -1547,6 +1552,40 @@ static int vfio_add_nv_gpudirect_cap(VFIOPCIDevice 
*vdev, Error **errp)
  return -EINVAL;
  }
  
+/*

+ * Per the updated specification above, it's recommended to use offset
+ * D4h for Turing and later GPU architectures due to a conflict of the
+ * MSI-X capability at C8h.  We don't know how to determine the GPU


There is a way :

  # nvidia-smi -q | grep Architecture
  Product Architecture  : Turing

but it must be vendor specific and the proposed solution is as good.

Reviewed-by: Cédric Le Goater 

Thanks,

C.


+ * architecture, instead we walk the capability chain to mark conflicts
+ * and choose one or error based on the result.
+ *
+ * NB. Cap list head in pdev->config is already cleared, read from device.
+ */
+ret = pread(vdev->vbasedev.fd, &tmp, 1,
+vdev->config_offset + PCI_CAPABILITY_LIST);
+if (ret != 1 || !tmp) {
+error_setg(errp, "NVIDIA GPUDirect Clique ID: error getting cap list");
+return -EINVAL;
+}
+
+do {
+if (tmp == 0xC8) {
+c8_conflict = true;
+} else if (tmp == 0xD4) {
+d4_conflict = true;
+}
+tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT];
+} while (tmp);
+
+if (!c8_conflict) {
+pos = 0xC8;
+} else if (!d4_conflict) {
+pos = 0xD4;
+} else {
+error_setg(errp, "NVIDIA GPUDirect Clique ID: invalid config space");
+return -EINVAL;
+}
+
  ret = pci_add_capability(pdev, PCI_CAP_ID_VNDR, pos, 8, errp);
  if (ret < 0) {
  error_prepend(errp, "Failed to add NVIDIA GPUDirect cap: ");

[PATCH][RESEND v5 3/3] Add a Hyper-V Dynamic Memory Protocol driver (hv-balloon)

[Maciej S. Szmigiero]

From: "Maciej S. Szmigiero" 

This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and inserting pieces of extra RAM
into it on demand from a provided memory backend.

One of advantages of these over ACPI-based PC DIMM hotplug is that such
memory can be hotplugged in much smaller granularity because the ACPI DIMM
slot limit does not apply.

In order to enable hot-adding additional memory a new memory backend needs
to be created and provided to the driver via the "memdev" parameter.
This can be achieved by, for example, adding
"-object memory-backend-ram,id=mem1,size=32G" to the QEMU command line and
then instantiating the driver with "memdev=mem1" parameter.

In contrast with ACPI DIMM hotplug where one can only request to unplug a
whole DIMM stick this driver allows removing memory from guest in single
page (4k) units via ballooning.

The actual resizing is done via ballooning interface (for example, via
the "balloon" HMP command)
This includes resizing the guest past its boot size - that is, hot-adding
additional memory in granularity limited only by the guest alignment
requirements.

After a VM reboot the guest is back to its original (boot) size.

In the future, the guest boot memory size might be changed on reboot
instead, taking into account the effective size that VM had before that
reboot (much like Hyper-V does).

For performance reasons, the guest-released memory is tracked in a few
range trees, as a series of (start, count) ranges.
Each time a new page range is inserted into such tree its neighbors are
checked as candidates for possible merging with it.

Besides performance reasons, the Dynamic Memory protocol itself uses page
ranges as the data structure in its messages, so relevant pages need to be
merged into such ranges anyway.

One has to be careful when tracking the guest-released pages, since the
guest can maliciously report returning pages outside its current address
space, which later clash with the address range of newly added memory.
Similarly, the guest can report freeing the same page twice.

The above design results in much better ballooning performance than when
using virtio-balloon with the same guest: 230 GB / minute with this driver
versus 70 GB / minute with virtio-balloon.

During a ballooning operation most of time is spent waiting for the guest
to come up with newly freed page ranges, processing the received ranges on
the host side (in QEMU and KVM) is nearly instantaneous.

The unballoon operation is also pretty much instantaneous:
thanks to the merging of the ballooned out page ranges 200 GB of memory can
be returned to the guest in about 1 second.
With virtio-balloon this operation takes about 2.5 minutes.

These tests were done against a Windows Server 2019 guest running on a
Xeon E5-2699, after dirtying the whole memory inside guest before each
balloon operation.

Using a range tree instead of a bitmap to track the removed memory also
means that the solution scales well with the guest size: even a 1 TB range
takes just a few bytes of such metadata.

Since the required GTree operations aren't present in every Glib version
a check for them was added to the meson build script, together with new
"--enable-hv-balloon" and "--disable-hv-balloon" configure arguments.
If these GTree operations are missing in the system's Glib version this
driver will be skipped during QEMU build.

An optional "status-report=on" device parameter requests memory status
events from the guest (typically sent every second), which allow the host
to learn both the guest memory available and the guest memory in use
counts.
They are emitted externally as "HV_BALLOON_STATUS_REPORT" QMP events.

The driver is named hv-balloon since the Linux kernel client driver for
the Dynamic Memory Protocol is named as such and to follow the naming
pattern established by the virtio-balloon driver.
The whole protocol runs over Hyper-V VMBus.

The driver was tested against Windows Server 2012 R2, Windows Server 2016
and Windows Server 2019 guests and obeys the guest alignment requirements
reported to the host via DM_CAPABILITIES_REPORT message.

Signed-off-by: Maciej S. Szmigiero 
---
 Kconfig.host  |3 +
 hw/hyperv/Kconfig |5 +
 hw/hyperv/hv-balloon.c| 2040 +
 hw/hyperv/meson.build |1 +
 hw/hyperv/trace-events|   16 +
 meson.build   |   28 +-
 meson_options.txt |2 +
 qapi/machine.json |   25 +
 scripts/meson-buildoptions.sh |3 +
 9 files changed, 2122 insertions(+), 1 deletion(-)
 create mode 100644 hw/hyperv/hv-balloon.c

diff --git a/Kconfig.host b/Kconfig.host
index d763d892693c..2ee71578f38f 100644
--- a/Kconfig.host
+++ b/Kconfig.host
@@ -46,3 +46,6 @@ config FUZZ
 config VFIO_USER_SERVER_ALLOWED
 bool
 imply VFIO_USER_SERVER
+
+config HV_BALLOON_POSSIBLE
+bool
diff --git a/hw/hyperv/Kconfig b/hw/hype

[PATCH][RESEND v5 1/3] error: define g_autoptr() cleanup function for the Error type

[Maciej S. Szmigiero]

From: "Maciej S. Szmigiero" 

Used by the hv-balloon driver for automatic memory management.

Signed-off-by: Maciej S. Szmigiero 
---
 include/qapi/error.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index f21a231bb1a6..b0b1838e3e93 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -437,6 +437,8 @@ Error *error_copy(const Error *err);
  */
 void error_free(Error *err);
 
+G_DEFINE_AUTOPTR_CLEANUP_FUNC(Error, error_free)
+
 /*
  * Convenience function to assert that *@errp is set, then silently free it.
  */

[PATCH][RESEND v5 2/3] Add Hyper-V Dynamic Memory Protocol definitions

[Maciej S. Szmigiero]

From: "Maciej S. Szmigiero" 

This commit adds Hyper-V Dynamic Memory Protocol definitions, taken
from hv_balloon Linux kernel driver, adapted to the QEMU coding style and
definitions.

Signed-off-by: Maciej S. Szmigiero 
---
 include/hw/hyperv/dynmem-proto.h | 423 +++
 1 file changed, 423 insertions(+)
 create mode 100644 include/hw/hyperv/dynmem-proto.h

diff --git a/include/hw/hyperv/dynmem-proto.h b/include/hw/hyperv/dynmem-proto.h
new file mode 100644
index ..d0f9090ac489
--- /dev/null
+++ b/include/hw/hyperv/dynmem-proto.h
@@ -0,0 +1,423 @@
+#ifndef HW_HYPERV_DYNMEM_PROTO_H
+#define HW_HYPERV_DYNMEM_PROTO_H
+
+/*
+ * Hyper-V Dynamic Memory Protocol definitions
+ *
+ * Copyright (C) 2020-2023 Oracle and/or its affiliates.
+ *
+ * Based on drivers/hv/hv_balloon.c from Linux kernel:
+ * Copyright (c) 2012, Microsoft Corporation.
+ *
+ * Author: K. Y. Srinivasan 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ * See the COPYING file in the top-level directory.
+ */
+
+/*
+ * Protocol versions. The low word is the minor version, the high word the 
major
+ * version.
+ *
+ * History:
+ * Initial version 1.0
+ * Changed to 0.1 on 2009/03/25
+ * Changes to 0.2 on 2009/05/14
+ * Changes to 0.3 on 2009/12/03
+ * Changed to 1.0 on 2011/04/05
+ * Changed to 2.0 on 2019/12/10
+ */
+
+#define DYNMEM_MAKE_VERSION(Major, Minor) ((uint32_t)(((Major) << 16) | 
(Minor)))
+#define DYNMEM_MAJOR_VERSION(Version) ((uint32_t)(Version) >> 16)
+#define DYNMEM_MINOR_VERSION(Version) ((uint32_t)(Version) & 0xff)
+
+enum {
+DYNMEM_PROTOCOL_VERSION_1 = DYNMEM_MAKE_VERSION(0, 3),
+DYNMEM_PROTOCOL_VERSION_2 = DYNMEM_MAKE_VERSION(1, 0),
+DYNMEM_PROTOCOL_VERSION_3 = DYNMEM_MAKE_VERSION(2, 0),
+
+DYNMEM_PROTOCOL_VERSION_WIN7 = DYNMEM_PROTOCOL_VERSION_1,
+DYNMEM_PROTOCOL_VERSION_WIN8 = DYNMEM_PROTOCOL_VERSION_2,
+DYNMEM_PROTOCOL_VERSION_WIN10 = DYNMEM_PROTOCOL_VERSION_3,
+
+DYNMEM_PROTOCOL_VERSION_CURRENT = DYNMEM_PROTOCOL_VERSION_WIN10
+};
+
+
+
+/*
+ * Message Types
+ */
+
+enum dm_message_type {
+/*
+ * Version 0.3
+ */
+DM_ERROR = 0,
+DM_VERSION_REQUEST = 1,
+DM_VERSION_RESPONSE = 2,
+DM_CAPABILITIES_REPORT = 3,
+DM_CAPABILITIES_RESPONSE = 4,
+DM_STATUS_REPORT = 5,
+DM_BALLOON_REQUEST = 6,
+DM_BALLOON_RESPONSE = 7,
+DM_UNBALLOON_REQUEST = 8,
+DM_UNBALLOON_RESPONSE = 9,
+DM_MEM_HOT_ADD_REQUEST = 10,
+DM_MEM_HOT_ADD_RESPONSE = 11,
+DM_VERSION_03_MAX = 11,
+/*
+ * Version 1.0.
+ */
+DM_INFO_MESSAGE = 12,
+DM_VERSION_1_MAX = 12,
+
+/*
+ * Version 2.0
+ */
+DM_MEM_HOT_REMOVE_REQUEST = 13,
+DM_MEM_HOT_REMOVE_RESPONSE = 14
+};
+
+
+/*
+ * Structures defining the dynamic memory management
+ * protocol.
+ */
+
+union dm_version {
+struct {
+uint16_t minor_version;
+uint16_t major_version;
+};
+uint32_t version;
+} QEMU_PACKED;
+
+
+union dm_caps {
+struct {
+uint64_t balloon:1;
+uint64_t hot_add:1;
+/*
+ * To support guests that may have alignment
+ * limitations on hot-add, the guest can specify
+ * its alignment requirements; a value of n
+ * represents an alignment of 2^n in mega bytes.
+ */
+uint64_t hot_add_alignment:4;
+uint64_t hot_remove:1;
+uint64_t reservedz:57;
+} cap_bits;
+uint64_t caps;
+} QEMU_PACKED;
+
+union dm_mem_page_range {
+struct  {
+/*
+ * The PFN number of the first page in the range.
+ * 40 bits is the architectural limit of a PFN
+ * number for AMD64.
+ */
+uint64_t start_page:40;
+/*
+ * The number of pages in the range.
+ */
+uint64_t page_cnt:24;
+} finfo;
+uint64_t  page_range;
+} QEMU_PACKED;
+
+
+
+/*
+ * The header for all dynamic memory messages:
+ *
+ * type: Type of the message.
+ * size: Size of the message in bytes; including the header.
+ * trans_id: The guest is responsible for manufacturing this ID.
+ */
+
+struct dm_header {
+uint16_t type;
+uint16_t size;
+uint32_t trans_id;
+} QEMU_PACKED;
+
+/*
+ * A generic message format for dynamic memory.
+ * Specific message formats are defined later in the file.
+ */
+
+struct dm_message {
+struct dm_header hdr;
+uint8_t data[]; /* enclosed message */
+} QEMU_PACKED;
+
+
+/*
+ * Specific message types supporting the dynamic memory protocol.
+ */
+
+/*
+ * Version negotiation message. Sent from the guest to the host.
+ * The guest is free to try different versions until the host
+ * accepts the version.
+ *
+ * dm_version: The protocol version requested.
+ * is_last_attempt: If TRUE, this is the last version guest will request.
+ * reservedz: Reserved field, set to zero.
+ */
+
+struct dm_version_request {
+struct dm_header hdr;
+union dm_version version;
+uint32_t is_last_attempt:1;
+uint32_t reservedz:31;
+} 

[PATCH][RESEND v5 0/3] Hyper-V Dynamic Memory Protocol driver (hv-balloon 🎈️)

[Maciej S. Szmigiero]

From: "Maciej S. Szmigiero" 

This is almost a pure rebase/resend of the v4 of patch series located here:
https://lore.kernel.org/qemu-devel/cover.1682584770.git.maciej.szmigi...@oracle.com/

The only other change from the previous version is that the check for the
required Glib's GTree operations was moved from the configure script to the
meson build script in keeping with the spirit of the times (and the driver
was re-tested too).

 Kconfig.host |3 +
 hw/hyperv/Kconfig|5 +
 hw/hyperv/hv-balloon.c   | 2040 ++
 hw/hyperv/meson.build|1 +
 hw/hyperv/trace-events   |   16 +
 include/hw/hyperv/dynmem-proto.h |  423 +++
 include/qapi/error.h |2 +
 meson.build  |   28 +-
 meson_options.txt|2 +
 qapi/machine.json|   25 +
 scripts/meson-buildoptions.sh|3 +
 11 files changed, 2547 insertions(+), 1 deletion(-)
 create mode 100644 hw/hyperv/hv-balloon.c
 create mode 100644 include/hw/hyperv/dynmem-proto.h

Re: [PATCH 07/15] hw/pci-host/i440fx: Replace magic values by existing constants

[Igor Mammedov]

On Sun, 11 Jun 2023 12:34:04 +0200
Bernhard Beschow  wrote:

> Signed-off-by: Bernhard Beschow 

Reviewed-by: Igor Mammedov 

> ---
>  hw/pci-host/i440fx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
> index 61e7b97ff4..daa4d11104 100644
> --- a/hw/pci-host/i440fx.c
> +++ b/hw/pci-host/i440fx.c
> @@ -277,8 +277,8 @@ PCIBus *i440fx_init(const char *pci_type,
>  
>  /* if *disabled* show SMRAM to all CPUs */
>  memory_region_init_alias(&f->smram_region, OBJECT(d), "smram-region",
> - f->pci_address_space, 0xa, 0x2);
> -memory_region_add_subregion_overlap(f->system_memory, 0xa,
> + f->pci_address_space, SMRAM_C_BASE, 
> SMRAM_C_SIZE);
> +memory_region_add_subregion_overlap(f->system_memory, SMRAM_C_BASE,
>  &f->smram_region, 1);
>  memory_region_set_enabled(&f->smram_region, true);
>  
> @@ -286,9 +286,9 @@ PCIBus *i440fx_init(const char *pci_type,
>  memory_region_init(&f->smram, OBJECT(d), "smram", 4 * GiB);
>  memory_region_set_enabled(&f->smram, true);
>  memory_region_init_alias(&f->low_smram, OBJECT(d), "smram-low",
> - f->ram_memory, 0xa, 0x2);
> + f->ram_memory, SMRAM_C_BASE, SMRAM_C_SIZE);
>  memory_region_set_enabled(&f->low_smram, true);
> -memory_region_add_subregion(&f->smram, 0xa, &f->low_smram);
> +memory_region_add_subregion(&f->smram, SMRAM_C_BASE, &f->low_smram);
>  object_property_add_const_link(qdev_get_machine(), "smram",
> OBJECT(&f->smram));
>  

Re: [PATCH v4 03/24] nbd/server: Prepare for alternate-size headers

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 16:56, Eric Blake wrote:

Upstream NBD now documents[1] an extension that supports 64-bit effect
lengths in requests.  As part of that extension, the size of the reply
headers will change in order to permit a 64-bit length in the reply
for symmetry[2].  Additionally, where the reply header is currently 16
bytes for simple reply, and 20 bytes for structured reply; with the
extension enabled, there will only be one extended reply header, of 32
bytes, with both structured and extended modes sending identical
payloads for chunked replies.

Since we are already wired up to use iovecs, it is easiest to allow
for this change in header size by splitting each structured reply
across multiple iovecs, one for the header (which will become wider in
a future patch according to client negotiation), and the other(s) for
the chunk payload, and removing the header from the payload struct
definitions.  Rename the affected functions with s/structured/chunk/
to make it obvious that the code will be reused in extended mode.

Interestingly, the client side code never utilized the packed types,
so only the server code needs to be updated.

[1]https://github.com/NetworkBlockDevice/nbd/blob/extension-ext-header/doc/proto.md
as of NBD commit e6f3b94a934

[2] Note that on the surface, this is because some future server might
permit a 4G+ NBD_CMD_READ and need to reply with that much data in one
transaction.  But even though the extended reply length is widened to
64 bits, for now the NBD spec is clear that servers will not reply
with more than a maximum payload bounded by the 32-bit
NBD_INFO_BLOCK_SIZE field; allowing a client and server to mutually
agree to transactions larger than 4G would require yet another
extension.

Signed-off-by: Eric Blake


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH 05/15] hw/pci-host/q35: Initialize PCI_HOST_BYPASS_IOMMU property from board code

[Igor Mammedov]

On Sun, 11 Jun 2023 12:34:02 +0200
Bernhard Beschow  wrote:

> The Q35 PCI host already has a PCI_HOST_BYPASS_IOMMU property. However, the
> host initializes this property itself by accessing global machine state,
> thereby assuming it to be a PC machine. Avoid this by having board code
> set this property.
> 
> Signed-off-by: Bernhard Beschow 

Reviewed-by: Igor Mammedov 

> ---
>  hw/i386/pc_q35.c  | 2 ++
>  hw/pci-host/q35.c | 3 +--
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 29b46d3e1c..5220b535b2 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -230,6 +230,8 @@ static void pc_q35_init(MachineState *machine)
>  x86ms->below_4g_mem_size, NULL);
>  object_property_set_int(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
>  x86ms->above_4g_mem_size, NULL);
> +object_property_set_bool(phb, PCI_HOST_BYPASS_IOMMU,
> + pcms->default_bus_bypass_iommu, NULL);
>  sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
>  
>  /* pci */
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 23b689dba3..7980ddde69 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -66,8 +66,7 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
>  s->mch.pci_address_space,
>  s->mch.address_space_io,
>  0, TYPE_PCIE_BUS);
> -pci->bypass_iommu =
> -PC_MACHINE(qdev_get_machine())->default_bus_bypass_iommu;
> +
>  qdev_realize(DEVICE(&s->mch), BUS(pci->bus), &error_fatal);
>  }
>  

Re: [PATCH 04/15] hw/pci/pci_host: Introduce PCI_HOST_BYPASS_IOMMU macro

[Igor Mammedov]

On Sun, 11 Jun 2023 12:34:01 +0200
Bernhard Beschow  wrote:

> Introduce a macro to avoid copy and pasting strings which can easily
> cause typos.
> 
> Suggested-by: Michael S. Tsirkin 
> Signed-off-by: Bernhard Beschow 

Reviewed-by: Igor Mammedov 

> ---
>  include/hw/pci/pci_host.h | 2 ++
>  hw/pci/pci_host.c | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/hw/pci/pci_host.h b/include/hw/pci/pci_host.h
> index c6f4eb4585..e52d8ec2cd 100644
> --- a/include/hw/pci/pci_host.h
> +++ b/include/hw/pci/pci_host.h
> @@ -31,6 +31,8 @@
>  #include "hw/sysbus.h"
>  #include "qom/object.h"
>  
> +#define PCI_HOST_BYPASS_IOMMU "bypass-iommu"
> +
>  #define TYPE_PCI_HOST_BRIDGE "pci-host-bridge"
>  OBJECT_DECLARE_TYPE(PCIHostState, PCIHostBridgeClass, PCI_HOST_BRIDGE)
>  
> diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c
> index dfd185bbb4..7af8afdcbe 100644
> --- a/hw/pci/pci_host.c
> +++ b/hw/pci/pci_host.c
> @@ -232,7 +232,7 @@ const VMStateDescription vmstate_pcihost = {
>  static Property pci_host_properties_common[] = {
>  DEFINE_PROP_BOOL("x-config-reg-migration-enabled", PCIHostState,
>   mig_enabled, true),
> -DEFINE_PROP_BOOL("bypass-iommu", PCIHostState, bypass_iommu, false),
> +DEFINE_PROP_BOOL(PCI_HOST_BYPASS_IOMMU, PCIHostState, bypass_iommu, 
> false),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  

Re: [PATCH 03/15] hw/pci-host/q35: Initialize PCMachineState::bus in board code

[Igor Mammedov]

On Sun, 11 Jun 2023 12:34:00 +0200
Bernhard Beschow  wrote:

> The Q35 PCI host currently sets the PC machine's PCI bus attribute
> through global state, thereby assuming the machine to be a PC machine.
> The Q35 machine code already holds on to Q35's pci bus attribute, so can
> easily set its own property while preserving encapsulation.
> 
> Signed-off-by: Bernhard Beschow 

Reviewed-by: Igor Mammedov 

> ---
>  hw/i386/pc_q35.c  | 4 +++-
>  hw/pci-host/q35.c | 1 -
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 62c5d652b7..29b46d3e1c 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -230,10 +230,12 @@ static void pc_q35_init(MachineState *machine)
>  x86ms->below_4g_mem_size, NULL);
>  object_property_set_int(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
>  x86ms->above_4g_mem_size, NULL);
> +sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
>  
>  /* pci */
> -sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
>  host_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pcie.0"));
> +pcms->bus = host_bus;
> +
>  /* create ISA bus */
>  lpc = pci_new_multifunction(PCI_DEVFN(ICH9_LPC_DEV, ICH9_LPC_FUNC), true,
>  TYPE_ICH9_LPC_DEVICE);
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 859c197f25..23b689dba3 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -66,7 +66,6 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
>  s->mch.pci_address_space,
>  s->mch.address_space_io,
>  0, TYPE_PCIE_BUS);
> -PC_MACHINE(qdev_get_machine())->bus = pci->bus;
>  pci->bypass_iommu =
>  PC_MACHINE(qdev_get_machine())->default_bus_bypass_iommu;
>  qdev_realize(DEVICE(&s->mch), BUS(pci->bus), &error_fatal);

Re: [PATCH] coroutine-asm: add x86 CET shadow stack support

[Marc-André Lureau]

Hi Paolo

On Wed, May 10, 2023 at 6:05 PM Paolo Bonzini  wrote:

> Signed-off-by: Paolo Bonzini 
>

patch looks generally good, but does not apply anymore.

Are you planning to update it later to support the more secure "
map_shadow_stack" syscall, if/when it is added?

---
>  meson.build  | 16 +++--
>  util/coroutine-asm.c | 82 ++--
>  2 files changed, 93 insertions(+), 5 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0121ccab78dd..17e4a3bc582e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -328,6 +328,10 @@ elif coroutine_backend not in supported_backends
>  .format(coroutine_backend, ', '.join(supported_backends)))
>  endif
>
> +if cfi_mode == 'hw' and coroutine_backend != 'asm'
> +  error('Hardware control-flow integrity requires the "asm" coroutine
> backend.')
> +endif
> +
>  # Compiles if SafeStack *not* enabled
>  safe_stack_probe = '''
>int main(void)
> @@ -469,16 +473,22 @@ if cfi_mode == 'sw'
>  endif
>endif
>  elif cfi_mode in ['hw', 'auto']
> -  if cfi_mode == 'hw'
> -error('Hardware CFI is not supported yet')
> +  if cpu in ['x86', 'x86_64']
> +cfi_flags += cc.get_supported_arguments('-fcf-protection=full')
> +if cfi_mode == 'hw'
> +  error('C compiler does not support -fcf-protection')
> +endif
> +  elif cfi_mode == 'hw'
> +error('Hardware CFI is only supported on x86')
>endif
>if cfi_flags == [] and cfi_mode == 'auto'
>  cfi_mode = 'disabled'
>endif
>  endif
> -if cpu in ['x86', 'x86_64']
> +if cpu in ['x86', 'x86_64'] and cfi_mode != 'hw'
>cfi_flags += cc.get_supported_arguments('-fcf-protection=branch')
>  endif
> +
>  add_global_arguments(cfi_flags, native: false, language: all_languages)
>  add_global_link_arguments(cfi_flags, native: false, language:
> all_languages)
>
> diff --git a/util/coroutine-asm.c b/util/coroutine-asm.c
> index a06ecbcb0a07..771b1d4a0fc9 100644
> --- a/util/coroutine-asm.c
> +++ b/util/coroutine-asm.c
> @@ -22,6 +22,13 @@
>  #include "qemu/osdep.h"
>  #include "qemu-common.h"
>  #include "qemu/coroutine_int.h"
> +#include "qemu/error-report.h"
> +
> +#ifdef CONFIG_CF_PROTECTION
> +#include 
> +#include 
> +int arch_prctl(int code, unsigned long addr);
> +#endif
>
>  #ifdef CONFIG_VALGRIND_H
>  #include 
> @@ -39,10 +46,14 @@
>  typedef struct {
>  Coroutine base;
>  void *sp;
> +void *ssp;
>
>  void *stack;
>  size_t stack_size;
>
> +/* x86: CET shadow stack */
> +void *sstack;
> +size_t sstack_size;
>  #ifdef CONFIG_VALGRIND_H
>  unsigned int valgrind_stack_id;
>  #endif
> @@ -77,6 +88,35 @@ static void start_switch_fiber(void **fake_stack_save,
>  #endif
>  }
>
> +static bool have_sstack(void)
> +{
> +#if defined CONFIG_CF_PROTECTION && defined __x86_64__
> +uint64_t ssp;
> +asm ("xor %0, %0; rdsspq %0\n" : "=r" (ssp));
> +return !!ssp;
> +#else
> +return 0;
> +#endif
> +}
> +
> +static void *alloc_sstack(size_t sz)
> +{
> +#if defined CONFIG_CF_PROTECTION && defined __x86_64__
> +#ifndef ARCH_X86_CET_ALLOC_SHSTK
> +#define ARCH_X86_CET_ALLOC_SHSTK 0x3004
> +#endif
> +
> +uint64_t arg = sz;
> +if (arch_prctl(ARCH_X86_CET_ALLOC_SHSTK, (unsigned long) &arg) < 0) {
> +abort();
> +}
> +
> +return (void *)arg;
> +#else
> +abort();
> +#endif
> +}
> +
>  #ifdef __x86_64__
>  /*
>   * We hardcode all operands to specific registers so that we can write
> down all the
> @@ -88,6 +128,26 @@ static void start_switch_fiber(void **fake_stack_save,
>   * Note that push and call would clobber the red zone.  Makefile.objs
> compiles this
>   * file with -mno-red-zone.  The alternative is to subtract/add 128 bytes
> from rsp
>   * around the switch, with slightly lower cache performance.
> + *
> + * The RSTORSSP and SAVEPREVSSP instructions are intricate.  In a
> nutshell they are:
> + *
> + *  RSTORSSP(mem):oldSSP = SSP
> + *SSP = mem
> + **SSP = oldSSP
> + *
> + *  SAVEPREVSSP:  oldSSP = shadow_stack_pop()
> + **(oldSSP - 8) = oldSSP   # "push" to old
> shadow stack
> + *
> + * Therefore, RSTORSSP(mem) followed by SAVEPREVSSP is the same as
> + *
> + * shadow_stack_push(SSP)
> + * SSP = mem
> + * shadow_stack_pop()
> + *
> + * From the simplified description you can see that co->ssp, being stored
> before
> + * the RSTORSSP+SAVEPREVSSP sequence, points to the top actual entry of
> the shadow
> + * stack, not to the restore token.  Hence we use an offset of -8 in the
> operand
> + * of rstorssp.
>   */
>  #define CO_SWITCH(from, to, action, jump) ({
> \
>  int action_ = action;
>  \
> @@ -100,7 +160,15 @@ static void start_switch_fiber(void **fake_stack_save,
>  "jmp 2f\n"  /* switch back continues at
> label 2 */\
>
>  \
>  "1: .cfi_adjust_cfa_offset 8\n"
>  \
> -  

Re: [PATCH v2 38/38] host/include/ppc: Implement aes-round.h

[Daniel Henrique Barboza]

On 6/8/23 23:24, Richard Henderson wrote:

Detect CRYPTO in cpuinfo; implement the accel hooks.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  host/include/ppc/host/aes-round.h   | 181 
  host/include/ppc/host/cpuinfo.h |   1 +
  host/include/ppc64/host/aes-round.h |   1 +
  util/cpuinfo-ppc.c  |   8 ++
  4 files changed, 191 insertions(+)
  create mode 100644 host/include/ppc/host/aes-round.h
  create mode 100644 host/include/ppc64/host/aes-round.h

diff --git a/host/include/ppc/host/aes-round.h 
b/host/include/ppc/host/aes-round.h
new file mode 100644
index 00..9b5a15d1e5
--- /dev/null
+++ b/host/include/ppc/host/aes-round.h
@@ -0,0 +1,181 @@
+/*
+ * Power v2.07 specific aes acceleration.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef PPC_HOST_AES_ROUND_H
+#define PPC_HOST_AES_ROUND_H
+
+#ifndef __ALTIVEC__
+/* Without ALTIVEC, we can't even write inline assembly. */
+#include "host/include/generic/host/aes-round.h"
+#else
+#include "host/cpuinfo.h"
+
+#ifdef __CRYPTO__
+# define HAVE_AES_ACCEL  true
+#else
+# define HAVE_AES_ACCEL  likely(cpuinfo & CPUINFO_CRYPTO)
+#endif
+#define ATTR_AES_ACCEL
+
+/*
+ * While there is , both gcc and clang "aid" with the
+ * endianness issues in different ways. Just use inline asm instead.
+ */
+
+/* Bytes in memory are host-endian; bytes in register are @be. */
+static inline AESStateVec aes_accel_ld(const AESState *p, bool be)
+{
+AESStateVec r;
+
+if (be) {
+asm("lvx %0, 0, %1" : "=v"(r) : "r"(p), "m"(*p));
+} else if (HOST_BIG_ENDIAN) {
+AESStateVec rev = {
+15, 14, 13, 12, 11, 10, 9, 8, 7,  6,  5,  4,  3,  2,  1,  0,
+};
+asm("lvx %0, 0, %1\n\t"
+"vperm %0, %0, %0, %2"
+: "=v"(r) : "r"(p), "v"(rev), "m"(*p));
+} else {
+#ifdef __POWER9_VECTOR__
+asm("lxvb16x %x0, 0, %1" : "=v"(r) : "r"(p), "m"(*p));
+#else
+asm("lxvd2x %x0, 0, %1\n\t"
+"xxpermdi %x0, %x0, %x0, 2"
+: "=v"(r) : "r"(p), "m"(*p));
+#endif
+}
+return r;
+}
+
+static void aes_accel_st(AESState *p, AESStateVec r, bool be)
+{
+if (be) {
+asm("stvx %1, 0, %2" : "=m"(*p) : "v"(r), "r"(p));
+} else if (HOST_BIG_ENDIAN) {
+AESStateVec rev = {
+15, 14, 13, 12, 11, 10, 9, 8, 7,  6,  5,  4,  3,  2,  1,  0,
+};
+asm("vperm %1, %1, %1, %2\n\t"
+"stvx %1, 0, %3"
+: "=m"(*p), "+v"(r) : "v"(rev), "r"(p));
+} else {
+#ifdef __POWER9_VECTOR__
+asm("stxvb16x %x1, 0, %2" : "=m"(*p) : "v"(r), "r"(p));
+#else
+asm("xxpermdi %x1, %x1, %x1, 2\n\t"
+"stxvd2x %x1, 0, %2"
+: "=m"(*p), "+v"(r) : "r"(p));
+#endif
+}
+}
+
+static inline AESStateVec aes_accel_vcipher(AESStateVec d, AESStateVec k)
+{
+asm("vcipher %0, %0, %1" : "+v"(d) : "v"(k));
+return d;
+}
+
+static inline AESStateVec aes_accel_vncipher(AESStateVec d, AESStateVec k)
+{
+asm("vncipher %0, %0, %1" : "+v"(d) : "v"(k));
+return d;
+}
+
+static inline AESStateVec aes_accel_vcipherlast(AESStateVec d, AESStateVec k)
+{
+asm("vcipherlast %0, %0, %1" : "+v"(d) : "v"(k));
+return d;
+}
+
+static inline AESStateVec aes_accel_vncipherlast(AESStateVec d, AESStateVec k)
+{
+asm("vncipherlast %0, %0, %1" : "+v"(d) : "v"(k));
+return d;
+}
+
+static inline void
+aesenc_MC_accel(AESState *ret, const AESState *st, bool be)
+{
+AESStateVec t, z = { };
+
+t = aes_accel_ld(st, be);
+t = aes_accel_vncipherlast(t, z);
+t = aes_accel_vcipher(t, z);
+aes_accel_st(ret, t, be);
+}
+
+static inline void
+aesenc_SB_SR_AK_accel(AESState *ret, const AESState *st,
+  const AESState *rk, bool be)
+{
+AESStateVec t, k;
+
+t = aes_accel_ld(st, be);
+k = aes_accel_ld(rk, be);
+t = aes_accel_vcipherlast(t, k);
+aes_accel_st(ret, t, be);
+}
+
+static inline void
+aesenc_SB_SR_MC_AK_accel(AESState *ret, const AESState *st,
+ const AESState *rk, bool be)
+{
+AESStateVec t, k;
+
+t = aes_accel_ld(st, be);
+k = aes_accel_ld(rk, be);
+t = aes_accel_vcipher(t, k);
+aes_accel_st(ret, t, be);
+}
+
+static inline void
+aesdec_IMC_accel(AESState *ret, const AESState *st, bool be)
+{
+AESStateVec t, z = { };
+
+t = aes_accel_ld(st, be);
+t = aes_accel_vcipherlast(t, z);
+t = aes_accel_vncipher(t, z);
+aes_accel_st(ret, t, be);
+}
+
+static inline void
+aesdec_ISB_ISR_AK_accel(AESState *ret, const AESState *st,
+const AESState *rk, bool be)
+{
+AESStateVec t, k;
+
+t = aes_accel_ld(st, be);
+k = aes_accel_ld(rk, be);
+t = aes_accel_vncipherlast(t, k);
+aes_accel_st(ret, t, be);
+}
+
+static inline void
+aesdec_ISB_ISR_AK_IMC_accel(AESState *ret, const AESState *st,
+const AESState *rk, bool be)
+{
+AESStateVec t, k;
+
+

Re: [RFC v2 6/6] linux-user: Add '-native-bypass' option

[Alex Bennée]

Yeqi Fu  writes:

> Signed-off-by: Yeqi Fu 
> ---
>  include/qemu/envlist.h |  1 +
>  linux-user/main.c  | 23 +
>  util/envlist.c | 56 ++
>  3 files changed, 80 insertions(+)
>
> diff --git a/include/qemu/envlist.h b/include/qemu/envlist.h
> index 6006dfae44..865eb18e17 100644
> --- a/include/qemu/envlist.h
> +++ b/include/qemu/envlist.h
> @@ -7,6 +7,7 @@ envlist_t *envlist_create(void);
>  void envlist_free(envlist_t *);
>  int envlist_setenv(envlist_t *, const char *);
>  int envlist_unsetenv(envlist_t *, const char *);
> +int envlist_appendenv(envlist_t *, const char *, const char *);
>  int envlist_parse_set(envlist_t *, const char *);
>  int envlist_parse_unset(envlist_t *, const char *);
>  char **envlist_to_environ(const envlist_t *, size_t *);
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 5e6b2e1714..313c116b3b 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -125,6 +125,8 @@ static void usage(int exitcode);
>  static const char *interp_prefix = CONFIG_QEMU_INTERP_PREFIX;
>  const char *qemu_uname_release;
>  
> +static const char *native_lib;
> +
>  #if !defined(TARGET_DEFAULT_STACK_SIZE)
>  /* XXX: on x86 MAP_GROWSDOWN only works if ESP <= address + 32, so
> we allocate a bigger stack. Need a better solution, for example
> @@ -293,6 +295,13 @@ static void handle_arg_set_env(const char *arg)
>  free(r);
>  }
>  
> +#if defined(CONFIG_USER_ONLY)  && defined(CONFIG_USER_NATIVE_CALL)

CONFIG_USER_ONLY is a pointless check as by definition this file is
user-mode only.

> +static void handle_arg_native_bypass(const char *arg)
> +{
> +native_lib = arg;

canonicalise the path and maybe verify it exists/is accessible?

> +}
> +#endif
> +
>  static void handle_arg_unset_env(const char *arg)
>  {
>  char *r, *p, *token;
> @@ -522,6 +531,10 @@ static const struct qemu_argument arg_table[] = {
>   "",   "Generate a /tmp/perf-${pid}.map file for perf"},
>  {"jitdump","QEMU_JITDUMP", false, handle_arg_jitdump,
>   "",   "Generate a jit-${pid}.dump file for perf"},
> +#if defined(CONFIG_USER_ONLY)  && defined(CONFIG_USER_NATIVE_CALL)

see above re CONFIG_USER_ONLY.

> +{"native-bypass", "QEMU_NATIVE_BYPASS", true, handle_arg_native_bypass,
> + "",   "native bypass for library calls in user mode only."},
> +#endif
>  {NULL, NULL, false, NULL, NULL, NULL}
>  };
>  
> @@ -826,6 +839,16 @@ int main(int argc, char **argv, char **envp)
>  }
>  }
>  
> +/* Set the library for native bypass  */
> +if (native_lib != NULL) {
> +char *token = malloc(strlen(native_lib) + 12);
> +strcpy(token, "LD_PRELOAD=");
> +strcat(token, native_lib);
> + if (envlist_appendenv(envlist, token, ":") != 0) {
> +usage(EXIT_FAILURE);
> +}
> +}
> +
>  target_environ = envlist_to_environ(envlist, NULL);
>  envlist_free(envlist);
>  
> diff --git a/util/envlist.c b/util/envlist.c
> index db937c0427..713d52497e 100644
> --- a/util/envlist.c
> +++ b/util/envlist.c
> @@ -201,6 +201,62 @@ envlist_unsetenv(envlist_t *envlist, const char *env)
>  return (0);
>  }
>

I think adding this function should be a separate commit. It would be
nice to add some unittests for the functionality while we are at it.

> +/*
> + * Appends environment value to envlist. If the environment
> + * variable already exists, the new value is appended to the
> + * existing one.
> + *
> + * Returns 0 in success, errno otherwise.
> + */
> +int
> +envlist_appendenv(envlist_t *envlist, const char *env, const char *separator)
> +{
> +struct envlist_entry *entry = NULL;
> +const char *eq_sign;
> +size_t envname_len;
> +
> +if ((envlist == NULL) || (env == NULL)) {
> +return (EINVAL);
> +}
> +
> +/* find out first equals sign in given env */
> +eq_sign = strchr(env, '=');
> +if (eq_sign == NULL) {
> +return (EINVAL);
> +}
> +envname_len = eq_sign - env + 1;
> +
> +/*
> + * If there already exists variable with given name,
> + * we append the new value to the existing one.
> + */
> +for (entry = envlist->el_entries.lh_first; entry != NULL;
> +entry = entry->ev_link.le_next) {
> +if (strncmp(entry->ev_var, env, envname_len) == 0) {
> +break;
> +}
> +}
> +
> +if (entry != NULL) {
> +char *new_env_value = NULL;
> +size_t new_env_len = strlen(entry->ev_var) + strlen(eq_sign)
> ++ strlen(separator) + 1;
> +new_env_value = g_malloc(new_env_len);
> +strcpy(new_env_value, entry->ev_var);
> +strcat(new_env_value, separator);
> +strcat(new_env_value, eq_sign + 1);

See other comments about string functions.

> +g_free((char *)entry->ev_var);
> +entry->ev_var = new_env_value;
> +} else {
> +envlist->el_count++;
> +entry = g_mal

Re: [PATCH v2 31/38] target/ppc: Use aesdec_ISB_ISR_AK_IMC

[Daniel Henrique Barboza]

On 6/8/23 23:23, Richard Henderson wrote:

This implements the VNCIPHER instruction.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  target/ppc/int_helper.c | 19 ---
  1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 1e477924b7..834da80fe3 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -2947,22 +2947,11 @@ void helper_vcipherlast(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b)
  
  void helper_vncipher(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

  {
-/* This differs from what is written in ISA V2.07.  The RTL is */
-/* incorrect and will be fixed in V2.07B.  */
-int i;
-ppc_avr_t tmp;
+AESState *ad = (AESState *)r;
+AESState *st = (AESState *)a;
+AESState *rk = (AESState *)b;
  
-VECTOR_FOR_INORDER_I(i, u8) {

-tmp.VsrB(i) = b->VsrB(i) ^ AES_isbox[a->VsrB(AES_ishifts[i])];
-}
-
-VECTOR_FOR_INORDER_I(i, u32) {
-r->VsrW(i) =
-AES_imc[tmp.VsrB(4 * i + 0)][0] ^
-AES_imc[tmp.VsrB(4 * i + 1)][1] ^
-AES_imc[tmp.VsrB(4 * i + 2)][2] ^
-AES_imc[tmp.VsrB(4 * i + 3)][3];
-}
+aesdec_ISB_ISR_AK_IMC(ad, st, rk, true);
  }
  
  void helper_vncipherlast(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

Re: [PATCH v2 25/38] target/ppc: Use aesenc_SB_SR_MC_AK

[Daniel Henrique Barboza]

On 6/8/23 23:23, Richard Henderson wrote:

This implements the VCIPHER instruction.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  target/ppc/int_helper.c | 14 --
  1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 15f07fca2b..1e477924b7 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -2933,17 +2933,11 @@ void helper_vsbox(ppc_avr_t *r, ppc_avr_t *a)
  
  void helper_vcipher(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

  {
-ppc_avr_t result;
-int i;
+AESState *ad = (AESState *)r;
+AESState *st = (AESState *)a;
+AESState *rk = (AESState *)b;
  
-VECTOR_FOR_INORDER_I(i, u32) {

-result.VsrW(i) = b->VsrW(i) ^
-(AES_Te0[a->VsrB(AES_shifts[4 * i + 0])] ^
- AES_Te1[a->VsrB(AES_shifts[4 * i + 1])] ^
- AES_Te2[a->VsrB(AES_shifts[4 * i + 2])] ^
- AES_Te3[a->VsrB(AES_shifts[4 * i + 3])]);
-}
-*r = result;
+aesenc_SB_SR_MC_AK(ad, st, rk, true);
  }
  
  void helper_vcipherlast(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

Re: [PATCH v2 15/38] target/ppc: Use aesdec_ISB_ISR_AK

[Daniel Henrique Barboza]

On 6/8/23 23:23, Richard Henderson wrote:

This implements the VNCIPHERLAST instruction.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  target/ppc/int_helper.c | 8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 34257e9d76..15f07fca2b 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -2973,13 +2973,7 @@ void helper_vncipher(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b)
  
  void helper_vncipherlast(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

  {
-ppc_avr_t result;
-int i;
-
-VECTOR_FOR_INORDER_I(i, u8) {
-result.VsrB(i) = b->VsrB(i) ^ (AES_isbox[a->VsrB(AES_ishifts[i])]);
-}
-*r = result;
+aesdec_ISB_ISR_AK((AESState *)r, (AESState *)a, (AESState *)b, true);
  }
  
  void helper_vshasigmaw(ppc_avr_t *r,  ppc_avr_t *a, uint32_t st_six)

Re: [PATCH v2 02/38] util: Add cpuinfo-ppc.c

[Daniel Henrique Barboza]

On 6/8/23 23:23, Richard Henderson wrote:

Move the code from tcg/.  Fix a bug in that PPC_FEATURE2_ARCH_3_10
is actually spelled PPC_FEATURE2_ARCH_3_1.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  host/include/ppc/host/cpuinfo.h   | 29 
  host/include/ppc64/host/cpuinfo.h |  1 +
  tcg/ppc/tcg-target.h  | 16 -
  util/cpuinfo-ppc.c| 57 +++
  tcg/ppc/tcg-target.c.inc  | 44 +---
  util/meson.build  |  2 ++
  6 files changed, 98 insertions(+), 51 deletions(-)
  create mode 100644 host/include/ppc/host/cpuinfo.h
  create mode 100644 host/include/ppc64/host/cpuinfo.h
  create mode 100644 util/cpuinfo-ppc.c

diff --git a/host/include/ppc/host/cpuinfo.h b/host/include/ppc/host/cpuinfo.h
new file mode 100644
index 00..7ec252ef52
--- /dev/null
+++ b/host/include/ppc/host/cpuinfo.h
@@ -0,0 +1,29 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ * Host specific cpu indentification for ppc.
+ */
+
+#ifndef HOST_CPUINFO_H
+#define HOST_CPUINFO_H
+
+/* Digested version of  */
+
+#define CPUINFO_ALWAYS  (1u << 0)  /* so cpuinfo is nonzero */
+#define CPUINFO_V2_06   (1u << 1)
+#define CPUINFO_V2_07   (1u << 2)
+#define CPUINFO_V3_00   (1u << 3)
+#define CPUINFO_V3_10   (1u << 4)
+#define CPUINFO_ISEL(1u << 5)
+#define CPUINFO_ALTIVEC (1u << 6)
+#define CPUINFO_VSX (1u << 7)
+
+/* Initialized with a constructor. */
+extern unsigned cpuinfo;
+
+/*
+ * We cannot rely on constructor ordering, so other constructors must
+ * use the function interface rather than the variable above.
+ */
+unsigned cpuinfo_init(void);
+
+#endif /* HOST_CPUINFO_H */
diff --git a/host/include/ppc64/host/cpuinfo.h 
b/host/include/ppc64/host/cpuinfo.h
new file mode 100644
index 00..2f036a0627
--- /dev/null
+++ b/host/include/ppc64/host/cpuinfo.h
@@ -0,0 +1 @@
+#include "host/include/ppc/host/cpuinfo.h"
diff --git a/tcg/ppc/tcg-target.h b/tcg/ppc/tcg-target.h
index c7552b6391..b632a5a647 100644
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -25,6 +25,8 @@
  #ifndef PPC_TCG_TARGET_H
  #define PPC_TCG_TARGET_H
  
+#include "host/cpuinfo.h"

+
  #define MAX_CODE_GEN_BUFFER_SIZE  ((size_t)-1)
  
  #define TCG_TARGET_NB_REGS 64

@@ -61,14 +63,12 @@ typedef enum {
  tcg_isa_3_10,
  } TCGPowerISA;
  
-extern TCGPowerISA have_isa;

-extern bool have_altivec;
-extern bool have_vsx;
-
-#define have_isa_2_06  (have_isa >= tcg_isa_2_06)
-#define have_isa_2_07  (have_isa >= tcg_isa_2_07)
-#define have_isa_3_00  (have_isa >= tcg_isa_3_00)
-#define have_isa_3_10  (have_isa >= tcg_isa_3_10)
+#define have_isa_2_06  (cpuinfo & CPUINFO_V2_06)
+#define have_isa_2_07  (cpuinfo & CPUINFO_V2_07)
+#define have_isa_3_00  (cpuinfo & CPUINFO_V3_00)
+#define have_isa_3_10  (cpuinfo & CPUINFO_V3_10)
+#define have_altivec   (cpuinfo & CPUINFO_ALTIVEC)
+#define have_vsx   (cpuinfo & CPUINFO_VSX)
  
  /* optional instructions automatically implemented */

  #define TCG_TARGET_HAS_ext8u_i320 /* andi */
diff --git a/util/cpuinfo-ppc.c b/util/cpuinfo-ppc.c
new file mode 100644
index 00..ee761de33a
--- /dev/null
+++ b/util/cpuinfo-ppc.c
@@ -0,0 +1,57 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ * Host specific cpu indentification for ppc.
+ */
+
+#include "qemu/osdep.h"
+#include "host/cpuinfo.h"
+
+#ifdef CONFIG_GETAUXVAL
+# include 
+#else
+# include 
+# include "elf.h"
+#endif
+
+unsigned cpuinfo;
+
+/* Called both as constructor and (possibly) via other constructors. */
+unsigned __attribute__((constructor)) cpuinfo_init(void)
+{
+unsigned info = cpuinfo;
+unsigned long hwcap, hwcap2;
+
+if (info) {
+return info;
+}
+
+hwcap = qemu_getauxval(AT_HWCAP);
+hwcap2 = qemu_getauxval(AT_HWCAP2);
+info = CPUINFO_ALWAYS;
+
+if (hwcap & PPC_FEATURE_ARCH_2_06) {
+info |= CPUINFO_V2_06;
+}
+if (hwcap2 & PPC_FEATURE2_ARCH_2_07) {
+info |= CPUINFO_V2_07;
+}
+if (hwcap2 & PPC_FEATURE2_ARCH_3_00) {
+info |= CPUINFO_V3_00;
+}
+if (hwcap2 & PPC_FEATURE2_ARCH_3_1) {
+info |= CPUINFO_V3_10;
+}
+if (hwcap2 & PPC_FEATURE2_HAS_ISEL) {
+info |= CPUINFO_ISEL;
+}
+if (hwcap & PPC_FEATURE_HAS_ALTIVEC) {
+info |= CPUINFO_ALTIVEC;
+/* We only care about the portion of VSX that overlaps Altivec. */
+if (hwcap & PPC_FEATURE_HAS_VSX) {
+info |= CPUINFO_VSX;
+}
+}
+
+cpuinfo = info;
+return info;
+}
diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc
index 5c8378f8f6..c866f2c997 100644
--- a/tcg/ppc/tcg-target.c.inc
+++ b/tcg/ppc/tcg-target.c.inc
@@ -101,10 +101,7 @@
  #define ALL_GENERAL_REGS  0xu
  #define ALL_VECTOR_REGS   0xull
  
-TCGPowerISA have_isa;

-static bool have_isel;
-bool have_altivec;
-bool 

Re: [PATCH v2 10/38] target/ppc: Use aesenc_SB_SR_AK

[Daniel Henrique Barboza]

On 6/8/23 23:23, Richard Henderson wrote:

This implements the VCIPHERLAST instruction.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  target/ppc/int_helper.c | 9 ++---
  1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index d97a7f1f28..34257e9d76 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -25,6 +25,7 @@
  #include "qemu/log.h"
  #include "exec/helper-proto.h"
  #include "crypto/aes.h"
+#include "crypto/aes-round.h"
  #include "fpu/softfloat.h"
  #include "qapi/error.h"
  #include "qemu/guest-random.h"
@@ -2947,13 +2948,7 @@ void helper_vcipher(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b)
  
  void helper_vcipherlast(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

  {
-ppc_avr_t result;
-int i;
-
-VECTOR_FOR_INORDER_I(i, u8) {
-result.VsrB(i) = b->VsrB(i) ^ (AES_sbox[a->VsrB(AES_shifts[i])]);
-}
-*r = result;
+aesenc_SB_SR_AK((AESState *)r, (AESState *)a, (AESState *)b, true);
  }
  
  void helper_vncipher(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)

Re: [PATCH v2 01/38] tcg/ppc: Define _CALL_AIX for clang on ppc64(be)

[Daniel Henrique Barboza]

On 6/8/23 23:23, Richard Henderson wrote:

Restructure the ifdef ladder, separating 64-bit from 32-bit,
and ensure _CALL_AIX is set for ELF v1.  Fixes the build for
ppc64 big-endian host with clang.

Signed-off-by: Richard Henderson 
---


Reviewed-by: Daniel Henrique Barboza 


  tcg/ppc/tcg-target.c.inc | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/tcg/ppc/tcg-target.c.inc b/tcg/ppc/tcg-target.c.inc
index 507fe6cda8..5c8378f8f6 100644
--- a/tcg/ppc/tcg-target.c.inc
+++ b/tcg/ppc/tcg-target.c.inc
@@ -29,15 +29,24 @@
  /*
   * Standardize on the _CALL_FOO symbols used by GCC:
   * Apple XCode does not define _CALL_DARWIN.
- * Clang defines _CALL_ELF (64-bit) but not _CALL_SYSV (32-bit).
+ * Clang defines _CALL_ELF (64-bit) but not _CALL_SYSV or _CALL_AIX.
   */
-#if !defined(_CALL_SYSV) && \
-!defined(_CALL_DARWIN) && \
-!defined(_CALL_AIX) && \
-!defined(_CALL_ELF)
-# if defined(__APPLE__)
+#if TCG_TARGET_REG_BITS == 64
+# ifdef _CALL_AIX
+/* ok */
+# elif defined(_CALL_ELF) && _CALL_ELF == 1
+#  define _CALL_AIX
+# elif defined(_CALL_ELF) && _CALL_ELF == 2
+/* ok */
+# else
+#  error "Unknown ABI"
+# endif
+#else
+# if defined(_CALL_SYSV) || defined(_CALL_DARWIN)
+/* ok */
+# elif defined(__APPLE__)
  #  define _CALL_DARWIN
-# elif defined(__ELF__) && TCG_TARGET_REG_BITS == 32
+# elif defined(__ELF__)
  #  define _CALL_SYSV
  # else
  #  error "Unknown ABI"

Re: [RFC v2 6/6] linux-user: Add '-native-bypass' option

[Alex Bennée]

Manos Pitsidianakis  writes:

> On Wed, 07 Jun 2023 19:47, Yeqi Fu  wrote:
>>--- a/linux-user/main.c
>>+++ b/linux-user/main.c
>>+/* Set the library for native bypass  */
>>+if (native_lib != NULL) {
>>+char *token = malloc(strlen(native_lib) + 12);
>
> malloc() can fail (in rare circumstances). Check for the return value
> here. Or use g_malloc() which terminates on alloc failure.

We avoid malloc in favour of g_malloc(). You can use g_try_malloc for
certain cases (although this is not one of them). However you can make
this glibs problem with something like:

/* Set the library for native bypass  */
if (native_lib != NULL) {
GString *lib = g_string_new(native_lib);
lib = g_string_prepend(lib, "LD_PRELOAD=");
if (envlist_appendenv(envlist, g_string_free(lib, false), ":") != 0) {
usage(EXIT_FAILURE);
}
}


>
>>+strcpy(token, "LD_PRELOAD=");
>>+strcat(token, native_lib);
>
> (You could alternatively use snprintf() here)

We have a section on strings in the developer manual:

 https://qemu.readthedocs.io/en/latest/devel/style.html#string-manipulation

so we have things like pstrcat and pstrcpy. However this isn't criticl
performance path so GString provides a nice memory safe wrapper for all
this sort of manipulation.



-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v3 2/8] target/arm: v8.3 PAC ID_AA64ISAR[12] feature-detection

[Aaron Lindsay]

On Jun 09 13:51, Richard Henderson wrote:
> On 6/9/23 10:23, Aaron Lindsay wrote:
> > +static inline int isar_feature_pauth_get_features(const ARMISARegisters 
> > *id)
> > +{
> > +if (isar_feature_aa64_pauth_arch_qarma5(id)) {
> > +return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, APA);
> > +} else if (isar_feature_aa64_pauth_arch_qarma3(id)) {
> > +return FIELD_EX64(id->id_aa64isar2, ID_AA64ISAR2, APA3);
> > +} else {
> > +return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, API);
> > +}
> > +}
> 
> As I mentioned in previous review, exactly one of these fields will be
> non-zero, so you can just OR them all together without the conditionals.

Sorry I missed this last time around - I've queued this change for v4.

Thanks!

-Aaron

Re: [PATCH v3 1/8] target/arm: Add ID_AA64ISAR2_EL1

[Aaron Lindsay]

On Jun 09 13:49, Richard Henderson wrote:
> On 6/9/23 10:23, Aaron Lindsay wrote:
> > --- a/target/arm/hvf/hvf.c
> > +++ b/target/arm/hvf/hvf.c
> > @@ -847,6 +847,7 @@ static bool 
> > hvf_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
> >   { HV_SYS_REG_ID_AA64DFR1_EL1, &host_isar.id_aa64dfr1 },
> >   { HV_SYS_REG_ID_AA64ISAR0_EL1, &host_isar.id_aa64isar0 },
> >   { HV_SYS_REG_ID_AA64ISAR1_EL1, &host_isar.id_aa64isar1 },
> > +{ HV_SYS_REG_ID_AA64ISAR2_EL1, &host_isar.id_aa64isar2 },
> 
> Sadly not defined for MacOSX13.1.sdk, and it's an enum so you can't #ifdef it 
> either.
> 
> You'll need a meson probe for it.

I'm not very familiar with HVF or meson - I am not sure I understand
what you're suggesting here (and a few attempts to grep around for an
example didn't turn up anything that looked helpful). Are you suggesting
some sort of build-time auto-detection, a "dumb" configuration switch
that a user could use to manually enable this, or something else? And/or
is there an example you could point me to of what you're thinking?

-Aaron

Re: [RFC 0/2] migration: Update error description outside migration.c

[Peter Xu]

On Fri, May 26, 2023 at 11:50:01AM +, Tejus GK wrote:
> Hi everyone,
> 
> This patchset aims to cover code paths in the source code where a 
> migration is marked as failed via MIGRATION_STATUS_FAILED, however the 
> failure exists outside of migration.c, and without a call for 
> migrate_set_error at this place. 
> 
> This patchset has been split out from the patchset sent before which 
> covered cases of such gaps in migration.c aswell.
> 
> Previous patchset: 
> https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg04463.html 

Acked-by: Peter Xu 

-- 
Peter Xu

[PATCH] target/riscv: fix the issue of guest reboot then no response or crash in kvm-mode

[liguang.zhang]

From: "liguang.zhang" 

There have a issue of guest reboot bug in kvm-mode:
1. in guest shell just run the reboot, guest can't reboot success, and host kvm 
stop the vcpu schedual.
2. for smp guest, ctrl+a+c switch to qemu command, use system_reset command to 
reset the guest, then vcpu crash

kernel log
```shell
$reboot

The system is going down NOW!
Sent SIGTERM to all processes
logout
Sent SIGKILL to all processes
Requesting system reboot

```
then no response

for qemu command:
$system_reset:

kernel log:
```shell
[   53.739556] kvm [150]: VCPU exit error -95
[   53.739563] kvm [148]: VCPU exit error -95
[   53.739557] kvm [149]: VCPU exit error -95
[   53.740957] kvm [149]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.740957] kvm [148]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.741054] kvm [148]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
[   53.741058] kvm [149]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
[   53.756187] kvm [150]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.757797] kvm [150]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
```

solution:

add reset csr and context for riscv vcpu
qemu ioctl reset vcpu->arch.power_off state of kvm

tests:

qemu-system-riscv64 -M virt -bios none -kernel Image \
   -smp 4 -enable-kvm \
   -append "rootwait root=/dev/vda ro" \
   -drive file=rootfs.ext2,format=raw,id=hd0 \
   -device virtio-blk-device,drive=hd0

in guest shell:
$reboot

qemu command:
$system_reset

---
v2:
- update submit description

Signed-off-by: liguang.zhang 
---
 target/riscv/kvm.c   | 43 
 target/riscv/kvm_riscv.h |  1 +
 2 files changed, 44 insertions(+)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 0f932a5b96..c6a7824c9e 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -42,6 +42,8 @@
 #include "migration/migration.h"
 #include "sysemu/runstate.h"
 
+static bool cap_has_mp_state;
+
 static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
  uint64_t idx)
 {
@@ -335,6 +337,25 @@ int kvm_arch_get_registers(CPUState *cs)
 return ret;
 }
 
+int kvm_riscv_set_mpstate_to_kvm(RISCVCPU *cpu, int state)
+{
+if (cap_has_mp_state) {
+
+struct kvm_mp_state mp_state = {
+.mp_state = state
+};
+
+int ret = kvm_vcpu_ioctl(CPU(cpu), KVM_SET_MP_STATE, &mp_state);
+if (ret) {
+fprintf(stderr, "%s: failed to set MP_STATE %d/%s\n",
+__func__, ret, strerror(-ret));
+return -1;
+}
+}
+
+return 0;
+}
+
 int kvm_arch_put_registers(CPUState *cs, int level)
 {
 int ret = 0;
@@ -354,6 +375,18 @@ int kvm_arch_put_registers(CPUState *cs, int level)
 return ret;
 }
 
+if (KVM_PUT_RESET_STATE == level) {
+RISCVCPU *cpu = RISCV_CPU(cs);
+if (cs->cpu_index == 0) {
+ret = kvm_riscv_set_mpstate_to_kvm(cpu, KVM_MP_STATE_RUNNABLE);
+} else {
+ret = kvm_riscv_set_mpstate_to_kvm(cpu, KVM_MP_STATE_STOPPED);
+}
+if (ret) {
+return ret;
+}
+}
+
 return ret;
 }
 
@@ -428,6 +461,7 @@ int kvm_arch_add_msi_route_post(struct 
kvm_irq_routing_entry *route,
 
 int kvm_arch_init(MachineState *ms, KVMState *s)
 {
+cap_has_mp_state = kvm_check_extension(s, KVM_CAP_MP_STATE);
 return 0;
 }
 
@@ -506,10 +540,19 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
 if (!kvm_enabled()) {
 return;
 }
+for (int i=0; i<32; i++)
+env->gpr[i] = 0;
 env->pc = cpu->env.kernel_addr;
 env->gpr[10] = kvm_arch_vcpu_id(CPU(cpu)); /* a0 */
 env->gpr[11] = cpu->env.fdt_addr;  /* a1 */
 env->satp = 0;
+env->mie = 0;
+env->stvec = 0;
+env->sscratch = 0;
+env->sepc = 0;
+env->scause = 0;
+env->stval = 0;
+env->mip = 0;
 }
 
 void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level)
diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
index ed281bdce0..4a4c262820 100644
--- a/target/riscv/kvm_riscv.h
+++ b/target/riscv/kvm_riscv.h
@@ -21,5 +21,6 @@
 
 void kvm_riscv_reset_vcpu(RISCVCPU *cpu);
 void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level);
+int kvm_riscv_set_mpstate_to_kvm(RISCVCPU *cpu, int state);
 
 #endif
-- 
2.17.1

[PATCH] target/riscv: fix the issue of guest reboot then no response or crash in kvm-mode

[liguang.zhang]

From: "liguang.zhang" 

kernel log
```shell
The system is going down NOW!
Sent SIGTERM to all processes
logout
Sent SIGKILL to all processes
Requesting system reboot

```
then no response

for qemu command:
system_reset:

kernel log:
```shell
[   53.739556] kvm [150]: VCPU exit error -95
[   53.739563] kvm [148]: VCPU exit error -95
[   53.739557] kvm [149]: VCPU exit error -95
[   53.740957] kvm [149]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.740957] kvm [148]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.741054] kvm [148]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
[   53.741058] kvm [149]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
[   53.756187] kvm [150]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.757797] kvm [150]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
```

solution:

add reset csr and context for riscv vcpu
qemu ioctl reset vcpu->arch.power_off state of kvm

tests:

qemu-system-riscv64 -M virt -bios none -kernel Image \
   -smp 4 -enable-kvm \
   -append "rootwait root=/dev/vda ro" \
   -drive file=rootfs.ext2,format=raw,id=hd0 \
   -device virtio-blk-device,drive=hd0

in guest shell:

qemu command:
system_reset

Signed-off-by: liguang.zhang 
---
 target/riscv/kvm.c   | 43 
 target/riscv/kvm_riscv.h |  1 +
 2 files changed, 44 insertions(+)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 0f932a5b96..c6a7824c9e 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -42,6 +42,8 @@
 #include "migration/migration.h"
 #include "sysemu/runstate.h"
 
+static bool cap_has_mp_state;
+
 static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
  uint64_t idx)
 {
@@ -335,6 +337,25 @@ int kvm_arch_get_registers(CPUState *cs)
 return ret;
 }
 
+int kvm_riscv_set_mpstate_to_kvm(RISCVCPU *cpu, int state)
+{
+if (cap_has_mp_state) {
+
+struct kvm_mp_state mp_state = {
+.mp_state = state
+};
+
+int ret = kvm_vcpu_ioctl(CPU(cpu), KVM_SET_MP_STATE, &mp_state);
+if (ret) {
+fprintf(stderr, "%s: failed to set MP_STATE %d/%s\n",
+__func__, ret, strerror(-ret));
+return -1;
+}
+}
+
+return 0;
+}
+
 int kvm_arch_put_registers(CPUState *cs, int level)
 {
 int ret = 0;
@@ -354,6 +375,18 @@ int kvm_arch_put_registers(CPUState *cs, int level)
 return ret;
 }
 
+if (KVM_PUT_RESET_STATE == level) {
+RISCVCPU *cpu = RISCV_CPU(cs);
+if (cs->cpu_index == 0) {
+ret = kvm_riscv_set_mpstate_to_kvm(cpu, KVM_MP_STATE_RUNNABLE);
+} else {
+ret = kvm_riscv_set_mpstate_to_kvm(cpu, KVM_MP_STATE_STOPPED);
+}
+if (ret) {
+return ret;
+}
+}
+
 return ret;
 }
 
@@ -428,6 +461,7 @@ int kvm_arch_add_msi_route_post(struct 
kvm_irq_routing_entry *route,
 
 int kvm_arch_init(MachineState *ms, KVMState *s)
 {
+cap_has_mp_state = kvm_check_extension(s, KVM_CAP_MP_STATE);
 return 0;
 }
 
@@ -506,10 +540,19 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
 if (!kvm_enabled()) {
 return;
 }
+for (int i=0; i<32; i++)
+env->gpr[i] = 0;
 env->pc = cpu->env.kernel_addr;
 env->gpr[10] = kvm_arch_vcpu_id(CPU(cpu)); /* a0 */
 env->gpr[11] = cpu->env.fdt_addr;  /* a1 */
 env->satp = 0;
+env->mie = 0;
+env->stvec = 0;
+env->sscratch = 0;
+env->sepc = 0;
+env->scause = 0;
+env->stval = 0;
+env->mip = 0;
 }
 
 void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level)
diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
index ed281bdce0..4a4c262820 100644
--- a/target/riscv/kvm_riscv.h
+++ b/target/riscv/kvm_riscv.h
@@ -21,5 +21,6 @@
 
 void kvm_riscv_reset_vcpu(RISCVCPU *cpu);
 void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level);
+int kvm_riscv_set_mpstate_to_kvm(RISCVCPU *cpu, int state);
 
 #endif
-- 
2.17.1

[PATCH] target/riscv: fix the issue of guest reboot then no response or crash in kvm-mode

[liguang.zhang]

From: "liguang.zhang" 

kernel log
```shell
reboot

The system is going down NOW!
Sent SIGTERM to all processes
logout
Sent SIGKILL to all processes
Requesting system reboot

```
then no response

for qemu command:
system_reset:

kernel log:
```shell
[   53.739556] kvm [150]: VCPU exit error -95
[   53.739563] kvm [148]: VCPU exit error -95
[   53.739557] kvm [149]: VCPU exit error -95
[   53.740957] kvm [149]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.740957] kvm [148]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.741054] kvm [148]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
[   53.741058] kvm [149]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
[   53.756187] kvm [150]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[   53.757797] kvm [150]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0
```

solution:

add reset csr and context for riscv vcpu
qemu ioctl reset vcpu->arch.power_off state of kvm

tests:

qemu-system-riscv64 -M virt -bios none -kernel Image \
   -smp 4 -enable-kvm \
   -append "rootwait root=/dev/vda ro" \
   -drive file=rootfs.ext2,format=raw,id=hd0 \
   -device virtio-blk-device,drive=hd0

in guest shell:
reboot

qemu command:
system_reset

Signed-off-by: liguang.zhang 
Signed-off-by: liguang.zhang <18622748...@163.com>
---
 target/riscv/kvm.c   | 43 
 target/riscv/kvm_riscv.h |  1 +
 2 files changed, 44 insertions(+)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 0f932a5b96..c6a7824c9e 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -42,6 +42,8 @@
 #include "migration/migration.h"
 #include "sysemu/runstate.h"
 
+static bool cap_has_mp_state;
+
 static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
  uint64_t idx)
 {
@@ -335,6 +337,25 @@ int kvm_arch_get_registers(CPUState *cs)
 return ret;
 }
 
+int kvm_riscv_set_mpstate_to_kvm(RISCVCPU *cpu, int state)
+{
+if (cap_has_mp_state) {
+
+struct kvm_mp_state mp_state = {
+.mp_state = state
+};
+
+int ret = kvm_vcpu_ioctl(CPU(cpu), KVM_SET_MP_STATE, &mp_state);
+if (ret) {
+fprintf(stderr, "%s: failed to set MP_STATE %d/%s\n",
+__func__, ret, strerror(-ret));
+return -1;
+}
+}
+
+return 0;
+}
+
 int kvm_arch_put_registers(CPUState *cs, int level)
 {
 int ret = 0;
@@ -354,6 +375,18 @@ int kvm_arch_put_registers(CPUState *cs, int level)
 return ret;
 }
 
+if (KVM_PUT_RESET_STATE == level) {
+RISCVCPU *cpu = RISCV_CPU(cs);
+if (cs->cpu_index == 0) {
+ret = kvm_riscv_set_mpstate_to_kvm(cpu, KVM_MP_STATE_RUNNABLE);
+} else {
+ret = kvm_riscv_set_mpstate_to_kvm(cpu, KVM_MP_STATE_STOPPED);
+}
+if (ret) {
+return ret;
+}
+}
+
 return ret;
 }
 
@@ -428,6 +461,7 @@ int kvm_arch_add_msi_route_post(struct 
kvm_irq_routing_entry *route,
 
 int kvm_arch_init(MachineState *ms, KVMState *s)
 {
+cap_has_mp_state = kvm_check_extension(s, KVM_CAP_MP_STATE);
 return 0;
 }
 
@@ -506,10 +540,19 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
 if (!kvm_enabled()) {
 return;
 }
+for (int i=0; i<32; i++)
+env->gpr[i] = 0;
 env->pc = cpu->env.kernel_addr;
 env->gpr[10] = kvm_arch_vcpu_id(CPU(cpu)); /* a0 */
 env->gpr[11] = cpu->env.fdt_addr;  /* a1 */
 env->satp = 0;
+env->mie = 0;
+env->stvec = 0;
+env->sscratch = 0;
+env->sepc = 0;
+env->scause = 0;
+env->stval = 0;
+env->mip = 0;
 }
 
 void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level)
diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
index ed281bdce0..4a4c262820 100644
--- a/target/riscv/kvm_riscv.h
+++ b/target/riscv/kvm_riscv.h
@@ -21,5 +21,6 @@
 
 void kvm_riscv_reset_vcpu(RISCVCPU *cpu);
 void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level);
+int kvm_riscv_set_mpstate_to_kvm(RISCVCPU *cpu, int state);
 
 #endif
-- 
2.17.1

Re: [RFC v2 1/6] build: Add configure options for native calls

[Alex Bennée]

Alex Bennée  writes:

> Yeqi Fu  writes:
>
>> Signed-off-by: Yeqi Fu 
>> ---
>>  Makefile|  4 +++
>>  common-user/native/Makefile.include |  9 ++
>>  common-user/native/Makefile.target  | 22 +
>>  configure   | 50 +
>>  docs/devel/build-system.rst |  4 +++
>>  meson.build |  8 +
>>  meson_options.txt   |  2 ++
>>  scripts/meson-buildoptions.sh   |  4 +++
>>  8 files changed, 103 insertions(+)
>>  create mode 100644 common-user/native/Makefile.include
>>  create mode 100644 common-user/native/Makefile.target
>>
>> diff --git a/Makefile b/Makefile
>> index 3c7d67142f..923da109bf 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -185,6 +185,10 @@ SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory 
>> --quiet)
>>  
>>  include $(SRC_PATH)/tests/Makefile.include
>>  
>> +ifeq ($(CONFIG_USER_NATIVE),y)
>> +include $(SRC_PATH)/common-user/native/Makefile.include
>> +endif
>> +
>>  all: recurse-all
>>  
>>  ROMS_RULES=$(foreach t, all clean distclean, $(addsuffix /$(t), $(ROMS)))
>> diff --git a/common-user/native/Makefile.include 
>> b/common-user/native/Makefile.include
>> new file mode 100644
>> index 00..40d20bcd4c
>> --- /dev/null
>> +++ b/common-user/native/Makefile.include
>> @@ -0,0 +1,9 @@
>> +.PHONY: build-native
>> +build-native: $(NATIVE_TARGETS:%=build-native-library-%)
>> +$(NATIVE_TARGETS:%=build-native-library-%): build-native-library-%:
>> +$(call quiet-command, \
>> +$(MAKE) -C common-user/native/$* $(SUBDIR_MAKEFLAGS), \
>> +"BUILD","$* native library")
>> +# endif
>> +
>> +all: build-native
>
> I think it would be better if we could add the targets via meson and let
> it deal with the multiple versions. I will defer to Paolo on how to do
> this though.

OK Paolo said we won't expose cross compilers to meson so we are stuck
with pure makefiles for now... however:


>> +
>> +(config_host_mak=common-user/native/config-host.mak
>> +mkdir -p common-user/native
>> +echo "# Automatically generated by configure - do not modify" > 
>> $config_host_mak
>> +echo "SRC_PATH=$source_path" >> $config_host_mak
>> +echo "HOST_CC=$host_cc" >> $config_host_mak
>> +
>> +native_targets=
>> +for target in $target_list; do
>> +  arch=${target%%-*}
>> +
>> +  case $target in
>> +*-linux-user|*-bsd-user)
>> +if probe_target_compiler $target || test -n "$container_image"; then
>> +mkdir -p "common-user/native/$target"
>> +config_target_mak=common-user/native/$target/config-target.mak
>> +ln -sf "$source_path/common-user/native/Makefile.target" 
>> "common-user/native/$target/Makefile"
>> +echo "# Automatically generated by configure - do not modify" > 
>> "$config_target_mak"
>> +echo "TARGET_NAME=$arch" >> "$config_target_mak"
>> +echo "TARGET=$target" >> "$config_target_mak"
>> +eval "target_native_flag=\${native_flag_$target_arch}"
>> +target_cflags="$target_cflags $target_native_flag"
>> +write_target_makefile "build-native-library-$target" >> 
>> "$config_target_mak"
>> +native_targets="$native_targets $target"
>> +fi
>> +  ;;
>> +  esac
>> +done
>
> This is basically replicating what we already have in
> tests/tcg/FOO-linux-user/config-target.mak. I would suggest moving those
> into a common location ($BUILD/targets/foo/compiler.mak) and then fixing
> up TCG tests to use the new location. When you add the native libs you
> can use the same configs.

This should be merged with the existing config_target code.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 02/15] hw/pci-host/q35: Fix double, contradicting .endianness assignment

[Igor Mammedov]

On Sun, 11 Jun 2023 12:33:59 +0200
Bernhard Beschow  wrote:

> Fixes the following clangd warning (-Winitializer-overrides):
> 
>   q35.c:297:19: Initializer overrides prior initialization of this subobject
>   q35.c:292:19: previous initialization is here
> 
> Settle on native endian which causes the least overhead.
indeed it doesn't matter which way we read all ones, so that should work.
but does it really matter (I mean the overhead/what workload)?
If not, I'd prefer explicit LE as it's now to be consistent
the the rest of memops on Q35.

> 
> Fixes: bafc90bdc594 ("q35: implement TSEG")
> Signed-off-by: Bernhard Beschow 
> ---
>  hw/pci-host/q35.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index fd18920e7f..859c197f25 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -290,7 +290,6 @@ static const MemoryRegionOps blackhole_ops = {
>  .valid.max_access_size = 4,
>  .impl.min_access_size = 4,
>  .impl.max_access_size = 4,
> -.endianness = DEVICE_LITTLE_ENDIAN,
>  };
>  
>  /* PCIe MMCFG */

Re: Fwd: QEMU AVR Patch - Correct handling of AVR interrupts

[Philippe Mathieu-Daudé]

Hi Lucas,

On 8/6/23 23:03, Adecy wrote:

-- Forwarded message -
De : *Adecy* mailto:ld.ad...@gmail.com>>
Date: jeu. 1 juin 2023 à 21:34
Subject: QEMU AVR Patch - Correct handling of AVR interrupts
To: mailto:qemu-triv...@nongnu.org>>


Hello,

I would like to submit the attached patch.


Unfortunately your patch doesn't apply cleanly:

Applying: Fix handling of AVR interrupts above 33 by switching ctz32 to 
ctz64

error: patch failed: target/avr/helper.c:45
error: target/avr/helper.c: patch does not apply
Patch failed at 0001 Fix handling of AVR interrupts above 33 by 
switching ctz32 to ctz64

hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

You can find help on how to send your patch here:
https://www.qemu.org/docs/master/devel/submitting-a-patch.html#submitting-your-patches

Thanks,

Phil.

Re: [PATCH 1/5] cmd646: checkpatch fixes

[Philippe Mathieu-Daudé]

On 9/6/23 20:51, Mark Cave-Ayland wrote:

Signed-off-by: Mark Cave-Ayland 
---
  hw/ide/cmd646.c | 13 +++--
  1 file changed, 7 insertions(+), 6 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 4/5] cmd646: rename cmd646_bmdma_ops to bmdma_ops

[Philippe Mathieu-Daudé]

On 9/6/23 20:51, Mark Cave-Ayland wrote:

This is to allow us to use the cmd646_bmdma_ops name for the CMD646
device-specific registers in the next commit.

Signed-off-by: Mark Cave-Ayland 
---
  hw/ide/cmd646.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

[Marc-André Lureau]

Hi

On Thu, Jun 8, 2023 at 6:26 AM Jiqian Chen  wrote:

> After suspending and resuming guest VM, you will get
> a black screen, and the display can't come back.
>
> This is because when guest did suspending, it called
> into qemu to call virtio_gpu_gl_reset. In function
> virtio_gpu_gl_reset, it destroyed resources and reset
> renderer, which were used for display. As a result,
> guest's screen can't come back to the time when it was
> suspended and only showed black.
>
> So, this patch adds a new ctrl message
> VIRTIO_GPU_CMD_STATUS_FREEZING to get notification from
> guest. If guest is during suspending, it sets freezing
> status of virtgpu to true, this will prevent destroying
> resources and resetting renderer when guest calls into
> virtio_gpu_gl_reset. If guest is during resuming, it sets
> freezing to false, and then virtio_gpu_gl_reset will keep
> its origin actions and has no other impaction.
>
> Signed-off-by: Jiqian Chen 
> ---
>  hw/display/virtio-gpu-gl.c  |  9 ++-
>  hw/display/virtio-gpu-virgl.c   |  3 +++
>  hw/display/virtio-gpu.c | 26 +++--
>  include/hw/virtio/virtio-gpu.h  |  3 +++
>  include/standard-headers/linux/virtio_gpu.h |  9 +++
>  5 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
> index e06be60dfb..e11ad233eb 100644
> --- a/hw/display/virtio-gpu-gl.c
> +++ b/hw/display/virtio-gpu-gl.c
> @@ -100,7 +100,14 @@ static void virtio_gpu_gl_reset(VirtIODevice *vdev)
>   */
>  if (gl->renderer_inited && !gl->renderer_reset) {
>  virtio_gpu_virgl_reset_scanout(g);
> -gl->renderer_reset = true;
> +/*
> + * If guest is suspending, we shouldn't reset renderer,
> + * otherwise, the display can't come back to the time when
> + * it was suspended after guest resumed.
> + */
> +if (!g->freezing) {
> +gl->renderer_reset = true;
> +}
>  }
>  }
>
> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> index 73cb92c8d5..183ec92d53 100644
> --- a/hw/display/virtio-gpu-virgl.c
> +++ b/hw/display/virtio-gpu-virgl.c
> @@ -464,6 +464,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
>  case VIRTIO_GPU_CMD_GET_EDID:
>  virtio_gpu_get_edid(g, cmd);
>  break;
> +case VIRTIO_GPU_CMD_STATUS_FREEZING:
> +virtio_gpu_cmd_status_freezing(g, cmd);
> +break;
>  default:
>  cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
>  break;
> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> index 5e15c79b94..8f235d7848 100644
> --- a/hw/display/virtio-gpu.c
> +++ b/hw/display/virtio-gpu.c
> @@ -373,6 +373,16 @@ static void virtio_gpu_resource_create_blob(VirtIOGPU
> *g,
>  QTAILQ_INSERT_HEAD(&g->reslist, res, next);
>  }
>
> +void virtio_gpu_cmd_status_freezing(VirtIOGPU *g,
> + struct virtio_gpu_ctrl_command *cmd)
> +{
> +struct virtio_gpu_status_freezing sf;
> +
> +VIRTIO_GPU_FILL_CMD(sf);
> +virtio_gpu_bswap_32(&sf, sizeof(sf));
> +g->freezing = sf.freezing;
> +}
> +
>  static void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id)
>  {
>  struct virtio_gpu_scanout *scanout =
> &g->parent_obj.scanout[scanout_id];
> @@ -986,6 +996,9 @@ void virtio_gpu_simple_process_cmd(VirtIOGPU *g,
>  case VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING:
>  virtio_gpu_resource_detach_backing(g, cmd);
>  break;
> +case VIRTIO_GPU_CMD_STATUS_FREEZING:
> +virtio_gpu_cmd_status_freezing(g, cmd);
> +break;
>  default:
>  cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
>  break;
> @@ -1344,6 +1357,8 @@ void virtio_gpu_device_realize(DeviceState *qdev,
> Error **errp)
>  QTAILQ_INIT(&g->reslist);
>  QTAILQ_INIT(&g->cmdq);
>  QTAILQ_INIT(&g->fenceq);
> +
> +g->freezing = false;
>  }
>
>  void virtio_gpu_reset(VirtIODevice *vdev)
> @@ -1352,8 +1367,15 @@ void virtio_gpu_reset(VirtIODevice *vdev)
>  struct virtio_gpu_simple_resource *res, *tmp;
>  struct virtio_gpu_ctrl_command *cmd;
>
> -QTAILQ_FOREACH_SAFE(res, &g->reslist, next, tmp) {
> -virtio_gpu_resource_destroy(g, res);
> +/*
> + * If guest is suspending, we shouldn't destroy resources,
> + * otherwise, the display can't come back to the time when
> + * it was suspended after guest resumed.
> + */
> +if (!g->freezing) {
> +QTAILQ_FOREACH_SAFE(res, &g->reslist, next, tmp) {
> +virtio_gpu_resource_destroy(g, res);
> +}
>  }
>
>  while (!QTAILQ_EMPTY(&g->cmdq)) {
> diff --git a/include/hw/virtio/virtio-gpu.h
> b/include/hw/virtio/virtio-gpu.h
> index 2e28507efe..c21c2990fb 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -173,6 +173,7 @@ struct VirtIOGPU {
>
>  uint64_t hostmem;
>
> +bool freezing;
>  bool 

Re: [PATCH 2/5] cmd646: create separate header and QOM type for CMD646_IDE

[Bernhard Beschow]

Am 9. Juni 2023 18:51:16 UTC schrieb Mark Cave-Ayland 
:
>This will enable CMD646-specific fields to be added to CMD6464IDEState in
>future.
>
>Signed-off-by: Mark Cave-Ayland 
>---
> hw/ide/cmd646.c |  4 +++-
> include/hw/ide/cmd646.h | 38 ++
> 2 files changed, 41 insertions(+), 1 deletion(-)
> create mode 100644 include/hw/ide/cmd646.h
>
>diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
>index 20f1e41d57..a3e227fba7 100644
>--- a/hw/ide/cmd646.c
>+++ b/hw/ide/cmd646.c
>@@ -33,6 +33,7 @@
> #include "sysemu/reset.h"
> 
> #include "hw/ide/pci.h"
>+#include "hw/ide/cmd646.h"
> #include "trace.h"
> 
> /* CMD646 specific */
>@@ -339,9 +340,10 @@ static void cmd646_ide_class_init(ObjectClass *klass, 
>void *data)
> }
> 
> static const TypeInfo cmd646_ide_info = {
>-.name  = "cmd646-ide",
>+.name  = TYPE_CMD646_IDE,
> .parent= TYPE_PCI_IDE,
> .class_init= cmd646_ide_class_init,
>+.instance_size = sizeof(CMD646IDEState),
> };
> 
> static void cmd646_ide_register_types(void)
>diff --git a/include/hw/ide/cmd646.h b/include/hw/ide/cmd646.h
>new file mode 100644
>index 00..4780b1132c
>--- /dev/null
>+++ b/include/hw/ide/cmd646.h
>@@ -0,0 +1,38 @@
>+/*
>+ * QEMU IDE Emulation: PCI cmd646 support.
>+ *
>+ * Copyright (c) 2003 Fabrice Bellard
>+ * Copyright (c) 2006 Openedhand Ltd.
>+ *
>+ * 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.
>+ */
>+
>+#ifndef HW_IDE_CMD646_H
>+#define HW_IDE_CMD646_H
>+
>+#define TYPE_CMD646_IDE "cmd646-ide"
>+OBJECT_DECLARE_SIMPLE_TYPE(CMD646IDEState, CMD646_IDE)
>+
>+#include "hw/ide/pci.h"
>+
>+struct CMD646IDEState {
>+PCIIDEState parent_obj;

No public / private sections here? From the naming this attribute is often 
considered private and the rest public. I guess what this scheme communicates 
is that `parent_obj` should be accessed via `IDE_PCI()` only.

>+};
>+
>+#endif

Re: [RFC v2 1/6] build: Add configure options for native calls

[Alex Bennée]

Yeqi Fu  writes:

> Signed-off-by: Yeqi Fu 
> ---
>  Makefile|  4 +++
>  common-user/native/Makefile.include |  9 ++
>  common-user/native/Makefile.target  | 22 +
>  configure   | 50 +
>  docs/devel/build-system.rst |  4 +++
>  meson.build |  8 +
>  meson_options.txt   |  2 ++
>  scripts/meson-buildoptions.sh   |  4 +++
>  8 files changed, 103 insertions(+)
>  create mode 100644 common-user/native/Makefile.include
>  create mode 100644 common-user/native/Makefile.target
>
> diff --git a/Makefile b/Makefile
> index 3c7d67142f..923da109bf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -185,6 +185,10 @@ SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory --quiet)
>  
>  include $(SRC_PATH)/tests/Makefile.include
>  
> +ifeq ($(CONFIG_USER_NATIVE),y)
> + include $(SRC_PATH)/common-user/native/Makefile.include
> +endif
> +
>  all: recurse-all
>  
>  ROMS_RULES=$(foreach t, all clean distclean, $(addsuffix /$(t), $(ROMS)))
> diff --git a/common-user/native/Makefile.include 
> b/common-user/native/Makefile.include
> new file mode 100644
> index 00..40d20bcd4c
> --- /dev/null
> +++ b/common-user/native/Makefile.include
> @@ -0,0 +1,9 @@
> +.PHONY: build-native
> +build-native: $(NATIVE_TARGETS:%=build-native-library-%)
> +$(NATIVE_TARGETS:%=build-native-library-%): build-native-library-%:
> + $(call quiet-command, \
> + $(MAKE) -C common-user/native/$* $(SUBDIR_MAKEFLAGS), \
> + "BUILD","$* native library")
> +# endif
> +
> +all: build-native

I think it would be better if we could add the targets via meson and let
it deal with the multiple versions. I will defer to Paolo on how to do
this though.


> diff --git a/common-user/native/Makefile.target 
> b/common-user/native/Makefile.target
> new file mode 100644
> index 00..1038367b37
> --- /dev/null
> +++ b/common-user/native/Makefile.target
> @@ -0,0 +1,22 @@
> +# -*- Mode: makefile -*-
> +#
> +# Library for native calls 
> +#
> +
> +all:
> +-include ../config-host.mak
> +-include config-target.mak
> +
> +CFLAGS+=-I$(SRC_PATH)/include -O1 -fPIC -shared -fno-stack-protector
> +LDFLAGS+=
> +
> +SRC = $(SRC_PATH)/common-user/native/libnative.c
> +TARGET = libnative.so
> +
> +all: $(TARGET)
> +
> +$(TARGET): $(SRC)
> + $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $< -o $@ $(LDFLAGS)
> +
> +clean:
> + rm -f $(TARGET)
> diff --git a/configure b/configure
> index 2a556d14c9..cc94d10c98 100755
> --- a/configure
> +++ b/configure
> @@ -275,6 +275,7 @@ use_containers="yes"
>  gdb_bin=$(command -v "gdb-multiarch" || command -v "gdb")
>  gdb_arches=""
>  werror=""
> +user_native_call="disabled"
>  
>  # Don't accept a target_list environment variable.
>  unset target_list
> @@ -787,6 +788,10 @@ for opt do
>;;
>--disable-vfio-user-server) vfio_user_server="disabled"
>;;
> +  --enable-user-native-call) user_native_call="enabled"
> +  ;;
> +  --disable-user-native-call) user_native_call="disabled"
> +  ;;

I'm not sure it's worth the configuration control here. We can embed if
a given frontend has support for native calls in:

  config/targets/FOO-linux-user.mak

and simply add the symbol when each front end is enabled.

># everything else has the same name in configure and meson
>--*) meson_option_parse "$opt" "$optarg"
>;;
> @@ -1898,6 +1903,50 @@ if test "$tcg" = "enabled"; then
>  fi
>  )
>  
> +# common-user/native configuration
> +native_flag_i386="-DTARGET_I386"
> +native_flag_x86_64="-DTARGET_X86_64"
> +native_flag_mips="-DTARGET_MIPS"
> +native_flag_mips64="-DTARGET_MIPS64"
> +native_flag_arm="-DTARGET_ARM"
> +native_flag_aarch64="-DTARGET_AARCH64"

As we have target names already in the per-target configs we could use
that instead and build the cflags there.

> +
> +(config_host_mak=common-user/native/config-host.mak
> +mkdir -p common-user/native
> +echo "# Automatically generated by configure - do not modify" > 
> $config_host_mak
> +echo "SRC_PATH=$source_path" >> $config_host_mak
> +echo "HOST_CC=$host_cc" >> $config_host_mak
> +
> +native_targets=
> +for target in $target_list; do
> +  arch=${target%%-*}
> +
> +  case $target in
> +*-linux-user|*-bsd-user)
> +if probe_target_compiler $target || test -n "$container_image"; then
> +mkdir -p "common-user/native/$target"
> +config_target_mak=common-user/native/$target/config-target.mak
> +ln -sf "$source_path/common-user/native/Makefile.target" 
> "common-user/native/$target/Makefile"
> +echo "# Automatically generated by configure - do not modify" > 
> "$config_target_mak"
> +echo "TARGET_NAME=$arch" >> "$config_target_mak"
> +echo "TARGET=$target" >> "$config_target_mak"
> +eval "target_native_flag=\${native_flag_$target_arch}"
> +target_cflags="$target_cflags $target_native_flag"
> +write_target_makefile "build-native-library-$target" 

[PATCH v2] Use named constants in BCM props

[Sergey Kambalin]

ping

- PI_FIRMWARE_*_RATE constsnts were moved to raspberrypi-fw-defs.h
  (seems more suitable place for them)
- inclusion of "qemu/osdep.h" has been removed
- year in copyright header has been updated 

Signed-off-by: Sergey Kambalin 
---
 hw/misc/bcm2835_property.c| 120 ++-
 include/hw/arm/raspi_platform.h   |   6 +
 include/hw/misc/raspberrypi-fw-defs.h | 163 ++
 3 files changed, 236 insertions(+), 53 deletions(-)
 create mode 100644 include/hw/misc/raspberrypi-fw-defs.h

diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
index 251b3d865d..871f71fdcd 100644
--- a/hw/misc/bcm2835_property.c
+++ b/hw/misc/bcm2835_property.c
@@ -12,10 +12,12 @@
 #include "migration/vmstate.h"
 #include "hw/irq.h"
 #include "hw/misc/bcm2835_mbox_defs.h"
+#include "hw/misc/raspberrypi-fw-defs.h"
 #include "sysemu/dma.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
 #include "trace.h"
+#include "hw/arm/raspi_platform.h"
 
 /* https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface */
 
@@ -51,48 +53,48 @@ static void bcm2835_property_mbox_push(BCM2835PropertyState 
*s, uint32_t value)
 /* @(value + 8) : Request/response indicator */
 resplen = 0;
 switch (tag) {
-case 0x: /* End tag */
+case RPI_FWREQ_PROPERTY_END: /* End tag */
 break;
-case 0x0001: /* Get firmware revision */
+case RPI_FWREQ_GET_FIRMWARE_REVISION: /* Get firmware revision */
 stl_le_phys(&s->dma_as, value + 12, 346337);
 resplen = 4;
 break;
-case 0x00010001: /* Get board model */
+case RPI_FWREQ_GET_BOARD_MODEL: /* Get board model */
 qemu_log_mask(LOG_UNIMP,
   "bcm2835_property: 0x%08x get board model NYI\n",
   tag);
 resplen = 4;
 break;
-case 0x00010002: /* Get board revision */
+case RPI_FWREQ_GET_BOARD_REVISION: /* Get board revision */
 stl_le_phys(&s->dma_as, value + 12, s->board_rev);
 resplen = 4;
 break;
-case 0x00010003: /* Get board MAC address */
+case RPI_FWREQ_GET_BOARD_MAC_ADDRESS: /* Get board MAC address */
 resplen = sizeof(s->macaddr.a);
 dma_memory_write(&s->dma_as, value + 12, s->macaddr.a, resplen,
  MEMTXATTRS_UNSPECIFIED);
 break;
-case 0x00010004: /* Get board serial */
+case RPI_FWREQ_GET_BOARD_SERIAL: /* Get board serial */
 qemu_log_mask(LOG_UNIMP,
   "bcm2835_property: 0x%08x get board serial NYI\n",
   tag);
 resplen = 8;
 break;
-case 0x00010005: /* Get ARM memory */
+case RPI_FWREQ_GET_ARM_MEMORY: /* Get ARM memory */
 /* base */
 stl_le_phys(&s->dma_as, value + 12, 0);
 /* size */
 stl_le_phys(&s->dma_as, value + 16, s->fbdev->vcram_base);
 resplen = 8;
 break;
-case 0x00010006: /* Get VC memory */
+case RPI_FWREQ_GET_VC_MEMORY: /* Get VC memory */
 /* base */
 stl_le_phys(&s->dma_as, value + 12, s->fbdev->vcram_base);
 /* size */
 stl_le_phys(&s->dma_as, value + 16, s->fbdev->vcram_size);
 resplen = 8;
 break;
-case 0x00028001: /* Set power state */
+case RPI_FWREQ_SET_POWER_STATE: /* Set power state */
 /* Assume that whatever device they asked for exists,
  * and we'll just claim we set it to the desired state
  */
@@ -103,38 +105,42 @@ static void 
bcm2835_property_mbox_push(BCM2835PropertyState *s, uint32_t value)
 
 /* Clocks */
 
-case 0x00030001: /* Get clock state */
+case RPI_FWREQ_GET_CLOCK_STATE: /* Get clock state */
 stl_le_phys(&s->dma_as, value + 16, 0x1);
 resplen = 8;
 break;
 
-case 0x00038001: /* Set clock state */
+case RPI_FWREQ_SET_CLOCK_STATE: /* Set clock state */
 qemu_log_mask(LOG_UNIMP,
   "bcm2835_property: 0x%08x set clock state NYI\n",
   tag);
 resplen = 8;
 break;
 
-case 0x00030002: /* Get clock rate */
-case 0x00030004: /* Get max clock rate */
-case 0x00030007: /* Get min clock rate */
+case RPI_FWREQ_GET_CLOCK_RATE: /* Get clock rate */
+case RPI_FWREQ_GET_MAX_CLOCK_RATE: /* Get max clock rate */
+case RPI_FWREQ_GET_MIN_CLOCK_RATE: /* Get min clock rate */
 switch (ldl_le_phys(&s->dma_as, value + 12)) {
-case 1: /* EMMC */
-stl_le_phys(&s->dma_as, value + 16, 5000);
+case RPI_FIRMWARE_EMMC_CLK_ID: /* EMMC */
+stl_le_phys(&s->dma_as, value + 16, 
RPI_FIRM

Re: [Libguestfs] [PATCH v4 02/24] nbd: Consistent typedef usage in header

[Vladimir Sementsov-Ogievskiy]

On 08.06.23 17:17, Eric Blake wrote:

On Thu, Jun 08, 2023 at 08:56:31AM -0500, Eric Blake wrote:

We had a mix of struct declarataions followed by typedefs, and direct


declarations


struct definitions as part of a typedef.  Pick a single style.  Also
float a couple of opaque typedefs earlier in the file, as a later
patch wants to refer NBDExport* in NBDRequest.  No semantic impact.


The curse of writing a commit message and then rebasing to a different
idea; in patch 22, I had originally intended to make NBDMetaContexts a
concrete type in nbd.h (which depends on NBDExport*, and would be
directly used in NBDRequest, which in turn is declared before the
pre-patch mention of NBDExport), but then changed my mind to instead
have NBDMetaContexts itself also be an opaque type with NBDRequest
only using NBDMetaContexts*.  And I missed floating the typedef for
NBDClientConnection to the same point, because we somewhat separated
opaque types along the lines of which .c files provide various
functions and opaque types.


@@ -26,24 +26,25 @@
  #include "qapi/error.h"
  #include "qemu/bswap.h"

+typedef struct NBDExport NBDExport;
+typedef struct NBDClient NBDClient;
+


Preferences on how I should tweak that aspect of this patch?  Options:

- Don't float NBDExport or NBDClient, and drop that part of the commit
   message.  However, the later patch that adds the typedef for
   NBDMetaContexts still has to do it earlier than the definition of
   NBDRequest, rather than alongside the other opaque types relevant to
   server.c

- Also float NBDClientConnection up here, and reword the commit
   message along the lines of: Also float forward declarations of
   opaque types to the top of the file, rather than interspersed with
   function declarations, which will help a future patch that wants to
   expose yet another opaque type that will be referenced in
   NBDRequest.


Sounds good to me. Anyway:
Reviewed-by: Vladimir Sementsov-Ogievskiy 



- something else?



--
Best regards,
Vladimir

Re: [PATCH v2 2/8] target/riscv: Factor out extension tests to cpu_cfg.h

[LIU Zhiwei]

On 2023/6/12 19:10, Christoph Muellner wrote:

From: Christoph Müllner 

This patch moves the extension test functions that are used
to gate vendor extension decoders, into cpu_cfg.h.
This allows to reuse them in the disassembler.

This patch does not introduce new functionality.
However, the patch includes a small change:
The parameter for the extension test functions has been changed
from 'DisasContext*' to 'const RISCVCPUConfig*' to keep
the code in cpu_cfg.h self-contained.

Signed-off-by: Christoph Müllner 


Reviewed-by: LIU Zhiwei 

Zhiwei


---
  target/riscv/cpu_cfg.h   | 26 ++
  target/riscv/translate.c | 27 ++-
  2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
index c4a627d335..0b4fe4b540 100644
--- a/target/riscv/cpu_cfg.h
+++ b/target/riscv/cpu_cfg.h
@@ -133,4 +133,30 @@ struct RISCVCPUConfig {
  };
  
  typedef struct RISCVCPUConfig RISCVCPUConfig;

+
+/* Helper functions to test for extensions.  */
+
+static inline bool always_true_p(const RISCVCPUConfig *cfg 
__attribute__((__unused__)))
+{
+return true;
+}
+
+static inline bool has_xthead_p(const RISCVCPUConfig *cfg)
+{
+return cfg->ext_xtheadba || cfg->ext_xtheadbb ||
+   cfg->ext_xtheadbs || cfg->ext_xtheadcmo ||
+   cfg->ext_xtheadcondmov ||
+   cfg->ext_xtheadfmemidx || cfg->ext_xtheadfmv ||
+   cfg->ext_xtheadmac || cfg->ext_xtheadmemidx ||
+   cfg->ext_xtheadmempair || cfg->ext_xtheadsync;
+}
+
+#define MATERIALISE_EXT_PREDICATE(ext) \
+static inline bool has_ ## ext ## _p(const RISCVCPUConfig *cfg) \
+{ \
+return cfg->ext_ ## ext ; \
+}
+
+MATERIALISE_EXT_PREDICATE(XVentanaCondOps)
+
  #endif
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 859d5b2dcf..275b922811 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -119,29 +119,6 @@ static inline bool has_ext(DisasContext *ctx, uint32_t ext)
  return ctx->misa_ext & ext;
  }
  
-static bool always_true_p(DisasContext *ctx  __attribute__((__unused__)))

-{
-return true;
-}
-
-static bool has_xthead_p(DisasContext *ctx  __attribute__((__unused__)))
-{
-return ctx->cfg_ptr->ext_xtheadba || ctx->cfg_ptr->ext_xtheadbb ||
-   ctx->cfg_ptr->ext_xtheadbs || ctx->cfg_ptr->ext_xtheadcmo ||
-   ctx->cfg_ptr->ext_xtheadcondmov ||
-   ctx->cfg_ptr->ext_xtheadfmemidx || ctx->cfg_ptr->ext_xtheadfmv ||
-   ctx->cfg_ptr->ext_xtheadmac || ctx->cfg_ptr->ext_xtheadmemidx ||
-   ctx->cfg_ptr->ext_xtheadmempair || ctx->cfg_ptr->ext_xtheadsync;
-}
-
-#define MATERIALISE_EXT_PREDICATE(ext)  \
-static bool has_ ## ext ## _p(DisasContext *ctx)\
-{ \
-return ctx->cfg_ptr->ext_ ## ext ; \
-}
-
-MATERIALISE_EXT_PREDICATE(XVentanaCondOps);
-
  #ifdef TARGET_RISCV32
  #define get_xl(ctx)MXL_RV32
  #elif defined(CONFIG_USER_ONLY)
@@ -1132,7 +1109,7 @@ static void decode_opc(CPURISCVState *env, DisasContext 
*ctx, uint16_t opcode)
   * that are tested in-order until a decoder matches onto the opcode.
   */
  static const struct {
-bool (*guard_func)(DisasContext *);
+bool (*guard_func)(const RISCVCPUConfig *);
  bool (*decode_func)(DisasContext *, uint32_t);
  } decoders[] = {
  { always_true_p,  decode_insn32 },
@@ -1161,7 +1138,7 @@ static void decode_opc(CPURISCVState *env, DisasContext 
*ctx, uint16_t opcode)
  ctx->opcode = opcode32;
  
  for (size_t i = 0; i < ARRAY_SIZE(decoders); ++i) {

-if (decoders[i].guard_func(ctx) &&
+if (decoders[i].guard_func(ctx->cfg_ptr) &&
  decoders[i].decode_func(ctx, opcode32)) {
  return;
  }

Re: [PATCH 6/9] target/riscv/cpu: Share RISCVCPUConfig with disassembler

[LIU Zhiwei]

On 2023/6/12 18:04, Christoph Müllner wrote:

On Mon, Jun 12, 2023 at 12:01 PM LIU Zhiwei  wrote:


On 2023/6/12 17:47, Christoph Müllner wrote:

On Mon, Jun 12, 2023 at 8:25 AM LIU Zhiwei  wrote:

On 2023/5/30 21:18, Christoph Muellner wrote:

From: Christoph Müllner 

The disassembler needs the available extensions in order
to properly decode instructions in case of overlapping
encodings (e.g. for vendor extensions).

Let's use the field 'disassemble_info::private_data' to store
our RISCVCPUConfig pointer.

Signed-off-by: Christoph Müllner 
---
target/riscv/cpu.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 5b7818dbd1..6f0cd9a0bb 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -819,6 +819,9 @@ static void riscv_cpu_disas_set_info(CPUState *s, 
disassemble_info *info)
{
RISCVCPU *cpu = RISCV_CPU(s);
CPURISCVState *env = &cpu->env;
+RISCVCPUConfig *cfg = &cpu->cfg;
+
+info->private_data = cfg;

I don't know if this field will be overridden by the binutils. Can we
extend the struct disassemble_info, and add some fields like supporting
for Capstone?

Initially I wanted to add a new field, but then I noticed that the field
'disassemble_info::private_data' is used for a similar purpose by
disas/cris.c, disas/m68k.c, and dias/xtensa.c.
So I decided to not add yet another field, which only serves one architecture.

I think you can CC these arch maintainers to see if it need some
specially process before using the private_data.

But if that's the preferred way, then I can change.

I prefer this way, but not insist on  if it really works using the
private_data.

This topic is already resolved by using the field 'info->target_info'.
So I dropped this patch anyway.


OK. I remembered I also used this field to pass the ISA information in 
the multi-path disassemble patch set.


Zhiwei



BR
Christoph


Zhiwei


Thanks
Christoph


Zhiwei


switch (env->xl) {
case MXL_RV32:

[PATCH 0/4] TriCore bugfixes

[Bastian Koppelmann]

Hi,

this series fixes a bunch of TriCore issues on the bugtracker.

Cheers,
Bastian

Bastian Koppelmann (3):
  target/tricore: Correctly fix saving PSW.CDE to CSA on call
  target/tricore: Add CHECK_REG_PAIR() for insn accessing 64 bit regs
  target/tricore: Fix helper_ret() not correctly restoring PSW

Siqi Chen (1):
  target/tricore: Fix out-of-bounds index in imask instruction

 target/tricore/op_helper.c | 15 ++-
 target/tricore/translate.c | 12 ++--
 2 files changed, 20 insertions(+), 7 deletions(-)

-- 
2.40.1

[PATCH 2/4] target/tricore: Correctly fix saving PSW.CDE to CSA on call

[Bastian Koppelmann]

we don't want to save PSW.CDC to the CSA, but PSW.CDE must be saved.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1699
Signed-off-by: Bastian Koppelmann 
---
 target/tricore/op_helper.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/target/tricore/op_helper.c b/target/tricore/op_helper.c
index 54f54811d9..d3c836ecd9 100644
--- a/target/tricore/op_helper.c
+++ b/target/tricore/op_helper.c
@@ -2447,7 +2447,12 @@ void helper_call(CPUTriCoreState *env, uint32_t next_pc)
 }
 /* PSW.CDE = 1;*/
 psw |= MASK_PSW_CDE;
-psw_write(env, psw);
+/*
+ * we need to save PSW.CDE and not PSW.CDC into the CSAs. psw already
+ * contains the CDC from cdc_increment(), so we cannot call psw_write()
+ * here.
+ */
+env->PSW |= MASK_PSW_CDE;
 
 /* tmp_FCX = FCX; */
 tmp_FCX = env->FCX;
-- 
2.40.1

[PATCH 4/4] target/tricore: Fix helper_ret() not correctly restoring PSW

[Bastian Koppelmann]

We are always taking the TRICORE_FEATURE_13 branch as every CPU has 
TRICORE_FEATURE_13.
For CPUs with ISA > 1.3 we have to take the else branch.

We fix this by inverting the condition. We check for
TRICORE_FEATURE_131, which every CPU except TRICORE_FEATURE_13 CPUs
have.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1700
Signed-off-by: Bastian Koppelmann 
---
 target/tricore/op_helper.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/tricore/op_helper.c b/target/tricore/op_helper.c
index d3c836ecd9..cbc46b2a5f 100644
--- a/target/tricore/op_helper.c
+++ b/target/tricore/op_helper.c
@@ -2532,12 +2532,12 @@ void helper_ret(CPUTriCoreState *env)
 /* PCXI = new_PCXI; */
 env->PCXI = new_PCXI;
 
-if (tricore_feature(env, TRICORE_FEATURE_13)) {
-/* PSW = new_PSW */
-psw_write(env, new_PSW);
-} else {
+if (tricore_feature(env, TRICORE_FEATURE_131)) {
 /* PSW = {new_PSW[31:26], PSW[25:24], new_PSW[23:0]}; */
 psw_write(env, (new_PSW & ~(0x300)) + (psw & (0x300)));
+} else { /* TRICORE_FEATURE_13 only */
+/* PSW = new_PSW */
+psw_write(env, new_PSW);
 }
 }
 
-- 
2.40.1

[PATCH 3/4] target/tricore: Add CHECK_REG_PAIR() for insn accessing 64 bit regs

[Bastian Koppelmann]

some insns were not checking if an even index was used to access a 64
bit register. In the worst case that could lead to a buffer overflow as
reported in https://gitlab.com/qemu-project/qemu/-/issues/1698.

Reported-by: Siqi Chen 
Signed-off-by: Bastian Koppelmann 
---
 target/tricore/translate.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/target/tricore/translate.c b/target/tricore/translate.c
index 3b8d3f53ee..2a947e9bd5 100644
--- a/target/tricore/translate.c
+++ b/target/tricore/translate.c
@@ -309,6 +309,7 @@ static void gen_cmpswap(DisasContext *ctx, int reg, TCGv ea)
 {
 TCGv temp = tcg_temp_new();
 TCGv temp2 = tcg_temp_new();
+CHECK_REG_PAIR(reg);
 tcg_gen_qemu_ld_tl(temp, ea, ctx->mem_idx, MO_LEUL);
 tcg_gen_movcond_tl(TCG_COND_EQ, temp2, cpu_gpr_d[reg+1], temp,
cpu_gpr_d[reg], temp);
@@ -321,7 +322,7 @@ static void gen_swapmsk(DisasContext *ctx, int reg, TCGv ea)
 TCGv temp = tcg_temp_new();
 TCGv temp2 = tcg_temp_new();
 TCGv temp3 = tcg_temp_new();
-
+CHECK_REG_PAIR(reg);
 tcg_gen_qemu_ld_tl(temp, ea, ctx->mem_idx, MO_LEUL);
 tcg_gen_and_tl(temp2, cpu_gpr_d[reg], cpu_gpr_d[reg+1]);
 tcg_gen_andc_tl(temp3, temp, cpu_gpr_d[reg+1]);
@@ -3219,6 +3220,7 @@ static void decode_src_opc(DisasContext *ctx, int op1)
 break;
 case OPC1_16_SRC_MOV_E:
 if (has_feature(ctx, TRICORE_FEATURE_16)) {
+CHECK_REG_PAIR(r1);
 tcg_gen_movi_tl(cpu_gpr_d[r1], const4);
 tcg_gen_sari_tl(cpu_gpr_d[r1+1], cpu_gpr_d[r1], 31);
 } else {
@@ -6172,6 +6174,7 @@ static void decode_rr_divide(DisasContext *ctx)
 tcg_gen_sari_tl(cpu_gpr_d[r3+1], cpu_gpr_d[r1], 31);
 break;
 case OPC2_32_RR_DVINIT_U:
+CHECK_REG_PAIR(r3);
 /* overflow = (D[b] == 0) */
 tcg_gen_setcondi_tl(TCG_COND_EQ, cpu_PSW_V, cpu_gpr_d[r2], 0);
 tcg_gen_shli_tl(cpu_PSW_V, cpu_PSW_V, 31);
@@ -6200,6 +6203,7 @@ static void decode_rr_divide(DisasContext *ctx)
 break;
 case OPC2_32_RR_DIV:
 if (has_feature(ctx, TRICORE_FEATURE_16)) {
+CHECK_REG_PAIR(r3);
 GEN_HELPER_RR(divide, cpu_gpr_d[r3], cpu_gpr_d[r3+1], 
cpu_gpr_d[r1],
   cpu_gpr_d[r2]);
 } else {
@@ -6208,6 +6212,7 @@ static void decode_rr_divide(DisasContext *ctx)
 break;
 case OPC2_32_RR_DIV_U:
 if (has_feature(ctx, TRICORE_FEATURE_16)) {
+CHECK_REG_PAIR(r3);
 GEN_HELPER_RR(divide_u, cpu_gpr_d[r3], cpu_gpr_d[r3+1],
   cpu_gpr_d[r1], cpu_gpr_d[r2]);
 } else {
@@ -6734,6 +6739,8 @@ static void decode_rrr2_msub(DisasContext *ctx)
  cpu_gpr_d[r3], cpu_gpr_d[r3+1], cpu_gpr_d[r2]);
 break;
 case OPC2_32_RRR2_MSUB_U_64:
+CHECK_REG_PAIR(r4);
+CHECK_REG_PAIR(r3);
 gen_msubu64_d(cpu_gpr_d[r4], cpu_gpr_d[r4+1], cpu_gpr_d[r1],
   cpu_gpr_d[r3], cpu_gpr_d[r3+1], cpu_gpr_d[r2]);
 break;
@@ -7817,7 +7824,7 @@ static void decode_rrrw_extract_insert(DisasContext *ctx)
 break;
 case OPC2_32_RRRW_IMASK:
 temp2 = tcg_temp_new();
-
+CHECK_REG_PAIR(r4);
 tcg_gen_andi_tl(temp, cpu_gpr_d[r3], 0x1f);
 tcg_gen_movi_tl(temp2, (1 << width) - 1);
 tcg_gen_shl_tl(temp2, temp2, temp);
-- 
2.40.1

[PATCH 1/4] target/tricore: Fix out-of-bounds index in imask instruction

[Bastian Koppelmann]

From: Siqi Chen 

When translating  "imask" instruction of Tricore architecture, QEMU did not 
check whether the register index was out of bounds, resulting in a 
global-buffer-overflow.

Reviewed-by: Bastian Koppelmann 
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1698
Reported-by: Siqi Chen 
Signed-off-by: Siqi Chen 
Message-Id: <20230612065633.149152-1-coc.c...@gmail.com>
---
 target/tricore/translate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/tricore/translate.c b/target/tricore/translate.c
index cd33a1dcdd..3b8d3f53ee 100644
--- a/target/tricore/translate.c
+++ b/target/tricore/translate.c
@@ -5331,6 +5331,7 @@ static void decode_rcrw_insert(DisasContext *ctx)
 
 switch (op2) {
 case OPC2_32_RCRW_IMASK:
+CHECK_REG_PAIR(r4);
 tcg_gen_andi_tl(temp, cpu_gpr_d[r3], 0x1f);
 tcg_gen_movi_tl(temp2, (1 << width) - 1);
 tcg_gen_shl_tl(cpu_gpr_d[r4 + 1], temp2, temp);
-- 
2.40.1