Re: [PATCH 9/9] contrib/plugins: add ips plugin example for cost modeling
vcpu->total_insn += vcpu->quantum_insn;
> +vcpu->quantum_insn = 0;
> +vcpu->last_quantum_time = now_ns();
> +
> +/* based on total number of instructions, what should be the new time? */
> +int64_t new_virtual_time = time_for_insn(vcpu->total_insn);
> +
> +g_mutex_lock(_state_lock);
> +
> +/* Time only moves forward. Another vcpu might have updated it already.
> */
> +if (new_virtual_time > virtual_time_ns) {
> +qemu_plugin_update_ns(time_handle, new_virtual_time);
> +virtual_time_ns = new_virtual_time;
> +}
> +
> +g_mutex_unlock(_state_lock);
> +}
> +
> +static void vcpu_init(qemu_plugin_id_t id, unsigned int cpu_index)
> +{
> +vCPUTime *vcpu = qemu_plugin_scoreboard_find(vcpus, cpu_index);
> +vcpu->total_insn = 0;
> +vcpu->quantum_insn = 0;
> +vcpu->last_quantum_time = now_ns();
> +}
> +
> +static void vcpu_exit(qemu_plugin_id_t id, unsigned int cpu_index)
> +{
> +vCPUTime *vcpu = qemu_plugin_scoreboard_find(vcpus, cpu_index);
> +update_system_time(vcpu);
> +}
> +
> +static void every_quantum_insn(unsigned int cpu_index, void *udata)
> +{
> +vCPUTime *vcpu = qemu_plugin_scoreboard_find(vcpus, cpu_index);
> +g_assert(vcpu->quantum_insn >= max_insn_per_quantum);
> +update_system_time(vcpu);
> +}
> +
> +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
> +{
> +size_t n_insns = qemu_plugin_tb_n_insns(tb);
> +qemu_plugin_u64 quantum_insn =
> +qemu_plugin_scoreboard_u64_in_struct(vcpus, vCPUTime, quantum_insn);
> +/* count (and eventually trap) once per tb */
> +qemu_plugin_register_vcpu_tb_exec_inline_per_vcpu(
> +tb, QEMU_PLUGIN_INLINE_ADD_U64, quantum_insn, n_insns);
> +qemu_plugin_register_vcpu_tb_exec_cond_cb(
> +tb, every_quantum_insn,
> +QEMU_PLUGIN_CB_NO_REGS, QEMU_PLUGIN_COND_GE,
> +quantum_insn, max_insn_per_quantum, NULL);
> +}
> +
> +static void plugin_exit(qemu_plugin_id_t id, void *udata)
> +{
> +qemu_plugin_scoreboard_free(vcpus);
> +}
> +
> +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
> + const qemu_info_t *info, int argc,
> + char **argv)
> +{
> +for (int i = 0; i < argc; i++) {
> +char *opt = argv[i];
> +g_auto(GStrv) tokens = g_strsplit(opt, "=", 2);
> +if (g_strcmp0(tokens[0], "ips") == 0) {
> +max_insn_per_second = g_ascii_strtoull(tokens[1], NULL, 10);
> +if (!max_insn_per_second && errno) {
> +fprintf(stderr, "%s: couldn't parse %s (%s)\n",
> +__func__, tokens[1], g_strerror(errno));
> +return -1;
> +}
> +} else {
> +fprintf(stderr, "option parsing failed: %s\n", opt);
> +return -1;
> +}
> +}
> +
> +vcpus = qemu_plugin_scoreboard_new(sizeof(vCPUTime));
> +max_insn_per_quantum = max_insn_per_second / NUM_TIME_UPDATE_PER_SEC;
> +
> +time_handle = qemu_plugin_request_time_control();
> + g_assert(time_handle);
> +
> +qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
> +qemu_plugin_register_vcpu_init_cb(id, vcpu_init);
> +qemu_plugin_register_vcpu_exit_cb(id, vcpu_exit);
> +qemu_plugin_register_atexit_cb(id, plugin_exit, NULL);
> +
> +return 0;
> +}
> diff --git a/contrib/plugins/Makefile b/contrib/plugins/Makefile
> index 0b64d2c1e3..449ead1130 100644
> --- a/contrib/plugins/Makefile
> +++ b/contrib/plugins/Makefile
> @@ -27,6 +27,7 @@ endif
> NAMES += hwprofile
> NAMES += cache
> NAMES += drcov
> +NAMES += ips
>
> ifeq ($(CONFIG_WIN32),y)
> SO_SUFFIX := .dll
> --
> 2.39.2
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: Examining device state via monitor for debugging (was: [PATCH 0/2] hw/misc/mos6522: Do not open-code hmp_info_human_readable_text())
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 11 Jun 2024 at 06:50, Markus Armbruster wrote: > > > > Philippe Mathieu-Daudé writes: > > > > > Officialise the QMP command, use the existing > > > hmp_info_human_readable_text() helper. > > > > I'm not sure "officialise" is a word :) > > > > Taking a step back... "info via" and its new QMP counterpart > > x-query-mos6522-devices dump device state. I understand why examining > > device state via monitor can be useful for debugging. However, we have > > more than 2000 devices in the tree. Clearly, we don't want 2000 device > > state queries. Not even 100. Could we have more generic means instead? > > > > We could use QOM (read-only) properties to expose device state. > > > > If we use one QOM property per "thing", examining device state becomes > > quite tedious. Also, you'd have to stop the guest to get a consistent > > view, and adding lots of QOM properties bloats the code. > > > > If we use a single, object-valued property for the entire state, we get > > to define the objects in QAPI. Differently tedious, and bloats the > > generated code. > > We already have a machine readable mandatory-for-every-device > representation of its entire state -- it's the vmstate struct. > Admittedly this is sometimes a bit different from the guest-facing > view of a device and we don't machine-record the field names... vmstate might not contain everything needed for debug; devices do a lot of fiddling to create a consistent vmstate, and there may be more that someone debugging wants (e.g. fd's or host memory addresses). It's also hopelessly cryptic. From an HMP point, a 'info debug ' seems good to me, possibly with some options as to whether to recurse or perhaps add flags to 'info qtree' to also call it. Dave > -- PMM -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH 1/3] hw/s390x: Declare target specific monitor commands in hmp-target.h
* Philippe Mathieu-Daudé (phi...@linaro.org) wrote: > "monitor/hmp-target.h" is meant to hold target-specific commands. > Move s390x specific commands there, slightly simplifying hmp-target.c. > > Signed-off-by: Philippe Mathieu-Daudé > --- > include/hw/s390x/storage-attributes.h | 4 > include/hw/s390x/storage-keys.h | 4 > include/monitor/hmp-target.h | 5 + > hw/s390x/s390-skeys.c | 2 ++ > hw/s390x/s390-stattrib.c | 2 ++ > monitor/hmp-target.c | 5 - > 6 files changed, 9 insertions(+), 13 deletions(-) > > diff --git a/include/hw/s390x/storage-attributes.h > b/include/hw/s390x/storage-attributes.h > index 8921a04d51..4916c75936 100644 > --- a/include/hw/s390x/storage-attributes.h > +++ b/include/hw/s390x/storage-attributes.h > @@ -13,7 +13,6 @@ > #define S390_STORAGE_ATTRIBUTES_H > > #include "hw/qdev-core.h" > -#include "monitor/monitor.h" > #include "qom/object.h" > > #define TYPE_S390_STATTRIB "s390-storage_attributes" > @@ -73,7 +72,4 @@ static inline Object *kvm_s390_stattrib_create(void) > } > #endif > > -void hmp_info_cmma(Monitor *mon, const QDict *qdict); > -void hmp_migrationmode(Monitor *mon, const QDict *qdict); > - > #endif /* S390_STORAGE_ATTRIBUTES_H */ > diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h > index aa2ec2aae5..1d9b7ead44 100644 > --- a/include/hw/s390x/storage-keys.h > +++ b/include/hw/s390x/storage-keys.h > @@ -13,7 +13,6 @@ > #define S390_STORAGE_KEYS_H > > #include "hw/qdev-core.h" > -#include "monitor/monitor.h" > #include "qom/object.h" > > #define TYPE_S390_SKEYS "s390-skeys" > @@ -114,7 +113,4 @@ void s390_skeys_init(void); > > S390SKeysState *s390_get_skeys_device(void); > > -void hmp_dump_skeys(Monitor *mon, const QDict *qdict); > -void hmp_info_skeys(Monitor *mon, const QDict *qdict); > - > #endif /* S390_STORAGE_KEYS_H */ > diff --git a/include/monitor/hmp-target.h b/include/monitor/hmp-target.h > index b679aaebbf..024cff0052 100644 > --- a/include/monitor/hmp-target.h > +++ b/include/monitor/hmp-target.h > @@ -61,4 +61,9 @@ void hmp_gva2gpa(Monitor *mon, const QDict *qdict); > void hmp_gpa2hva(Monitor *mon, const QDict *qdict); > void hmp_gpa2hpa(Monitor *mon, const QDict *qdict); > > +void hmp_dump_skeys(Monitor *mon, const QDict *qdict); > +void hmp_info_skeys(Monitor *mon, const QDict *qdict); > +void hmp_info_cmma(Monitor *mon, const QDict *qdict); > +void hmp_migrationmode(Monitor *mon, const QDict *qdict); > + Could you please add a comment here saying that these are all s390, since it's not obvious from their names. (and if we're lucky the other s390 commands will stay with them). Dave > #endif /* MONITOR_HMP_TARGET_H */ > diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c > index 5c535d483e..7b2ccb94a5 100644 > --- a/hw/s390x/s390-skeys.c > +++ b/hw/s390x/s390-skeys.c > @@ -23,6 +23,8 @@ > #include "sysemu/kvm.h" > #include "migration/qemu-file-types.h" > #include "migration/register.h" > +#include "monitor/hmp-target.h" > +#include "monitor/monitor.h" > > #define S390_SKEYS_BUFFER_SIZE (128 * KiB) /* Room for 128k storage keys */ > #define S390_SKEYS_SAVE_FLAG_EOS 0x01 > diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c > index c4259b5327..9b4b8d8d0c 100644 > --- a/hw/s390x/s390-stattrib.c > +++ b/hw/s390x/s390-stattrib.c > @@ -19,6 +19,8 @@ > #include "exec/ram_addr.h" > #include "qapi/error.h" > #include "qapi/qmp/qdict.h" > +#include "monitor/hmp-target.h" > +#include "monitor/monitor.h" > #include "cpu.h" > > /* 512KiB cover 2GB of guest memory */ > diff --git a/monitor/hmp-target.c b/monitor/hmp-target.c > index 1eb72ac1bf..0466474354 100644 > --- a/monitor/hmp-target.c > +++ b/monitor/hmp-target.c > @@ -36,11 +36,6 @@ > #include "qapi/error.h" > #include "qemu/cutils.h" > > -#if defined(TARGET_S390X) > -#include "hw/s390x/storage-keys.h" > -#include "hw/s390x/storage-attributes.h" > -#endif > - > /* Make devices configuration available for use in hmp-commands*.hx > templates */ > #include CONFIG_DEVICES > > -- > 2.41.0 > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH] monitor: Remove obsolete stubs
* Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> hmp_info_roms() was removed in commit dd98234c05 ("qapi:
> introduce x-query-roms QMP command"),
>
> hmp_info_numa() in commit 1b8ae799d8 ("qapi: introduce
> x-query-numa QMP command"),
>
> hmp_info_ramblock() in commit ca411b7c8a ("qapi: introduce
> x-query-ramblock QMP command")
>
> and hmp_info_irq() in commit 91f2fa7045 ("qapi: introduce
> x-query-irq QMP command").
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Dr. David Alan Gilbert
> ---
> Note x-query-roms is used as example in
> docs/devel/writing-monitor-commands.rst
> but was removed in commit dd98234c05
> ("qapi: introduce x-query-roms QMP command").
> ---
> include/hw/loader.h | 1 -
> include/monitor/hmp.h | 3 ---
> 2 files changed, 4 deletions(-)
>
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 8685e27334..9844c5e3cf 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -338,7 +338,6 @@ void *rom_ptr(hwaddr addr, size_t size);
> * rom_ptr().
> */
> void *rom_ptr_for_as(AddressSpace *as, hwaddr addr, size_t size);
> -void hmp_info_roms(Monitor *mon, const QDict *qdict);
>
> #define rom_add_file_fixed(_f, _a, _i) \
> rom_add_file(_f, NULL, _a, _i, false, NULL, NULL)
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 954f3c83ad..ae116d9804 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -35,7 +35,6 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict);
> void hmp_info_vnc(Monitor *mon, const QDict *qdict);
> void hmp_info_spice(Monitor *mon, const QDict *qdict);
> void hmp_info_balloon(Monitor *mon, const QDict *qdict);
> -void hmp_info_irq(Monitor *mon, const QDict *qdict);
> void hmp_info_pic(Monitor *mon, const QDict *qdict);
> void hmp_info_pci(Monitor *mon, const QDict *qdict);
> void hmp_info_tpm(Monitor *mon, const QDict *qdict);
> @@ -102,7 +101,6 @@ void hmp_chardev_send_break(Monitor *mon, const QDict
> *qdict);
> void hmp_object_add(Monitor *mon, const QDict *qdict);
> void hmp_object_del(Monitor *mon, const QDict *qdict);
> void hmp_info_memdev(Monitor *mon, const QDict *qdict);
> -void hmp_info_numa(Monitor *mon, const QDict *qdict);
> void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
> void hmp_qom_list(Monitor *mon, const QDict *qdict);
> void hmp_qom_get(Monitor *mon, const QDict *qdict);
> @@ -141,7 +139,6 @@ void hmp_rocker_ports(Monitor *mon, const QDict *qdict);
> void hmp_rocker_of_dpa_flows(Monitor *mon, const QDict *qdict);
> void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict *qdict);
> void hmp_info_dump(Monitor *mon, const QDict *qdict);
> -void hmp_info_ramblock(Monitor *mon, const QDict *qdict);
> void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
> void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
> void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
> --
> 2.41.0
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 0/7] Remove some unused structures
* Dr. David Alan Gilbert (d...@treblig.org) wrote: > A bunch of structs that are currently unused, > found with a simple script and a bit of eyeballing. > > The only one I'm that suspicious of is the SPARC > one, where the patch which removed the use is a bit > confusing to me. Copying in Trivial; I think there are 4 of these that are still outstanding: [PATCH 1/7] linux-user: cris: Remove unused struct 'rt_signal_frame' (Although cris is going) [PATCH 3/7] linux-user: sparc: Remove unused struct 'target_mc_fq' [PATCH 5/7] hw/arm/bcm2836: Remove unusued struct 'BCM283XClass' [PATCH 7/7] net/can: Remove unused struct 'CanBusState' Can Trivial pick these up please? Dave > Tested with a > > --target-list=ppc-softmmu,m68k-softmmu,x86_64-softmmu,arm-softmmu,aarch64-softmmu,cris-linux-user,i386-linux-user,sparc-linux-user > and 'make check' on x86 linux. > > Dave > > Dr. David Alan Gilbert (7): > linux-user: cris: Remove unused struct 'rt_signal_frame' > linux-user: i386/signal: Remove unused fp structs > linux-user: sparc: Remove unused struct 'target_mc_fq' > hw/usb/dev-network: Remove unused struct 'rndis_config_parameter' > hw/arm/bcm2836: Remove unusued struct 'BCM283XClass' > target/ppc: Remove unused struct 'mmu_ctx_hash32' > net/can: Remove unused struct 'CanBusState' > > hw/arm/bcm2836.c | 12 > hw/usb/dev-network.c | 8 > linux-user/cris/signal.c | 8 > linux-user/i386/signal.c | 10 -- > linux-user/sparc/signal.c | 5 - > net/can/can_host.c| 6 -- > target/ppc/mmu-hash32.c | 6 -- > 7 files changed, 55 deletions(-) > > -- > 2.45.0 > > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
* Peter Xu (pet...@redhat.com) wrote: > Hey, Dave! Hey! > On Wed, Jun 05, 2024 at 12:31:56AM +0000, Dr. David Alan Gilbert wrote: > > * Michael Galaxy (mgal...@akamai.com) wrote: > > > One thing to keep in mind here (despite me not having any hardware to > > > test) > > > was that one of the original goals here > > > in the RDMA implementation was not simply raw throughput nor raw latency, > > > but a lack of CPU utilization in kernel > > > space due to the offload. While it is entirely possible that newer > > > hardware > > > w/ TCP might compete, the significant > > > reductions in CPU usage in the TCP/IP stack were a big win at the time. > > > > > > Just something to consider while you're doing the testing > > > > I just noticed this thread; some random notes from a somewhat > > fragmented memory of this: > > > > a) Long long ago, I also tried rsocket; > > https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02040.html > > as I remember the library was quite flaky at the time. > > Hmm interesting. There also looks like a thread doing rpoll(). Yeh, I can't actually remember much more about what I did back then! > Btw, not sure whether you noticed, but there's the series posted for the > latest rsocket conversion here: > > https://lore.kernel.org/r/1717503252-51884-1-git-send-email-arei.gong...@huawei.com Oh I hadn't; I think all of the stack of qemu's file abstractions had changed in the ~10 years since I wrote my version! > I hope Lei and his team has tested >4G mem, otherwise definitely worth > checking. Lei also mentioned there're rsocket bugs they found in the cover > letter, but not sure what's that about. It would probably be a good idea to keep track of what bugs are in flight with it, and try it on a few RDMA cards to see what problems get triggered. I think I reported a few at the time, but I gave up after feeling it was getting very hacky. > Yes, and zero-copy requires multifd for now. I think it's because we didn't > want to complicate the header processings in the migration stream where it > may not be page aligned. Ah yes. > > > > e) Someone made a good suggestion (sorry can't remember who) - that the > > RDMA migration structure was the wrong way around - it should be the > > destination which initiates an RDMA read, rather than the source > > doing a write; then things might become a LOT simpler; you just need > > to send page ranges to the destination and it can pull it. > > That might work nicely for postcopy. > > I'm not sure whether it'll still be a problem if rdma recv side is based on > zero-copy. It would be a matter of whether atomicity can be guaranteed so > that we don't want the guest vcpus to see a partially copied page during > on-flight DMAs. UFFDIO_COPY (or friend) is currently the only solution for > that. Yes, but even ignoring that (and the UFFDIO_CONTINUE idea you mention), if the destination can issue an RDMA read itself, it doesn't need to send messages to the source to ask for a page fetch; it just goes and grabs it itself, that's got to be good for latency. Dave > > Thanks, > > -- > Peter Xu > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate
* Markus Armbruster (arm...@redhat.com) wrote: > Philippe Mathieu-Daudé writes: > > > Hi Daniel, Dave, Markus & Thomas. > > > > On 4/6/24 06:58, Markus Armbruster wrote: > >> "Dr. David Alan Gilbert" writes: > >>> * Daniel P. Berrangé (berra...@redhat.com) wrote: > >>>> On Fri, May 31, 2024 at 06:47:45AM +0200, Thomas Huth wrote: > >>>>> On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote: > >>>>>> We are trying to unify all qemu-system-FOO to a single binary. > >>>>>> In order to do that we need to remove QAPI target specific code. > >>>>>> > >>>>>> @dump-skeys is only available on qemu-system-s390x. This series > >>>>>> rename it as @dump-s390-skey, making it available on other > >>>>>> binaries. We take care of backward compatibility via deprecation. > >>>>>> > >>>>>> Philippe Mathieu-Daudé (4): > >>>>>> hw/s390x: Introduce the @dump-s390-skeys QMP command > >>>>>> hw/s390x: Introduce the 'dump_s390_skeys' HMP command > >>>>>> hw/s390x: Deprecate the HMP 'dump_skeys' command > >>>>>> hw/s390x: Deprecate the QMP @dump-skeys command > >>>>> > >>>>> Why do we have to rename the command? Just for the sake of it? I think > >>>>> renaming HMP commands is maybe ok, but breaking the API in QMP is > >>>>> something > >>>>> you should consider twice. > > > > I'm looking at how to include this command in the new "single binary". > > > > Markus explained in an earlier series, just expanding this command as > > stub to targets that don't implement it is not backward compatible and > > breaks QMP introspection. Currently on s390x we get a result, on other > > targets the command doesn't exist. If we add a stubs, then other targets > > return something (even if it is an empty list), confusing management > > interface. > > Loss of introspection precision is a concern, not a hard "no". > > We weigh all the concerns, and pick a solution we hate the least :) > > > So this approach use to deprecate process to include a new command > > which behaves differently on non-s390x targets. > > > > If we don't care for this particular case, better. However I'd still > > like to discuss this approach for other target-specific commands. > > > >> PRO rename: the command's tie to S390 is them immediately obvious, which > >> may be useful when the command becomes available in qemu-systems capable > >> of running other targets. > >> > >> CON rename: users need to adapt. > >> > >> What are the users? Not libvirt, as far as I can tell. > > > > Years ago we said, "all HMP must be based on QMP". > > In practice, it's closer to "HMP must be base on QMP when the > functionality does or should exist in QMP." > > >Now we realize HMP > > became stable because QMP-exposed, although not consumed externally... > > I'm afraid I didn't get this part. > > > Does the concept of "internal QMP commands" makes sense for HMP debug > > ones? (Looking at a way to not expose them). We could use the "x-" > > prefix to not care about stable / backward compat, but what is the point > > of exposing to QMP commands that will never be accessed there? > > > >>>> That was going to be my question too. Seems like its possible to simply > >>>> stub out the existing command for other targets. > >> > >> That's going to happen whether we rename the commands or not. > >> > >>> Are these commands really supposed to be stable, or are they just debug > >>> commands? If they are debug, then add the x- and don't worry too much. > > > > OK. > > > >> docs/devel/qapi-code-gen.rst: > >> > >> Names beginning with ``x-`` used to signify "experimental". This > >> convention has been replaced by special feature "unstable". > >> > >> Feature "unstable" is what makes something unstable, and is what > >> machines should check. > > > > What I mentioned earlier could be 'Feature "internal" or "debug"'. > > What's the difference to "unstable"? It should be clear *why* something is marked x- - something that's marked 'x-' because the featu
Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
DPU card. > > > > > > > > > > In some scenarios where fast live migration is needed (extremely > > > > > > short > > > > > > interruption duration and migration duration) is very useful. To > > > > > > this > > > > > > end, we have also developed RDMA support for multifd. > > > > > Will any of you upstream that work? I'm curious how intrusive would > > > > > it be > > > > > when adding it to multifd, if it can keep only 5 exported functions > > > > > like what > > > > > rdma.h does right now it'll be pretty nice. We also want to make > > > > > sure it works > > > > > with arbitrary sized loads and buffers, e.g. vfio is considering to > > > > > add IO loads to > > > > > multifd channels too. > > > > > > > > > In fact, we sent the patchset to the community in 2021. Pls see: > > > > https://urldefense.com/v3/__https://lore.kernel.org/all/20210203185906.GT2950@work-vm/T/__;!!GjvTz_vk!VfP_SV-8uRya7rBdopv8OUJkmnSi44Ktpqq1E7sr_Xcwt6zvveW51qboWOBSTChdUG1hJwfAl7HZl4NUEGc$ > > Yes, I have sent the patchset of multifd support for rdma migration by > > taking over my colleague, and also > > sorry for not keeping on this work at that time due to some reasons. > > And also I am strongly agree with Lei that the RDMA protocol has some > > special advantages against with TCP > > in some scenario, and we are indeed to use it in our product. > > > > > I wasn't aware of that for sure in the past.. > > > > > > Multifd has changed quite a bit in the last 9.0 release, that may not > > > apply > > > anymore. One thing to mention is please look at Dan's comment on possible > > > use of rsocket.h: > > > > > > https://urldefense.com/v3/__https://lore.kernel.org/all/zjjm6rcqs5eho...@redhat.com/__;!!GjvTz_vk!VfP_SV-8uRya7rBdopv8OUJkmnSi44Ktpqq1E7sr_Xcwt6zvveW51qboWOBSTChdUG1hJwfAl7HZ0CFSE-o$ > > > > > > And Jinpu did help provide an initial test result over the library: > > > > > > https://urldefense.com/v3/__https://lore.kernel.org/qemu-devel/camgffek8wiknqmouyxcathgtiem2dwocf_w7t0vmcd-i30t...@mail.gmail.com/__;!!GjvTz_vk!VfP_SV-8uRya7rBdopv8OUJkmnSi44Ktpqq1E7sr_Xcwt6zvveW51qboWOBSTChdUG1hJwfAl7HZxPNcdb4$ > > > > > > It looks like we have a chance to apply that in QEMU. > > > > > > > > > > > > One thing to note that the question here is not about a pure > > > > > performance > > > > > comparison between rdma and nics only. It's about help us make a > > > > > decision > > > > > on whether to drop rdma, iow, even if rdma performs well, the > > > > > community still > > > > > has the right to drop it if nobody can actively work and maintain it. > > > > > It's just that if nics can perform as good it's more a reason to > > > > > drop, unless > > > > > companies can help to provide good support and work together. > > > > > > > > > We are happy to provide the necessary review and maintenance work for > > > > RDMA > > > > if the community needs it. > > > > > > > > CC'ing Chuan Zheng. > > > I'm not sure whether you and Jinpu's team would like to work together and > > > provide a final solution for rdma over multifd. It could be much simpler > > > than the original 2021 proposal if the rsocket API will work out. > > > > > > Thanks, > > > > > That's a good news to see the socket abstraction for RDMA! > > When I was developed the series above, the most pain is the RDMA migration > > has no QIOChannel abstraction and i need to take a 'fake channel' > > for it which is awkward in code implementation. > > So, as far as I know, we can do this by > > i. the first thing is that we need to evaluate the rsocket is good enough > > to satisfy our QIOChannel fundamental abstraction > > ii. if it works right, then we will continue to see if it can give us > > opportunity to hide the detail of rdma protocol > > into rsocket by remove most of code in rdma.c and also some hack in > > migration main process. > > iii. implement the advanced features like multi-fd and multi-uri for rdma > > migration. > > > > Since I am not familiar with rsocket, I need some times to look at it and > > do some quick verify with rdma migration based on rsocket. > > But, yes, I am willing to involved in this refactor work and to see if we > > can make this migration feature more better:） > > > > > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH v2 06/18] monitor: Stop removing non-duplicated fds
; QLIST_REMOVE(mon_fdset_fd_dup, next);
> >> g_free(mon_fdset_fd_dup);
> >> -if (QLIST_EMPTY(_fdset->dup_fds)) {
> >> -monitor_fdset_cleanup(mon_fdset);
> >> -}
> >> +monitor_fdset_free(mon_fdset);
> >
> > This and above changes are not crystal clear to me where the _cleanup()
> > does extra check "removed" and clean those fds.
> >
> > I think it'll make it easier for me to understand if this one and the next
> > are squashed together. But maybe it's simply because I didn't fully
> > understand.
>
> monitor_fdsets_cleanup() was doing three things previously:
>
> 1- Remove the removed=true fds. This is weird, but ok.
>
> 2- Remove fds from an fdset that has an empty dup_fds list, but only if
> the guest is not running and the monitor is closed. This is problematic.
>
> 3- Remove/free fdsets that have become empty due to the above
> removals. This is ok.
>
> This patch covers (2), because that is the only change that has a
> complex reasoning behind it and we need to document that without
> conflating it with the rest of the changes.
The ebe52b592d you reference, makes me think that the only reason for the
'is not running' was as a way to detect when init had finished; and there
are certainly better ways to do that (now?).
However, the efb87c1697 talks about cleaning up non-dup's on all monitors
closed, to stop getting left-over fd's that were added but then not used
(because a disconnect happened between adding and being used).
In your world when do these get cleaned up?
Dave
> Since (3) is still a reasonable thing to do, this patch merely keeps it
> around, but using the helpers introduced in the previous patch.
>
> The next patch removed the need for (1), making the removal immediate
> instead of delayed. It has it's own much less complex reasoning, which
> is: "we don't need to wait to remove the fd".
>
> I hope this clarifies a bit. I would prefer if we kept this and the next
> patch separate to avoid having a single patch that does too many
> things. I hope to be as explicit as possible with the reason behind
> these changes to avoid putting future people in the situation that we
> are in now, i.e. having to guess at the reasons behind this code.
>
> If you still think we should squash or if you have more questions, let
> me know.
>
> >> return;
> >> }
> >> }
> >> diff --git a/monitor/hmp.c b/monitor/hmp.c
> >> index 69c1b7e98a..460e8832f6 100644
> >> --- a/monitor/hmp.c
> >> +++ b/monitor/hmp.c
> >> @@ -1437,11 +1437,9 @@ static void monitor_event(void *opaque,
> >> QEMUChrEvent event)
> >> monitor_resume(mon);
> >> }
> >> qemu_mutex_unlock(>mon_lock);
> >> -mon_refcount++;
> >> break;
> >>
> >> case CHR_EVENT_CLOSED:
> >> -mon_refcount--;
> >> monitor_fdsets_cleanup();
> >> break;
> >>
> >> diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
> >> index 252de85681..cb628f681d 100644
> >> --- a/monitor/monitor-internal.h
> >> +++ b/monitor/monitor-internal.h
> >> @@ -168,7 +168,6 @@ extern bool qmp_dispatcher_co_shutdown;
> >> extern QmpCommandList qmp_commands, qmp_cap_negotiation_commands;
> >> extern QemuMutex monitor_lock;
> >> extern MonitorList mon_list;
> >> -extern int mon_refcount;
> >>
> >> extern HMPCommand hmp_cmds[];
> >>
> >> diff --git a/monitor/qmp.c b/monitor/qmp.c
> >> index a239945e8d..5e538f34c0 100644
> >> --- a/monitor/qmp.c
> >> +++ b/monitor/qmp.c
> >> @@ -466,7 +466,6 @@ static void monitor_qmp_event(void *opaque,
> >> QEMUChrEvent event)
> >> data = qmp_greeting(mon);
> >> qmp_send_response(mon, data);
> >> qobject_unref(data);
> >> -mon_refcount++;
> >> break;
> >> case CHR_EVENT_CLOSED:
> >> /*
> >> @@ -479,7 +478,6 @@ static void monitor_qmp_event(void *opaque,
> >> QEMUChrEvent event)
> >> json_message_parser_destroy(>parser);
> >> json_message_parser_init(>parser, handle_qmp_command,
> >> mon, NULL);
> >> -mon_refcount--;
> >> monitor_fdsets_cleanup();
> >> break;
> >> case CHR_EVENT_BREAK:
> >
> > I like this too when mon_refcount can be dropped. It turns out I like this
> > patch and the next a lot, and I hope nothing will break.
> >
> > Aside, you seem to have forgot removal of the "int mon_refcount" in
> > monitor.c.
>
> Yes, I'll fix that. Thanks.
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Fri, May 31, 2024 at 06:47:45AM +0200, Thomas Huth wrote: > > On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote: > > > We are trying to unify all qemu-system-FOO to a single binary. > > > In order to do that we need to remove QAPI target specific code. > > > > > > @dump-skeys is only available on qemu-system-s390x. This series > > > rename it as @dump-s390-skey, making it available on other > > > binaries. We take care of backward compatibility via deprecation. > > > > > > Philippe Mathieu-Daudé (4): > > >hw/s390x: Introduce the @dump-s390-skeys QMP command > > >hw/s390x: Introduce the 'dump_s390_skeys' HMP command > > >hw/s390x: Deprecate the HMP 'dump_skeys' command > > >hw/s390x: Deprecate the QMP @dump-skeys command > > > > Why do we have to rename the command? Just for the sake of it? I think > > renaming HMP commands is maybe ok, but breaking the API in QMP is something > > you should consider twice. > > That was going to be my question too. Seems like its possible to simply > stub out the existing command for other targets. Are these commands really supposed to be stable, or are they just debug commands? If they are debug, then add the x- and don't worry too much. Dave > The renaming is just window dressing. > > > > > And even if we decide to rename ... maybe we should discuss whether it makes > > sense to come up with a generic command instead: As far as I know, ARM also > > has something similar, called MTE. Maybe we also want to dump MTE keys one > > day? So the new command should maybe be called "dump-memory-keys" instead? > > Or should it maybe rather be an option to the existing "dump-guest-memory" > > command instead? > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate
* Thomas Huth (th...@redhat.com) wrote:
> On 31/05/2024 16.02, Dr. David Alan Gilbert wrote:
> > * Thomas Huth (th...@redhat.com) wrote:
> > > On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote:
> > > > We are trying to unify all qemu-system-FOO to a single binary.
> > > > In order to do that we need to remove QAPI target specific code.
> > > >
> > > > @dump-skeys is only available on qemu-system-s390x. This series
> > > > rename it as @dump-s390-skey, making it available on other
> > > > binaries. We take care of backward compatibility via deprecation.
> > > >
> > > > Philippe Mathieu-Daudé (4):
> > > > hw/s390x: Introduce the @dump-s390-skeys QMP command
> > > > hw/s390x: Introduce the 'dump_s390_skeys' HMP command
> > > > hw/s390x: Deprecate the HMP 'dump_skeys' command
> > > > hw/s390x: Deprecate the QMP @dump-skeys command
> > >
> > > Why do we have to rename the command? Just for the sake of it? I think
> > > renaming HMP commands is maybe ok, but breaking the API in QMP is
> > > something
> > > you should consider twice.
> > >
> > > And even if we decide to rename ... maybe we should discuss whether it
> > > makes
> > > sense to come up with a generic command instead: As far as I know, ARM
> > > also
> > > has something similar, called MTE. Maybe we also want to dump MTE keys one
> > > day? So the new command should maybe be called "dump-memory-keys" instead?
> >
> > I think there are at least two different concepts; but I agree it would be
> > nice to keep a single command for matching concepts across different
> > architectures;
> > I can't say I know the details of any, but:
> >
> >a) Page table things - I think x86 PKRU/PKEY (???) is a page table thing
> > where pages marked a special way are associated with keys.
> > That sounds similar to what the skeys are???
>
> Sounds a little bit similar, but s390 storage keys are independent from page
> tables. It's rather that each page (4096 bytes) of RAM has an additional
> 7-bit value that contains the storage key and some additional bits. It's
> also usable when page tables are still disabled.
>
> > I'm not sure the two fit in the same command.
>
> Does it make sense to dump all the MTE or x86 keys all at once? If so, we
> could maybe come up with an unified command. Otherwise it might not make
> sense, indeed.
So they're all really different granularities:
s390 - one key/physical page
ARM MTE - one tag/16 bytes physical
x86 - per virtual page; then a current register with 16 permission
sets
For x86 I guess it would be easy to dump the register, and then the
values for a range of virtual addresses.
But then if you dumped a range of physical addresses on ARM MTE you'd
get hundreds times more output than for the equivalent s390.
Dave
> Thomas
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH v2 2/6] Convert 'info tlb' to use generic iterator
> -}
> -}
> -}
> -}
> -}
> -}
> +/* Trim line to fit screen */
> +if (pos - buf > 79) {
> +strcpy(buf + 77, "..");
> }
> -}
>
> -#ifdef TARGET_X86_64
> -static void tlb_info_la48(Monitor *mon, CPUArchState *env,
> -uint64_t l0, uint64_t pml4_addr)
> -{
> -uint64_t l1, l2, l3, l4;
> -uint64_t pml4e, pdpe, pde, pte;
> -uint64_t pdp_addr, pd_addr, pt_addr;
> -
> -for (l1 = 0; l1 < 512; l1++) {
> -cpu_physical_memory_read(pml4_addr + l1 * 8, , 8);
> -pml4e = le64_to_cpu(pml4e);
> -if (!(pml4e & PG_PRESENT_MASK)) {
> -continue;
> -}
> -
> -pdp_addr = pml4e & 0x3f000ULL;
> -for (l2 = 0; l2 < 512; l2++) {
> -cpu_physical_memory_read(pdp_addr + l2 * 8, , 8);
> -pdpe = le64_to_cpu(pdpe);
> -if (!(pdpe & PG_PRESENT_MASK)) {
> -continue;
> -}
> -
> -if (pdpe & PG_PSE_MASK) {
> -/* 1G pages, CR4.PSE is ignored */
> -print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
> -pdpe, 0x3c000ULL);
> -continue;
> -}
> -
> -pd_addr = pdpe & 0x3f000ULL;
> -for (l3 = 0; l3 < 512; l3++) {
> -cpu_physical_memory_read(pd_addr + l3 * 8, , 8);
> -pde = le64_to_cpu(pde);
> -if (!(pde & PG_PRESENT_MASK)) {
> -continue;
> -}
> -
> -if (pde & PG_PSE_MASK) {
> -/* 2M pages, CR4.PSE is ignored */
> -print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30)
> +
> -(l3 << 21), pde, 0x3ffe0ULL);
> -continue;
> -}
> -
> -pt_addr = pde & 0x3f000ULL;
> -for (l4 = 0; l4 < 512; l4++) {
> -cpu_physical_memory_read(pt_addr
> -+ l4 * 8,
> -, 8);
> -pte = le64_to_cpu(pte);
> -if (pte & PG_PRESENT_MASK) {
> -print_pte(mon, env, (l0 << 48) + (l1 << 39) +
> -(l2 << 30) + (l3 << 21) + (l4 << 12),
> -pte & ~PG_PSE_MASK, 0x3f000ULL);
> -}
> -}
> -}
> -}
> -}
> +monitor_printf(mon, "%s\n", buf);
> }
>
> -static void tlb_info_la57(Monitor *mon, CPUArchState *env)
> +static
> +int mem_print_tlb(CPUState *cs, void *data, PTE_t *pte,
> + target_ulong vaddr, int height, int offset)
> {
> -uint64_t l0;
> -uint64_t pml5e;
> -uint64_t pml5_addr;
> -
> -pml5_addr = env->cr[3] & 0x3f000ULL;
> -for (l0 = 0; l0 < 512; l0++) {
> -cpu_physical_memory_read(pml5_addr + l0 * 8, , 8);
> -pml5e = le64_to_cpu(pml5e);
> -if (pml5e & PG_PRESENT_MASK) {
> -tlb_info_la48(mon, env, l0, pml5e & 0x3f000ULL);
> -}
> -}
> +struct mem_print_state *state = (struct mem_print_state *) data;
> +print_pte(state->mon, state->env, vaddr, pte->pte64_t);
> +return 0;
> }
> -#endif /* TARGET_X86_64 */
>
> void hmp_info_tlb(Monitor *mon, const QDict *qdict)
> {
> -CPUArchState *env;
> +struct mem_print_state state;
>
> -env = mon_get_cpu_env(mon);
> -if (!env) {
> -monitor_printf(mon, "No CPU available\n");
> +CPUState *cs = mon_get_cpu(mon);
> +if (!cs) {
> +monitor_printf(mon, "Unable to get CPUState. Internal error\n");
> return;
> }
>
> -if (!(env->cr[0] & CR0_PG_MASK)) {
> -monitor_printf(mon, "PG disabled\n");
> +if (!init_iterator(mon, )) {
> return;
> }
> -if (env->cr[4] & CR4_PAE_MASK) {
> -#ifdef TARGET_X86_64
> -if (env->hflags & HF_LMA_MASK) {
> -if (env->cr[4] & CR4_LA57_MASK) {
> -tlb_info_la57(mon, env);
> -} else {
> -tlb_info_la48(mon, env, 0, env->cr[3] & 0x3f000ULL);
> -}
> -} else
> -#endif
> -{
> -tlb_info_pae32(mon, env);
> -}
> -} else {
> -tlb_info_32(mon, env);
> -}
> +
> +/**
> + * 'info tlb' visits only leaf PTEs marked present.
> + * It does not check other protection bits.
> + */
> +for_each_pte(cs, _print_tlb, , false, false);
> }
>
> static void mem_print(Monitor *mon, CPUArchState *env,
> --
> 2.34.1
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH v2 1/6] Add an "info pg" command that prints the current page tables
+}
> +
> +/* Trim line to fit screen */
> +if (pos - buf > 79) {
> +strcpy(buf + 77, "..");
> +}
> +
> +monitor_printf(mon, "%s\n", buf);
> +}
> +
> +static inline
> +int ent2prot(uint64_t prot)
> +{
> +return prot & (PG_USER_MASK | PG_RW_MASK |
> + PG_PRESENT_MASK);
> +}
> +
> +/* Returns true if it emitted anything */
> +static
> +bool flush_print_pg_state(CPUState *cs, struct mem_print_state *state)
> +{
> +bool ret = false;
> +for (int i = state->start_height; i > 0; i--) {
> +if (state->vstart[i] == -1) {
> +break;
> +}
> +PTE_t my_pte;
> +my_pte.pte64_t = state->ent[i];
> +ret = true;
> +pg_print(cs, state->mon, state->ent[i],
> + state->vstart[i], state->vend[i],
> + state->pstart, state->pend,
> + state->offset[i], state->last_offset[i],
> + i, state->max_height, state->vaw, state->paw,
> + mmu_pte_leaf(cs, i, _pte));
> +}
> +
> +return ret;
> +}
> +
> /* Perform linear address sign extension */
> static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
> {
> @@ -49,6 +244,191 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr
> addr)
> return addr;
> }
>
> +
> +
> +/*** Start generic page table monitor code */
> +
> +/* Assume only called on present entries */
> +static
> +int compressing_iterator(CPUState *cs, void *data, PTE_t *pte,
> + target_ulong vaddr, int height, int offset)
> +{
> +struct mem_print_state *state = (struct mem_print_state *) data;
> +hwaddr paddr = mmu_pte_child(cs, pte, height);
> +target_ulong size = mmu_pte_leaf_page_size(cs, height);
> +bool start_new_run = false, flush = false;
> +bool is_leaf = mmu_pte_leaf(cs, height, pte);
> +
> +int entries_per_node = mmu_page_table_entries_per_node(cs, height);
> +
> +/* Prot of current pte */
> +int prot = ent2prot(pte->pte64_t);
> +
> +
> +/* If there is a prior run, first try to extend it. */
> +if (state->start_height != 0) {
> +
> +/*
> + * If we aren't flushing interior nodes, raise the start height.
> + * We don't need to detect non-compressible interior nodes.
> + */
> +if ((!state->flush_interior) && state->start_height < height) {
> +state->start_height = height;
> +state->vstart[height] = vaddr;
> +state->vend[height] = vaddr;
> +state->ent[height] = pte->pte64_t;
> +if (offset == 0) {
> +state->last_offset[height] = entries_per_node - 1;
> +} else {
> +state->last_offset[height] = offset - 1;
> +}
> +}
> +
> +/* Detect when we are walking down the "left edge" of a range */
> +if (state->vstart[height] == -1
> +&& (height + 1) <= state->start_height
> +&& state->vstart[height + 1] == vaddr) {
> +
> +state->vstart[height] = vaddr;
> +state->vend[height] = vaddr;
> +state->ent[height] = pte->pte64_t;
> +state->offset[height] = offset;
> +state->last_offset[height] = offset;
> +
> +if (is_leaf) {
> +state->pstart = paddr;
> +state->pend = paddr;
> +}
> +
> +/* Detect contiguous entries at same level */
> +} else if ((state->vstart[height] != -1)
> + && (state->start_height >= height)
> + && ent2prot(state->ent[height]) == prot
> + && (((state->last_offset[height] + 1) % entries_per_node)
> + == offset)
> + && ((!is_leaf)
> + || (!state->require_physical_contiguity)
> + || (state->pend + size == paddr))) {
> +
> +
> +/*
> + * If there are entries at the levels below, make sure we
> + * completed them. We only compress interior nodes
> + * without holes in the mappings.
> + */
> +if (height != 1) {
> +for (int i = height - 1; i >= 1; i--) {
> +int entries = mmu_page_table_entries_per_node(cs, i);
> +
> +/* Stop if we hit large pages before level 1 */
> +if (state->vstart[i] == -1) {
> +break;
> +}
> +
> +if ((state->last_offset[i] + 1) != entries) {
> +flush = true;
> +start_new_run = true;
> +break;
> +}
> +}
> +}
> +
> +
> +if (!flush) {
> +
> +/* We can compress these entries */
> +state->ent[height] = pte->pte64_t;
> +state->vend[height] = vaddr;
> +state->last_offset[height] = offset;
> +
> +/* Only update the physical range on leaves */
> +if (is_leaf) {
> +state->pend = paddr;
> +}
> +}
> +/* Let PTEs accumulate... */
> +} else {
> +flush = true;
> +}
> +
> +if (flush) {
> +/*
> + * We hit dicontiguous permissions or pages.
> + * Print the old entries, then start accumulating again
> + *
> + * Some clients only want the flusher called on a leaf.
> + * Check that too.
> + *
> + * We can infer whether the accumulated range includes a
> + * leaf based on whether pstart is -1.
> + */
> +if (state->flush_interior || (state->pstart != -1)) {
> +if (state->flusher(cs, state)) {
> +start_new_run = true;
> +}
> +} else {
> +start_new_run = true;
> +}
> +}
> +} else {
> +start_new_run = true;
> +}
> +
> +if (start_new_run) {
> +/* start a new run with this PTE */
> +for (int i = state->start_height; i > 0; i--) {
> +if (state->vstart[i] != -1) {
> +state->ent[i] = 0;
> +state->last_offset[i] = 0;
> +state->vstart[i] = -1;
> +}
> +}
> +state->pstart = -1;
> +state->vstart[height] = vaddr;
> +state->vend[height] = vaddr;
> +state->ent[height] = pte->pte64_t;
> +state->offset[height] = offset;
> +state->last_offset[height] = offset;
> +if (is_leaf) {
> +state->pstart = paddr;
> +state->pend = paddr;
> +}
> +state->start_height = height;
> +}
> +
> +return 0;
> +}
> +
> +
> +void hmp_info_pg(Monitor *mon, const QDict *qdict)
> +{
> +struct mem_print_state state;
> +
> +CPUState *cs = mon_get_cpu(mon);
> +if (!cs) {
> +monitor_printf(mon, "Unable to get CPUState. Internal error\n");
> +return;
> +}
> +
> +if (!init_iterator(mon, )) {
> +return;
> +}
> +state.flush_interior = true;
> +state.require_physical_contiguity = true;
> +state.flusher = _print_pg_state;
> +
> +pg_print_header(mon, );
> +
> +/*
> + * We must visit interior entries to get the hierarchy, but
> + * can skip not present mappings
> + */
> +for_each_pte(cs, _iterator, , true, false);
> +
> +/* Print last entry, if one present */
> +flush_print_pg_state(cs, );
> +}
> +
> static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
>hwaddr pte, hwaddr mask)
> {
> --
> 2.34.1
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate
* Thomas Huth (th...@redhat.com) wrote: > On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote: > > We are trying to unify all qemu-system-FOO to a single binary. > > In order to do that we need to remove QAPI target specific code. > > > > @dump-skeys is only available on qemu-system-s390x. This series > > rename it as @dump-s390-skey, making it available on other > > binaries. We take care of backward compatibility via deprecation. > > > > Philippe Mathieu-Daudé (4): > >hw/s390x: Introduce the @dump-s390-skeys QMP command > >hw/s390x: Introduce the 'dump_s390_skeys' HMP command > >hw/s390x: Deprecate the HMP 'dump_skeys' command > >hw/s390x: Deprecate the QMP @dump-skeys command > > Why do we have to rename the command? Just for the sake of it? I think > renaming HMP commands is maybe ok, but breaking the API in QMP is something > you should consider twice. > > And even if we decide to rename ... maybe we should discuss whether it makes > sense to come up with a generic command instead: As far as I know, ARM also > has something similar, called MTE. Maybe we also want to dump MTE keys one > day? So the new command should maybe be called "dump-memory-keys" instead? I think there are at least two different concepts; but I agree it would be nice to keep a single command for matching concepts across different architectures; I can't say I know the details of any, but: a) Page table things - I think x86 PKRU/PKEY (???) is a page table thing where pages marked a special way are associated with keys. That sounds similar to what the skeys are??? b) Upper bit things - where you steal a few bits from the virtual address and then use that to associate some security; I think that's closer to what MTE is isn't it? I'm not sure the two fit in the same command. Dave > Or should it maybe rather be an option to the existing "dump-guest-memory" > command instead? > > Thomas > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH v2 3/4] tests/qtest/migration-test: Fix and enable test_ignore_shared
* Nicholas Piggin (npig...@gmail.com) wrote:
> This test is already starting to bitrot, so first remove it from ifdef
> and fix compile issues. ppc64 transfers about 2MB, so bump the size
> threshold too.
>
> It was said to be broken on aarch64 but it may have been due to the
> limited shm size under Gitlab CI. Now that it uses /tmp, enable it.
If it does fail, lets see if we can figure out how, i.e. whether it's the
shm size or something else.
Reviewed-by: Dr. David Alan Gilbert
> Cc: Yury Kotov
> Cc: Dr. David Alan Gilbert
> Signed-off-by: Nicholas Piggin
> ---
> tests/qtest/migration-test.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
> index de380757be..86eace354e 100644
> --- a/tests/qtest/migration-test.c
> +++ b/tests/qtest/migration-test.c
> @@ -1855,8 +1855,6 @@ static void
> test_precopy_unix_tls_x509_override_host(void)
> #endif /* CONFIG_TASN1 */
> #endif /* CONFIG_GNUTLS */
>
> -#if 0
> -/* Currently upset on aarch64 TCG */
> static void test_ignore_shared(void)
> {
> g_autofree char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
> @@ -1865,7 +1863,7 @@ static void test_ignore_shared(void)
> .use_memfile = true,
> };
>
> -if (test_migrate_start(, , uri, false, true, NULL, NULL)) {
> +if (test_migrate_start(, , uri, )) {
> return;
> }
>
> @@ -1890,11 +1888,11 @@ static void test_ignore_shared(void)
> wait_for_migration_complete(from);
>
> /* Check whether shared RAM has been really skipped */
> -g_assert_cmpint(read_ram_property_int(from, "transferred"), <, 1024 *
> 1024);
> +g_assert_cmpint(read_ram_property_int(from, "transferred"), <,
> + 4 * 1024 * 1024);
>
> test_migrate_end(from, to, true);
> }
> -#endif
>
> static void *
> test_migrate_xbzrle_start(QTestState *from,
> @@ -3535,7 +3533,8 @@ int main(int argc, char **argv)
> #endif /* CONFIG_TASN1 */
> #endif /* CONFIG_GNUTLS */
>
> -/* migration_test_add("/migration/ignore_shared", test_ignore_shared); */
> +migration_test_add("/migration/ignore_shared", test_ignore_shared);
> +
> #ifndef _WIN32
> migration_test_add("/migration/precopy/fd/tcp",
> test_migrate_precopy_fd_socket);
> --
> 2.43.0
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 3/7] linux-user: sparc: Remove unused struct 'target_mc_fq'
* Dr. David Alan Gilbert (d...@treblig.org) wrote:
> This struct is unused since Peter's
> Commit b8ae597f0e6d ("linux-user/sparc: Fix errors in target_ucontext
> structures")
>
> However, hmm, I'm a bit confused since that commit modifies the
> structure and then removes it, was that intentional?
Ping on this.
(I think the others in the set have been reviewed and one picked up).
Dave
> Signed-off-by: Dr. David Alan Gilbert
> ---
> linux-user/sparc/signal.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c
> index f164b74032..8181b8b92c 100644
> --- a/linux-user/sparc/signal.c
> +++ b/linux-user/sparc/signal.c
> @@ -546,11 +546,6 @@ void setup_sigtramp(abi_ulong sigtramp_page)
> typedef abi_ulong target_mc_greg_t;
> typedef target_mc_greg_t target_mc_gregset_t[SPARC_MC_NGREG];
>
> -struct target_mc_fq {
> -abi_ulong mcfq_addr;
> -uint32_t mcfq_insn;
> -};
> -
> /*
> * Note the manual 16-alignment; the kernel gets this because it
> * includes a "long double qregs[16]" in the mcpu_fregs union,
> --
> 2.45.0
>
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 6/7] target/ppc: Remove unused struct 'mmu_ctx_hash32'
* BALATON Zoltan (bala...@eik.bme.hu) wrote:
> On Sun, 5 May 2024, BALATON Zoltan wrote:
> > On Sun, 5 May 2024, Dr. David Alan Gilbert wrote:
> > > I think it's use was removed by
> > > Commit 5883d8b296 ("mmu-hash*: Don't use full ppc_hash{32,
> > > 64}_translate() path for get_phys_page_debug()")
> > >
> > > Signed-off-by: Dr. David Alan Gilbert
> >
> > Reviewed-by: BALATON Zoltan
>
> I've picked this patch up and will send with my series that changes the same
> place to avoid needing to rebase.
Thanks!
Dave
> Regards,
> BALATON Zoltan
>
> > > ---
> > > target/ppc/mmu-hash32.c | 6 --
> > > 1 file changed, 6 deletions(-)
> > >
> > > diff --git a/target/ppc/mmu-hash32.c b/target/ppc/mmu-hash32.c
> > > index 3976416840..746321329c 100644
> > > --- a/target/ppc/mmu-hash32.c
> > > +++ b/target/ppc/mmu-hash32.c
> > > @@ -36,12 +36,6 @@
> > > # define LOG_BATS(...) do { } while (0)
> > > #endif
> > >
> > > -struct mmu_ctx_hash32 {
> > > -hwaddr raddr; /* Real address */
> > > -int prot; /* Protection bits */
> > > -int key; /* Access key */
> > > -};
> > > -
> > > static int ppc_hash32_pp_prot(int key, int pp, int nx)
> > > {
> > > int prot;
> > >
> >
> >
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 2/7] linux-user: i386/signal: Remove unused fp structs
* Richard Henderson (richard.hender...@linaro.org) wrote:
> On 5/5/24 10:14, Dr. David Alan Gilbert wrote:
> > The structs 'target_fpxreg' and 'target_xmmreg' are unused since
> > Paolo's:
> >
> > Commit 2796f290b546 ("linux-user: i386/signal: support FXSAVE fpstate on
> > 32-bit emulation")
> >
> > Signed-off-by: Dr. David Alan Gilbert
> > ---
> > linux-user/i386/signal.c | 10 --
> > 1 file changed, 10 deletions(-)
>
> I have
>
> https://lore.kernel.org/qemu-devel/20240409050302.1523277-1-richard.hender...@linaro.org/
>
> which cleans this up. I need to refresh and resubmit.
Ah yes, that's fine.
Dave
>
>
> r~
>
> >
> > diff --git a/linux-user/i386/signal.c b/linux-user/i386/signal.c
> > index 990048f42a..9bf602b388 100644
> > --- a/linux-user/i386/signal.c
> > +++ b/linux-user/i386/signal.c
> > @@ -34,16 +34,6 @@ struct target_fpreg {
> > uint16_t exponent;
> > };
> > -struct target_fpxreg {
> > -uint16_t significand[4];
> > -uint16_t exponent;
> > -uint16_t padding[3];
> > -};
> > -
> > -struct target_xmmreg {
> > -uint32_t element[4];
> > -};
> > -
> > struct target_fpx_sw_bytes {
> > uint32_t magic1;
> > uint32_t extended_size;
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
[PATCH 3/7] linux-user: sparc: Remove unused struct 'target_mc_fq'
This struct is unused since Peter's
Commit b8ae597f0e6d ("linux-user/sparc: Fix errors in target_ucontext
structures")
However, hmm, I'm a bit confused since that commit modifies the
structure and then removes it, was that intentional?
Signed-off-by: Dr. David Alan Gilbert
---
linux-user/sparc/signal.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c
index f164b74032..8181b8b92c 100644
--- a/linux-user/sparc/signal.c
+++ b/linux-user/sparc/signal.c
@@ -546,11 +546,6 @@ void setup_sigtramp(abi_ulong sigtramp_page)
typedef abi_ulong target_mc_greg_t;
typedef target_mc_greg_t target_mc_gregset_t[SPARC_MC_NGREG];
-struct target_mc_fq {
-abi_ulong mcfq_addr;
-uint32_t mcfq_insn;
-};
-
/*
* Note the manual 16-alignment; the kernel gets this because it
* includes a "long double qregs[16]" in the mcpu_fregs union,
--
2.45.0
[PATCH 2/7] linux-user: i386/signal: Remove unused fp structs
The structs 'target_fpxreg' and 'target_xmmreg' are unused since
Paolo's:
Commit 2796f290b546 ("linux-user: i386/signal: support FXSAVE fpstate on
32-bit emulation")
Signed-off-by: Dr. David Alan Gilbert
---
linux-user/i386/signal.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/linux-user/i386/signal.c b/linux-user/i386/signal.c
index 990048f42a..9bf602b388 100644
--- a/linux-user/i386/signal.c
+++ b/linux-user/i386/signal.c
@@ -34,16 +34,6 @@ struct target_fpreg {
uint16_t exponent;
};
-struct target_fpxreg {
-uint16_t significand[4];
-uint16_t exponent;
-uint16_t padding[3];
-};
-
-struct target_xmmreg {
-uint32_t element[4];
-};
-
struct target_fpx_sw_bytes {
uint32_t magic1;
uint32_t extended_size;
--
2.45.0
[PATCH 1/7] linux-user: cris: Remove unused struct 'rt_signal_frame'
Since 'setup_rt_frame' has never been implemented, this struct
is unused.
Signed-off-by: Dr. David Alan Gilbert
---
linux-user/cris/signal.c | 8
1 file changed, 8 deletions(-)
diff --git a/linux-user/cris/signal.c b/linux-user/cris/signal.c
index 4f532b2903..10948bcf30 100644
--- a/linux-user/cris/signal.c
+++ b/linux-user/cris/signal.c
@@ -35,14 +35,6 @@ struct target_signal_frame {
uint16_t retcode[4]; /* Trampoline code. */
};
-struct rt_signal_frame {
-siginfo_t *pinfo;
-void *puc;
-siginfo_t info;
-ucontext_t uc;
-uint16_t retcode[4]; /* Trampoline code. */
-};
-
static void setup_sigcontext(struct target_sigcontext *sc, CPUCRISState *env)
{
__put_user(env->regs[0], >regs.r0);
--
2.45.0
[PATCH 0/7] Remove some unused structures
A bunch of structs that are currently unused, found with a simple script and a bit of eyeballing. The only one I'm that suspicious of is the SPARC one, where the patch which removed the use is a bit confusing to me. Tested with a --target-list=ppc-softmmu,m68k-softmmu,x86_64-softmmu,arm-softmmu,aarch64-softmmu,cris-linux-user,i386-linux-user,sparc-linux-user and 'make check' on x86 linux. Dave Dr. David Alan Gilbert (7): linux-user: cris: Remove unused struct 'rt_signal_frame' linux-user: i386/signal: Remove unused fp structs linux-user: sparc: Remove unused struct 'target_mc_fq' hw/usb/dev-network: Remove unused struct 'rndis_config_parameter' hw/arm/bcm2836: Remove unusued struct 'BCM283XClass' target/ppc: Remove unused struct 'mmu_ctx_hash32' net/can: Remove unused struct 'CanBusState' hw/arm/bcm2836.c | 12 hw/usb/dev-network.c | 8 linux-user/cris/signal.c | 8 linux-user/i386/signal.c | 10 -- linux-user/sparc/signal.c | 5 - net/can/can_host.c| 6 -- target/ppc/mmu-hash32.c | 6 -- 7 files changed, 55 deletions(-) -- 2.45.0
[PATCH 7/7] net/can: Remove unused struct 'CanBusState'
As far as I can tell this struct has never been used in this
file (it is used in can_core.c).
Signed-off-by: Dr. David Alan Gilbert
---
net/can/can_host.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/net/can/can_host.c b/net/can/can_host.c
index a3c84028c6..b2fe553f91 100644
--- a/net/can/can_host.c
+++ b/net/can/can_host.c
@@ -34,12 +34,6 @@
#include "net/can_emu.h"
#include "net/can_host.h"
-struct CanBusState {
-Object object;
-
-QTAILQ_HEAD(, CanBusClientState) clients;
-};
-
static void can_host_disconnect(CanHostState *ch)
{
CanHostClass *chc = CAN_HOST_GET_CLASS(ch);
--
2.45.0
[PATCH 5/7] hw/arm/bcm2836: Remove unusued struct 'BCM283XClass'
This struct has been unused since
Commit f932093ae165 ("hw/arm/bcm2836: Split out common part of BCM283X
classes")
Signed-off-by: Dr. David Alan Gilbert
---
hw/arm/bcm2836.c | 12
1 file changed, 12 deletions(-)
diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index db191661f2..40a379bc36 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -18,18 +18,6 @@
#include "target/arm/cpu-qom.h"
#include "target/arm/gtimer.h"
-struct BCM283XClass {
-/*< private >*/
-DeviceClass parent_class;
-/*< public >*/
-const char *name;
-const char *cpu_type;
-unsigned core_count;
-hwaddr peri_base; /* Peripheral base address seen by the CPU */
-hwaddr ctrl_base; /* Interrupt controller and mailboxes etc. */
-int clusterid;
-};
-
static Property bcm2836_enabled_cores_property =
DEFINE_PROP_UINT32("enabled-cpus", BCM283XBaseState, enabled_cpus, 0);
--
2.45.0
[PATCH 6/7] target/ppc: Remove unused struct 'mmu_ctx_hash32'
I think it's use was removed by
Commit 5883d8b296 ("mmu-hash*: Don't use full ppc_hash{32,
64}_translate() path for get_phys_page_debug()")
Signed-off-by: Dr. David Alan Gilbert
---
target/ppc/mmu-hash32.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/target/ppc/mmu-hash32.c b/target/ppc/mmu-hash32.c
index 3976416840..746321329c 100644
--- a/target/ppc/mmu-hash32.c
+++ b/target/ppc/mmu-hash32.c
@@ -36,12 +36,6 @@
# define LOG_BATS(...) do { } while (0)
#endif
-struct mmu_ctx_hash32 {
-hwaddr raddr; /* Real address */
-int prot; /* Protection bits */
-int key; /* Access key*/
-};
-
static int ppc_hash32_pp_prot(int key, int pp, int nx)
{
int prot;
--
2.45.0
[PATCH 4/7] hw/usb/dev-network: Remove unused struct 'rndis_config_parameter'
As far as I can tell it was never used.
Signed-off-by: Dr. David Alan Gilbert
---
hw/usb/dev-network.c | 8
1 file changed, 8 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 2c33e36cad..d00d68b21d 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -475,14 +475,6 @@ struct rndis_packet_msg_type {
le32 Reserved;
};
-struct rndis_config_parameter {
-le32 ParameterNameOffset;
-le32 ParameterNameLength;
-le32 ParameterType;
-le32 ParameterValueOffset;
-le32 ParameterValueLength;
-};
-
/* implementation specific */
enum rndis_state
{
--
2.45.0
Re: [PATCH v3 3/6] migration: Remove 'blk/-b' option from migrate commands
* Markus Armbruster (arm...@redhat.com) wrote:
> Fabiano Rosas writes:
>
> > The block migration is considered obsolete and has been deprecated in
> > 8.2. Remove the migrate command option that enables it. This only
> > affects the QMP and HMP commands, the feature can still be accessed by
> > setting the migration 'block' capability. The whole feature will be
> > removed in a future patch.
> >
> > Deprecation commit 8846b5bfca ("migration: migrate 'blk' command
> > option is deprecated.").
> >
> > Reviewed-by: Markus Armbruster
> > Signed-off-by: Fabiano Rosas
>
> [...]
>
> > diff --git a/hmp-commands.hx b/hmp-commands.hx
> > index 7978302949..ebca2cdced 100644
> > --- a/hmp-commands.hx
> > +++ b/hmp-commands.hx
> > @@ -909,21 +909,17 @@ ERST
> >
> > {
> > .name = "migrate",
> > -.args_type = "detach:-d,blk:-b,resume:-r,uri:s",
> > -.params = "[-d] [-b] [-r] uri",
> > +.args_type = "detach:-d,resume:-r,uri:s",
> > +.params = "[-d] [-r] uri",
> > .help = "migrate to URI (using -d to not wait for
> > completion)"
> > - "\n\t\t\t -b for migration without shared storage with"
> > - " full copy of disk\n\t\t\t -r to resume a paused
> > migration",
> > + "\n\t\t\t -r to resume a paused migration",
> > .cmd= hmp_migrate,
> > },
> >
> >
> > SRST
> > -``migrate [-d] [-b]`` *uri*
> > +``migrate [-d]`` *uri*
> >Migrate to *uri* (using -d to not wait for completion).
> > -
> > - ``-b``
> > -for migration with full copy of disk
> > ERST
>
> Not this patch's fault, but here goes anyway: -r is undocumented here.
Probably one for Peter I guess.
Dave
> >
> > {
>
> [...]
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: Add 'info pg' command to monitor
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 16 Apr 2024 at 19:11, Don Porter wrote: > > > > On 4/16/24 13:03, Peter Maydell wrote: > > > On Tue, 16 Apr 2024 at 17:53, Don Porter wrote: > > >> There is still a lot I am learning about the code base, but it seems > > >> that qemu_get_guest_memory_mapping() does most of what one would need. > > >> It currently only returns the "leaves" of the page table tree in a list. > > >> > > >> What if I extend this function with an optional argument to either > > >> 1) return the interior nodes of the page table in additional lists (and > > >> then parse+print in the monitor code), or > > >> 2) inline the monitor printing in the arch-specific hook, and pass a > > >> flag to get_guest_memory_mapping() that turns on/off the statements that > > >> pretty print the page tables? > > >> > > >> It looks like most CPUs implement this function as part of checkpointing. > > > As far as I can see only x86 implements the get_memory_mapping > > > function, so once again somebody has added some bit of > > > functionality that does a walk of the page tables that is > > > x86 only and that shares no code with any of the other > > > page table walking code :-( > > > > My mistake - get_memory_mappings() is only implemented in x86. > > > > In doing some searching of the code, many architectures implement > > mmu_translate() and > > get_physical_address() functions, but they are not standardized. I also > > see your larger point > > about replicating page walking code in x86. > > > > I imagine you have something in mind that abstracts things like the > > height of the radix tree, > > entries per node, checking permissions, printing the contents, etc. > > > > Perhaps I should start by trying to merge the x86 page walking code into > > one set of common > > helper functions, get more feedback (perhaps on a new patch thread?), > > and then consider > > how to abstract across architectures after getting feedback on this? > > I think the cross-architecture abstraction is probably the > trickiest part. I would actually be happy for us to drop > 'info tlb' and 'info mem' entirely if we have a cross-arch > command that gives basically the same information -- we don't > IMHO need more than one command for this, and we only have > multiple commands for basically legacy reasons. And for the > human monitor (HMP) we don't need to keep things around > for backwards compatibility. I'm not sure what happens for the (MIPS/SPARC ?) where it's not a traditional table hierarchy. The other thing you might want (and I'm not sure how it interacts with any of this) is to specify the root of the MMU tree (i.e. CR3 value for those in Intel thinking) to dump different processes etc. Dave > thanks > -- PMM -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: Add 'info pg' command to monitor
* Don Porter (por...@cs.unc.edu) wrote: > On 4/16/24 13:03, Peter Maydell wrote: > > On Tue, 16 Apr 2024 at 17:53, Don Porter wrote: > > > There is still a lot I am learning about the code base, but it seems > > > that qemu_get_guest_memory_mapping() does most of what one would need. > > > It currently only returns the "leaves" of the page table tree in a list. > > > > > > What if I extend this function with an optional argument to either > > > 1) return the interior nodes of the page table in additional lists (and > > > then parse+print in the monitor code), or > > > 2) inline the monitor printing in the arch-specific hook, and pass a > > > flag to get_guest_memory_mapping() that turns on/off the statements that > > > pretty print the page tables? > > > > > > It looks like most CPUs implement this function as part of checkpointing. > > As far as I can see only x86 implements the get_memory_mapping > > function, so once again somebody has added some bit of > > functionality that does a walk of the page tables that is > > x86 only and that shares no code with any of the other > > page table walking code :-( > > My mistake - get_memory_mappings() is only implemented in x86. > > In doing some searching of the code, many architectures implement > mmu_translate() and > get_physical_address() functions, but they are not standardized. I also see > your larger point > about replicating page walking code in x86. > > I imagine you have something in mind that abstracts things like the height > of the radix tree, > entries per node, checking permissions, printing the contents, etc. > > Perhaps I should start by trying to merge the x86 page walking code into one > set of common > helper functions, get more feedback (perhaps on a new patch thread?), and > then consider > how to abstract across architectures after getting feedback on this? > > In looking at x86 code, I see the following places where there is page table > walking code to > potentially merge: > > * target/i386/monitor.c - existing info commands > > * target/i386/helper.c - get_phys_page_attrs_debug > > * target/i386/arch_memory_mapping.c - implements get_memory_mapping > > * tcg/sysemu/excp_helper.c: implements mmu_translate() and > get_physical_address() One thing to keep in mind (although I don't know the x86 code) is that you want the monitor command not to change any state, nor to fail if there's a particularly screwy page table; so no flagging exceptions or flagging accessed bits or changing the state of the tcg. Dave > Thanks, > > Don > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [PATCH-for-9.1 05/21] target/m68k: Replace qemu_printf() by monitor_printf() in monitor
* BALATON Zoltan (bala...@eik.bme.hu) wrote:
> On Sun, 24 Mar 2024, Dr. David Alan Gilbert wrote:
> > * Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> > > Replace qemu_printf() by monitor_printf() / monitor_puts() in monitor.
> > >
> > > Signed-off-by: Philippe Mathieu-Daudé
> > > ---
> > > target/m68k/cpu.h | 2 +-
> > > target/m68k/helper.c | 126 +-
> > > target/m68k/monitor.c | 4 +-
> > > 3 files changed, 67 insertions(+), 65 deletions(-)
> > >
> > > diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
> > > index 346427e144..4e4307956d 100644
> > > --- a/target/m68k/cpu.h
> > > +++ b/target/m68k/cpu.h
> > > @@ -620,6 +620,6 @@ static inline void cpu_get_tb_cpu_state(CPUM68KState
> > > *env, vaddr *pc,
> > > }
> > > }
> > >
> > > -void dump_mmu(CPUM68KState *env);
> > > +void dump_mmu(Monitor *mon, CPUM68KState *env);
> > >
> > > #endif
> > > diff --git a/target/m68k/helper.c b/target/m68k/helper.c
> > > index 1a475f082a..310e26dfa1 100644
> > > --- a/target/m68k/helper.c
> > > +++ b/target/m68k/helper.c
> > > @@ -25,7 +25,7 @@
> > > #include "exec/helper-proto.h"
> > > #include "gdbstub/helpers.h"
> > > #include "fpu/softfloat.h"
> > > -#include "qemu/qemu-print.h"
> > > +#include "monitor/monitor.h"
> > >
> > > #define SIGNBIT (1u << 31)
> > >
> > > @@ -455,28 +455,30 @@ void m68k_switch_sp(CPUM68KState *env)
> > > #if !defined(CONFIG_USER_ONLY)
> > > /* MMU: 68040 only */
> > >
> > > -static void print_address_zone(uint32_t logical, uint32_t physical,
> > > +static void print_address_zone(Monitor *mon,
> > > + uint32_t logical, uint32_t physical,
> > > uint32_t size, int attr)
> > > {
> > > -qemu_printf("%08x - %08x -> %08x - %08x %c ",
> > > -logical, logical + size - 1,
> > > -physical, physical + size - 1,
> > > -attr & 4 ? 'W' : '-');
> > > +monitor_printf(mon, "%08x - %08x -> %08x - %08x %c ",
> > > + logical, logical + size - 1,
> > > + physical, physical + size - 1,
> > > + attr & 4 ? 'W' : '-');
> > > size >>= 10;
> > > if (size < 1024) {
> > > -qemu_printf("(%d KiB)\n", size);
> > > +monitor_printf(mon, "(%d KiB)\n", size);
> > > } else {
> > > size >>= 10;
> > > if (size < 1024) {
> > > -qemu_printf("(%d MiB)\n", size);
> > > +monitor_printf(mon, "(%d MiB)\n", size);
> > > } else {
> > > size >>= 10;
> > > -qemu_printf("(%d GiB)\n", size);
> > > +monitor_printf(mon, "(%d GiB)\n", size);
> > > }
> > > }
> > > }
> > >
> > > -static void dump_address_map(CPUM68KState *env, uint32_t root_pointer)
> > > +static void dump_address_map(Monitor *mon, CPUM68KState *env,
> > > + uint32_t root_pointer)
> > > {
> > > int i, j, k;
> > > int tic_size, tic_shift;
> > > @@ -545,7 +547,7 @@ static void dump_address_map(CPUM68KState *env,
> > > uint32_t root_pointer)
> > > if (first_logical != 0x) {
> > > size = last_logical + (1 << tic_shift) -
> > > first_logical;
> > > -print_address_zone(first_logical,
> > > +print_address_zone(mon, first_logical,
> > > first_physical, size,
> > > last_attr);
> > > }
> > > first_logical = logical;
> > > @@ -556,125 +558,125 @@ static void dump_address_map(CPUM68KState *env,
> > > uint32_t root_pointer)
> > > }
> > > if (first_logical != logical || (attr & 4) != (last_attr & 4)) {
> > > size = logical + (1 << tic_shift) - first_logical;
> > > -print_address_zone(first_logi
Re: [PATCH-for-9.1 05/21] target/m68k: Replace qemu_printf() by monitor_printf() in monitor
(Monitor *mon, uint32_t ttr)
> {
> if ((ttr & M68K_TTR_ENABLED) == 0) {
> -qemu_printf("disabled\n");
> +monitor_puts(mon, "disabled\n");
> return;
> }
> -qemu_printf("Base: 0x%08x Mask: 0x%08x Control: ",
> -ttr & M68K_TTR_ADDR_BASE,
> -(ttr & M68K_TTR_ADDR_MASK) << M68K_TTR_ADDR_MASK_SHIFT);
> +monitor_printf(mon, "Base: 0x%08x Mask: 0x%08x Control: ",
> + ttr & M68K_TTR_ADDR_BASE,
> + (ttr & M68K_TTR_ADDR_MASK) << M68K_TTR_ADDR_MASK_SHIFT);
> switch (ttr & M68K_TTR_SFIELD) {
> case M68K_TTR_SFIELD_USER:
> -qemu_printf("U");
> +monitor_puts(mon, "U");
> break;
> case M68K_TTR_SFIELD_SUPER:
> -qemu_printf("S");
> +monitor_puts(mon, "S");
> break;
> default:
> -qemu_printf("*");
> +monitor_puts(mon, "*");
> break;
> }
> DUMP_CACHEFLAGS(ttr);
> if (ttr & M68K_DESC_WRITEPROT) {
> -qemu_printf("R");
> +monitor_puts(mon, "R");
> } else {
> -qemu_printf("W");
> +monitor_puts(mon, "W");
> }
> -qemu_printf(" U: %d\n", (ttr & M68K_DESC_USERATTR) >>
> +monitor_printf(mon, " U: %d\n", (ttr & M68K_DESC_USERATTR) >>
> M68K_DESC_USERATTR_SHIFT);
> }
>
> -void dump_mmu(CPUM68KState *env)
> +void dump_mmu(Monitor *mon, CPUM68KState *env)
> {
> if ((env->mmu.tcr & M68K_TCR_ENABLED) == 0) {
> -qemu_printf("Translation disabled\n");
> +monitor_puts(mon, "Translation disabled\n");
> return;
> }
> -qemu_printf("Page Size: ");
> +monitor_puts(mon, "Page Size: ");
> if (env->mmu.tcr & M68K_TCR_PAGE_8K) {
> -qemu_printf("8kB\n");
> +monitor_puts(mon, "8kB\n");
> } else {
> -qemu_printf("4kB\n");
> +monitor_puts(mon, "4kB\n");
> }
>
> -qemu_printf("MMUSR: ");
> +monitor_puts(mon, "MMUSR: ");
> if (env->mmu.mmusr & M68K_MMU_B_040) {
> -qemu_printf("BUS ERROR\n");
> +monitor_puts(mon, "BUS ERROR\n");
> } else {
> -qemu_printf("Phy=%08x Flags: ", env->mmu.mmusr & 0xf000);
> +monitor_printf(mon, "Phy=%08x Flags: ", env->mmu.mmusr & 0xf000);
> /* flags found on the page descriptor */
> if (env->mmu.mmusr & M68K_MMU_G_040) {
> -qemu_printf("G"); /* Global */
> +monitor_puts(mon, "G"); /* Global */
> } else {
> -qemu_printf(".");
> +monitor_puts(mon, ".");
> }
> if (env->mmu.mmusr & M68K_MMU_S_040) {
> -qemu_printf("S"); /* Supervisor */
> +monitor_puts(mon, "S"); /* Supervisor */
> } else {
> -qemu_printf(".");
> +monitor_puts(mon, ".");
> }
> if (env->mmu.mmusr & M68K_MMU_M_040) {
> - qemu_printf("M"); /* Modified */
> +monitor_puts(mon, "M"); /* Modified */
> } else {
> -qemu_printf(".");
> +monitor_puts(mon, ".");
> }
> if (env->mmu.mmusr & M68K_MMU_WP_040) {
> -qemu_printf("W"); /* Write protect */
> +monitor_puts(mon, "W"); /* Write protect */
> } else {
> -qemu_printf(".");
> +monitor_puts(mon, ".");
> }
> if (env->mmu.mmusr & M68K_MMU_T_040) {
> -qemu_printf("T"); /* Transparent */
> +monitor_puts(mon, "T"); /* Transparent */
> } else {
> -qemu_printf(".");
> +monitor_puts(mon, ".");
> }
> if (env->mmu.mmusr & M68K_MMU_R_040) {
> -qemu_printf("R"); /* Resident */
> +monitor_puts(mon, "R"); /* Resident */
> } else {
> -qemu_printf(".");
> +monitor_puts(mon, ".");
> }
> -qemu_printf(" Cache: ");
> +monitor_puts(mon,
Re: [PATCH-for-9.0] monitor/hmp-cmds-target.c: append a space in error message in gpa2hva()
* Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> On 19/3/24 03:16, Shiyang Ruan via wrote:
> > From: Yao Xingtao
> >
> > In qemu monitor mode, when we use gpa2hva command to print the host
> > virtual address corresponding to a guest physical address, if the gpa is
> > not in RAM, the error message is below:
> >
> > (qemu) gpa2hva 0x75000
> > Memory at address 0x75000is not RAM
> >
> > a space is missed between '0x75000' and 'is'.
> >
> > Signed-off-by: Yao Xingtao
> > ---
> > monitor/hmp-cmds-target.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/monitor/hmp-cmds-target.c b/monitor/hmp-cmds-target.c
> > index 9338ae8440..ff01cf9d8d 100644
> > --- a/monitor/hmp-cmds-target.c
> > +++ b/monitor/hmp-cmds-target.c
> > @@ -261,7 +261,7 @@ void *gpa2hva(MemoryRegion **p_mr, hwaddr addr,
> > uint64_t size, Error **errp)
> > }
> > if (!memory_region_is_ram(mrs.mr) && !memory_region_is_romd(mrs.mr)) {
> > -error_setg(errp, "Memory at address 0x%" HWADDR_PRIx "is not RAM",
> > addr);
> > +error_setg(errp, "Memory at address 0x%" HWADDR_PRIx " is not
> > RAM", addr);
> > memory_region_unref(mrs.mr);
> > return NULL;
> > }
>
> Fixes: e9628441df ("hmp: gpa2hva and gpa2hpa hostaddr command")
> Reviewed-by: Philippe Mathieu-Daudé
Thanks,
Reviewed-by: Dr. David Alan Gilbert
Cc'ing in Trivial.
Dave
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH-for-9.0 0/2] target/monitor: Deprecate 'info tlb/mem' in favor of 'info mmu'
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 20 Mar 2024 at 17:06, Philippe Mathieu-Daudé
> wrote:
> >
> > +Alex/Daniel
> >
> > On 20/3/24 17:53, Peter Maydell wrote:
> > > On Wed, 20 Mar 2024 at 16:40, Philippe Mathieu-Daudé
> > > wrote:
> > >>
> > >> 'info tlb' and 'info mem' commands don't scale in heterogeneous
> > >> emulation. They will be reworked after the next release, hidden
> > >> behind the 'info mmu' command. It is not too late to deprecate
> > >> commands, so add the 'info mmu' command as wrapper to the other
> > >> ones, but already deprecate them.
> > >>
> > >> Philippe Mathieu-Daudé (2):
> > >>target/monitor: Introduce 'info mmu' command
> > >>target/monitor: Deprecate 'info tlb' and 'info mem' commands
> > >
> > > This seems to replace "info tlb" and "info mem" with "info mmu -t"
> > > and "info mmu -m", but it doesn't really say anything about:
> > > * what the difference is between these two things
> >
> > I really don't know; I'm only trying to keep the monitor interface
> > identical.
>
> You don't, though: you change it from "info tlb" to "info mmu -t" etc.
>
> > > * which targets implement which and why
> >
> > This one is easy to answer:
> >
> > #if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC)
> > || \
> > defined(TARGET_PPC) || defined(TARGET_XTENSA) || defined(TARGET_M68K)
> > {
> > .name = "tlb",
> >
> > #if defined(TARGET_I386) || defined(TARGET_RISCV)
> > {
> > .name = "mem",
> >
> > > * what the plan is for the future
> >
> > My problem is with linking a single QEMU binary, as these two symbols
> > (hmp_info_mem and hmp_info_tlb) clash.
>
> Yes, but they both (implicitly) operate on the current HMP CPU,
> so the problem with linking into a single binary is that they're
> not indirected through a method on the CPU object, not the syntax
> used in the monitor to invoke them, presumably.
>
> > I'm indeed only postponing the problem, without looking at what
> > this code does. I did it adding hmp_info_mmu_tlb/mem hooks in
> > TCGCPUOps ("hw/core/tcg-cpu-ops.h"), so the command can be
> > dispatched per target vcpu as target-agnostic code in
> > monitor/hmp-cmds.c:
> >
> > +#include "hw/core/tcg-cpu-ops.h"
> > +
> > +static void hmp_info_mmu_tlb(Monitor *mon, CPUState *cpu)
> > +{
> > +const TCGCPUOps *tcg_ops = cpu->cc->tcg_ops;
> > +
> > +if (tcg_ops->hmp_info_mmu_tlb) {
> > +tcg_ops->hmp_info_mmu_tlb(mon, cpu_env(cpu));
> > +} else {
> > +monitor_puts(mon, "No per-CPU information available on this
> > target\n");
> > +}
> > +}
>
> These aren't TCG specific though, so why TCGCPUOps ?
>
> > > I am definitely not a fan of either of these commands, because
> > > (as we currently implement them) they effectively require each
> > > target architecture to implement a second copy of the page table
> > > walking code. But before we can deprecate them we need to be
> > > pretty sure that "info mmu" is what we want to replace them with.
> >
> > An alternative is to just deprecate them, without adding "info mmu" :)
> >
> > It is OK to un-deprecate stuff if we realize its usefulness.
>
> The commands are there because some users find them useful.
> I just dislike them because I think they're a bit niche and
> annoying to implement and not consistent across target
> architectures and not very well documented...
>
> By the way, we have no obligation to follow the deprecate-and-drop
> process for HMP commands; unlike QMP, we give ourselves the
> license to vary it when we feel like it, because the users are
> humans, not programs or scripts.
Right, so no rush to get the deprecation in; change it when you agree
what you'd like a replacement to look like.
Dave
> -- PMM
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH] hmp: Add option to info qtree to omit details
* BALATON Zoltan (bala...@eik.bme.hu) wrote:
> The output of info qtree monitor command is very long. Add an option
> to print a brief overview omitting all the details.
>
> Signed-off-by: BALATON Zoltan
Seems OK to me (I'm not sure I'd have both 'brief' and 'detailed',
but rather stick to one or the other as variable names); still:
Reviewed-by: Dr. David Alan Gilbert
> ---
> hmp-commands-info.hx | 6 +++---
> system/qdev-monitor.c | 24 +---
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index da120f82a3..ad1b1306e3 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -540,9 +540,9 @@ ERST
>
> {
> .name = "qtree",
> -.args_type = "",
> -.params = "",
> -.help = "show device tree",
> +.args_type = "brief:-b",
> +.params = "[-b]",
> +.help = "show device tree (-b: brief, omit properties)",
> .cmd= hmp_info_qtree,
> },
>
> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> index a13db763e5..d5cef36800 100644
> --- a/system/qdev-monitor.c
> +++ b/system/qdev-monitor.c
> @@ -744,7 +744,6 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
> }
>
> #define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ##
> __VA_ARGS__)
> -static void qbus_print(Monitor *mon, BusState *bus, int indent);
>
> static void qdev_print_props(Monitor *mon, DeviceState *dev, Property *props,
> int indent)
> @@ -784,13 +783,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon,
> DeviceState *dev, int ind
> static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
> {
> ObjectClass *class;
> -BusState *child;
> NamedGPIOList *ngl;
> NamedClockList *ncl;
>
> -qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
> -dev->id ? dev->id : "");
> -indent += 2;
> QLIST_FOREACH(ngl, >gpios, node) {
> if (ngl->num_in) {
> qdev_printf("gpio-in \"%s\" %d\n", ngl->name ? ngl->name : "",
> @@ -814,12 +809,9 @@ static void qdev_print(Monitor *mon, DeviceState *dev,
> int indent)
> class = object_class_get_parent(class);
> } while (class != object_class_by_name(TYPE_DEVICE));
> bus_print_dev(dev->parent_bus, mon, dev, indent);
> -QLIST_FOREACH(child, >child_bus, sibling) {
> -qbus_print(mon, child, indent);
> -}
> }
>
> -static void qbus_print(Monitor *mon, BusState *bus, int indent)
> +static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
> {
> BusChild *kid;
>
> @@ -827,16 +819,26 @@ static void qbus_print(Monitor *mon, BusState *bus, int
> indent)
> indent += 2;
> qdev_printf("type %s\n", object_get_typename(OBJECT(bus)));
> QTAILQ_FOREACH(kid, >children, sibling) {
> +BusState *child_bus;
> DeviceState *dev = kid->child;
> -qdev_print(mon, dev, indent);
> +qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
> +dev->id ? dev->id : "");
> +if (details) {
> +qdev_print(mon, dev, indent + 2);
> +}
> +QLIST_FOREACH(child_bus, >child_bus, sibling) {
> +qbus_print(mon, child_bus, indent + 2, details);
> + }
> }
> }
> #undef qdev_printf
>
> void hmp_info_qtree(Monitor *mon, const QDict *qdict)
> {
> +bool brief = qdict_get_try_bool(qdict, "brief", false);
> +
> if (sysbus_get_default())
> -qbus_print(mon, sysbus_get_default(), 0);
> +qbus_print(mon, sysbus_get_default(), 0, !brief);
> }
>
> void hmp_info_qdm(Monitor *mon, const QDict *qdict)
> --
> 2.30.9
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 2/3] hmp: Remove deprecated 'singlestep' command
* Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> This command has been deprecated before the 8.1 release,
> in commit e9ccfdd91d ("hmp: Add 'one-insn-per-tb' command
> equivalent to 'singlestep'"). Time to drop it.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Dr. David Alan Gilbert
> ---
> docs/about/deprecated.rst | 9 -
> docs/about/removed-features.rst | 6 ++
> tests/qtest/test-hmp.c | 1 -
> hmp-commands.hx | 13 -
> 4 files changed, 6 insertions(+), 23 deletions(-)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 25527da423..316a26a82c 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -167,15 +167,6 @@ points was removed in 7.0. However QMP still exposed the
> vcpu
> parameter. This argument has now been deprecated and the remaining
> remaining trace points that used it are selected just by name.
>
> -Human Monitor Protocol (HMP) commands
> --
> -
> -``singlestep`` (since 8.1)
> -''
> -
> -The ``singlestep`` command has been replaced by the ``one-insn-per-tb``
> -command, which has the same behaviour but a less misleading name.
> -
> Host Architectures
> --
>
> diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
> index a8546f4787..855d788259 100644
> --- a/docs/about/removed-features.rst
> +++ b/docs/about/removed-features.rst
> @@ -635,6 +635,12 @@ Use ``migrate-set-parameters`` instead.
>
> This command didn't produce any output already. Removed with no replacement.
>
> +``singlestep`` (removed in 9.0)
> +'''
> +
> +The ``singlestep`` command has been replaced by the ``one-insn-per-tb``
> +command, which has the same behaviour but a less misleading name.
> +
> Guest Emulator ISAs
> ---
>
> diff --git a/tests/qtest/test-hmp.c b/tests/qtest/test-hmp.c
> index fc9125f8bb..1b2e07522f 100644
> --- a/tests/qtest/test-hmp.c
> +++ b/tests/qtest/test-hmp.c
> @@ -64,7 +64,6 @@ static const char *hmp_cmds[] = {
> "qom-get /machine initrd",
> "screendump /dev/null",
> "sendkey x",
> -"singlestep on",
> "wavcapture /dev/null",
> "stopcapture 0",
> "sum 0 512",
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 765349ed14..fc5f5c57ad 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -398,19 +398,6 @@ SRST
>If called with option off, the emulation returns to normal mode.
> ERST
>
> -{
> -.name = "singlestep",
> -.args_type = "option:s?",
> -.params = "[on|off]",
> -.help = "deprecated synonym for one-insn-per-tb",
> - .cmd= hmp_one_insn_per_tb,
> -},
> -
> -SRST
> -``singlestep [off]``
> - This is a deprecated synonym for the one-insn-per-tb command.
> -ERST
> -
> {
> .name = "stop|s",
> .args_type = "",
> --
> 2.41.0
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 2/7] hmp: Improve sync-profile error message
* Markus Armbruster (arm...@redhat.com) wrote:
> Improve
>
> (qemu) sync-profile of
> Error: Invalid parameter 'of'
>
> to
>
> Error: invalid parameter 'of', expecting 'on', 'off', or 'reset'
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Dr. David Alan Gilbert
> ---
> monitor/hmp-cmds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> index 6c559b48c8..871898ac46 100644
> --- a/monitor/hmp-cmds.c
> +++ b/monitor/hmp-cmds.c
> @@ -24,7 +24,6 @@
> #include "qapi/qapi-commands-control.h"
> #include "qapi/qapi-commands-misc.h"
> #include "qapi/qmp/qdict.h"
> -#include "qapi/qmp/qerror.h"
> #include "qemu/cutils.h"
> #include "hw/intc/intc.h"
> #include "qemu/log.h"
> @@ -138,7 +137,8 @@ void hmp_sync_profile(Monitor *mon, const QDict *qdict)
> } else {
> Error *err = NULL;
>
> -error_setg(, QERR_INVALID_PARAMETER, op);
> +error_setg(, "invalid parameter '%s',"
> + " expecting 'on', 'off', or 'reset'", op);
> hmp_handle_error(mon, err);
> }
> }
> --
> 2.41.0
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [RFC PATCH] hmp: implement hmp_ram_memory_dump
* Alex Bennée (alex.ben...@linaro.org) wrote:
> While reviewing the tb-stats series I was confused by the different
> between physical and ram address. This implements the RAM dump so I
> can replicate the disassembly of "info tb". Whether or not that is a
> good idea remains to be discussed.
Do you have the definition of what the address space for info tb is?
> Based-on: 20231003183058.1639121-1-richard.hender...@linaro.org
> Signed-off-by: Alex Bennée
> Cc: Richard Henderson
> ---
> include/monitor/hmp-target.h | 1 +
> monitor/hmp-cmds-target.c| 10 ++
> hmp-commands.hx | 19 ++-
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/include/monitor/hmp-target.h b/include/monitor/hmp-target.h
> index 730507bd65..a3fa7dc089 100644
> --- a/include/monitor/hmp-target.h
> +++ b/include/monitor/hmp-target.h
> @@ -50,6 +50,7 @@ void hmp_info_sgx(Monitor *mon, const QDict *qdict);
> void hmp_info_via(Monitor *mon, const QDict *qdict);
> void hmp_memory_dump(Monitor *mon, const QDict *qdict);
> void hmp_physical_memory_dump(Monitor *mon, const QDict *qdict);
> +void hmp_ram_memory_dump(Monitor *mon, const QDict *qdict);
> void hmp_info_registers(Monitor *mon, const QDict *qdict);
> void hmp_gva2gpa(Monitor *mon, const QDict *qdict);
> void hmp_gpa2hva(Monitor *mon, const QDict *qdict);
> diff --git a/monitor/hmp-cmds-target.c b/monitor/hmp-cmds-target.c
> index 476cf68e81..21ce790502 100644
> --- a/monitor/hmp-cmds-target.c
> +++ b/monitor/hmp-cmds-target.c
> @@ -253,6 +253,16 @@ void hmp_physical_memory_dump(Monitor *mon, const QDict
> *qdict)
> memory_dump(mon, count, format, size, addr, MON_DISAS_GPA);
> }
>
> +void hmp_ram_memory_dump(Monitor *mon, const QDict *qdict)
> +{
> +int count = qdict_get_int(qdict, "count");
> +int format = qdict_get_int(qdict, "format");
How does that does match your described '/countformatsize' syntax
you list below?
This just looks like 3 separate parameters; but I guess that's a copy.
> +int size = qdict_get_int(qdict, "size");
> +hwaddr addr = qdict_get_int(qdict, "addr");
> +
> +memory_dump(mon, count, format, size, addr, MON_DISAS_GRA);
OK, so really the only difference is that flag.
> +}
> +
> void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, uint64_t size, Error **errp)
> {
> Int128 gpa_region_size;
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index e1d78ab69d..5a9ecefdcb 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -471,7 +471,10 @@ ERST
>
> SRST
> ``x/``\ *fmt* *addr*
> - Virtual memory dump starting at *addr*.
> + Virtual memory dump starting at *addr*. See xp/ for physical memory and
> xr/ for ram
> +
> + *fmt* is a format which tells the command how to format the
> + data. Its syntax is: ``/{count}{format}{size}``
> ERST
>
> {
> @@ -530,7 +533,21 @@ SRST
> 0x000b8090: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
>
> ERST
> +{
> +.name = "xr",
> +.args_type = "fmt:/,addr:l",
> +.params = "/fmt addr",
> +.help = "ram memory dump starting at 'addr'",
> +.cmd= hmp_ram_memory_dump,
> +},
> +
> +SRST
> +``xr /``\ *fmt* *addr*
> + RAM memory dump starting at *addr*. See xp/ for physical and x/ for
> virtual memory
>
> + *fmt* is a format which tells the command how to format the
> + data. Its syntax is: ``/{count}{format}{size}``
> +ERST
> {
> .name = "gpa2hva",
> .args_type = "addr:l",
> --
> 2.39.2
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH 4/4] qapi: introduce CONFIG_READ event
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Wed, Oct 18, 2023 at 02:02:08PM +0200, Markus Armbruster wrote: > > Daniel P. Berrangé writes: > > > > > On Wed, Oct 18, 2023 at 06:51:41AM -0400, Michael S. Tsirkin wrote: > > >> On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote: > > >> > > x- seems safer for management tool that doesn't know about > > >> > > "unstable" properties.. > > >> > > > >> > Easy, traditional, and unreliable :) > > >> > > >> > > But on the other hand, changing from x- to no-prefix is already > > >> > > done when the feature is stable, and thouse who use it already > > >> > > use the latest version of interface, so, removing the prefix is > > >> > > just extra work. > > >> > > > >> > Exactly. > > >> > > > >> > > >> I think "x-" is still better for command line use of properties - we > > >> don't have an API to mark things unstable there, do we? > > > > > > Personally I like to see "x-" prefix present *everywhere* there is > > > an unstable feature, and consider the need to rename when declaring > > > it stable to be good thing as it sets an easily identifiable line > > > in the sand and is self-evident to outside observers. > > > > > > The self-documenting nature of the "x-" prefer is what makes it most > > > compelling to me. A patch submission, or command line invokation or > > > an example QMP command, or a bug report, that exhibit an 'x-' prefix > > > are an immediate red flag to anyone who sees them. > > > > Except when it isn't, like in "x-origin". > > > > > If someone sees a QMP comamnd / a typical giant QEMU command line, > > > they are never going to go look at the QAPI schema to check whether > > > any feature used had an 'unstable' marker. The 'unstable' marker > > > might as well not exist in most cases. > > > > > > IOW, having the 'unstable' flag in the QAPI schema is great for machine > > > introspection, but it isn't a substitute for having an 'x-' prefix used > > > for the benefit of humans IMHO. > > > > I'm not sure there's disagreement. Quoting myself: > > > > The "x-" can remind humans "this is unstable" better than a feature > > flag can (for machines, it's the other way round). > > > > CLI and HMP are for humans. We continue to use "x-" there. > > > > QMP is for machines. The feature flag is the sole source of truth. > > Additional use of "x-" is fine, but not required. > > I guess we have different defintions of "for humans" in this context. > I consider QMP data still relevant for humans, because humans are > reviewing patches to libvirt that add usage of QMP features, or > triaging bug reports that include examples of usage, and in both > cases it is pretty relevant to make unstable features stand out to > the human via the x- prefix IMHO. Using x- for events makes sense to me; the semantics of events can be quite subtle; often you don't find out how broken they are until you wire them through libvirt and up the stack; so it's not impossible you might need to change it - but then without the x- the semantics (rather than existence) of the event is carved in stone. Dave > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [RFC 1/3] hmp: avoid the nested event loop in handle_hmp_command()
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Thu, 7 Sept 2023 at 10:07, Dr. David Alan Gilbert wrote:
> >
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > On Thu, Sep 07, 2023 at 01:06:39AM +, Dr. David Alan Gilbert wrote:
> > > > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > > > Coroutine HMP commands currently run to completion in a nested event
> > > > > loop with the Big QEMU Lock (BQL) held. The call_rcu thread also uses
> > > > > the BQL and cannot process work while the coroutine monitor command is
> > > > > running. A deadlock occurs when monitor commands attempt to wait for
> > > > > call_rcu work to finish.
> > > >
> > > > I hate to think if there's anywhere else that ends up doing that
> > > > other than the monitors.
> > >
> > > Luckily drain_call_rcu() has few callers: just
> > > xen_block_device_destroy() and qmp_device_add(). We only need to worry
> > > about their call stacks.
> > >
> > > I haven't looked at the Xen code.
> > >
> > > >
> > > > But, not knowing the semantics of the rcu code, it looks kind of OK to
> > > > me from the monitor.
> > > >
> > > > (Do you ever get anything like qemu quitting from one of the other
> > > > monitors while this coroutine hasn't been run?)
> > >
> > > Not sure what you mean?
> >
> > Imagine that just after you create your coroutine, a vCPU does a
> > shutdown and qemu is configured to quit, or on another monitor someone
> > does a quit; does your coroutine get executed or not?
>
> I think the answer is that it depends.
>
> A coroutine can run for a while and then yield while waiting for a
> timer, BH, fd handler, etc. If the coroutine has yielded then I think
> QEMU could terminate.
>
> The behavior of entering a coroutine for the first time depends on the
> API that is used (e.g. qemu_coroutine_enter()/aio_co_enter()/etc).
> qemu_coroutine_enter() is immediate but aio_co_enter() contains
> indirect code paths like scheduling a BH.
>
> To summarize: ¯\_(ツ)_/¯
That does mean you leave your g_new'd data and qdict allocated at
exit - meh
I'm not sure if it means you're making any other assumptions about what
happens if the coroutine gets run during the exit path; although I guess
there are plenty of other cases like that.
Dave
> Stefan
>
> >
> > Dave
> >
> > > Stefan
> > >
> > > >
> > > > Dave
> > > >
> > > > > This patch refactors the HMP monitor to use the existing event loop
> > > > > instead of creating a nested event loop. This will allow the next
> > > > > patches to rely on draining call_rcu work.
> > > > >
> > > > > Signed-off-by: Stefan Hajnoczi
> > > > > ---
> > > > > monitor/hmp.c | 28 +++-
> > > > > 1 file changed, 15 insertions(+), 13 deletions(-)
> > > > >
> > > > > diff --git a/monitor/hmp.c b/monitor/hmp.c
> > > > > index 69c1b7e98a..6cff2810aa 100644
> > > > > --- a/monitor/hmp.c
> > > > > +++ b/monitor/hmp.c
> > > > > @@ -,15 +,17 @@ typedef struct HandleHmpCommandCo {
> > > > > Monitor *mon;
> > > > > const HMPCommand *cmd;
> > > > > QDict *qdict;
> > > > > -bool done;
> > > > > } HandleHmpCommandCo;
> > > > >
> > > > > -static void handle_hmp_command_co(void *opaque)
> > > > > +static void coroutine_fn handle_hmp_command_co(void *opaque)
> > > > > {
> > > > > HandleHmpCommandCo *data = opaque;
> > > > > +
> > > > > handle_hmp_command_exec(data->mon, data->cmd, data->qdict);
> > > > > monitor_set_cur(qemu_coroutine_self(), NULL);
> > > > > -data->done = true;
> > > > > +qobject_unref(data->qdict);
> > > > > +monitor_resume(data->mon);
> > > > > +g_free(data);
> > > > > }
> > > > >
> > > > > void handle_hmp_command(MonitorHMP *mon, const char *cmdline)
> > > > > @@ -1157,20 +1159,20 @@ void handle_hmp_command(MonitorHMP *mon,
> > > > > const char *cmdline)
> > > > > Monitor *old_mon = monitor_set_cur(qemu_coroutine_self(),
> > > > > >common);
> > > > > handle_h
Re: [RFC 1/3] hmp: avoid the nested event loop in handle_hmp_command()
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Thu, Sep 07, 2023 at 01:06:39AM +0000, Dr. David Alan Gilbert wrote:
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > Coroutine HMP commands currently run to completion in a nested event
> > > loop with the Big QEMU Lock (BQL) held. The call_rcu thread also uses
> > > the BQL and cannot process work while the coroutine monitor command is
> > > running. A deadlock occurs when monitor commands attempt to wait for
> > > call_rcu work to finish.
> >
> > I hate to think if there's anywhere else that ends up doing that
> > other than the monitors.
>
> Luckily drain_call_rcu() has few callers: just
> xen_block_device_destroy() and qmp_device_add(). We only need to worry
> about their call stacks.
>
> I haven't looked at the Xen code.
>
> >
> > But, not knowing the semantics of the rcu code, it looks kind of OK to
> > me from the monitor.
> >
> > (Do you ever get anything like qemu quitting from one of the other
> > monitors while this coroutine hasn't been run?)
>
> Not sure what you mean?
Imagine that just after you create your coroutine, a vCPU does a
shutdown and qemu is configured to quit, or on another monitor someone
does a quit; does your coroutine get executed or not?
Dave
> Stefan
>
> >
> > Dave
> >
> > > This patch refactors the HMP monitor to use the existing event loop
> > > instead of creating a nested event loop. This will allow the next
> > > patches to rely on draining call_rcu work.
> > >
> > > Signed-off-by: Stefan Hajnoczi
> > > ---
> > > monitor/hmp.c | 28 +++-
> > > 1 file changed, 15 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/monitor/hmp.c b/monitor/hmp.c
> > > index 69c1b7e98a..6cff2810aa 100644
> > > --- a/monitor/hmp.c
> > > +++ b/monitor/hmp.c
> > > @@ -,15 +,17 @@ typedef struct HandleHmpCommandCo {
> > > Monitor *mon;
> > > const HMPCommand *cmd;
> > > QDict *qdict;
> > > -bool done;
> > > } HandleHmpCommandCo;
> > >
> > > -static void handle_hmp_command_co(void *opaque)
> > > +static void coroutine_fn handle_hmp_command_co(void *opaque)
> > > {
> > > HandleHmpCommandCo *data = opaque;
> > > +
> > > handle_hmp_command_exec(data->mon, data->cmd, data->qdict);
> > > monitor_set_cur(qemu_coroutine_self(), NULL);
> > > -data->done = true;
> > > +qobject_unref(data->qdict);
> > > +monitor_resume(data->mon);
> > > +g_free(data);
> > > }
> > >
> > > void handle_hmp_command(MonitorHMP *mon, const char *cmdline)
> > > @@ -1157,20 +1159,20 @@ void handle_hmp_command(MonitorHMP *mon, const
> > > char *cmdline)
> > > Monitor *old_mon = monitor_set_cur(qemu_coroutine_self(),
> > > >common);
> > > handle_hmp_command_exec(>common, cmd, qdict);
> > > monitor_set_cur(qemu_coroutine_self(), old_mon);
> > > +qobject_unref(qdict);
> > > } else {
> > > -HandleHmpCommandCo data = {
> > > -.mon = >common,
> > > -.cmd = cmd,
> > > -.qdict = qdict,
> > > -.done = false,
> > > -};
> > > -Coroutine *co = qemu_coroutine_create(handle_hmp_command_co,
> > > );
> > > +HandleHmpCommandCo *data; /* freed by handle_hmp_command_co() */
> > > +
> > > +data = g_new(HandleHmpCommandCo, 1);
> > > +data->mon = >common;
> > > +data->cmd = cmd;
> > > +data->qdict = qdict; /* freed by handle_hmp_command_co() */
> > > +
> > > +Coroutine *co = qemu_coroutine_create(handle_hmp_command_co,
> > > data);
> > > +monitor_suspend(>common); /* resumed by
> > > handle_hmp_command_co() */
> > > monitor_set_cur(co, >common);
> > > aio_co_enter(qemu_get_aio_context(), co);
> > > -AIO_WAIT_WHILE_UNLOCKED(NULL, !data.done);
> > > }
> > > -
> > > -qobject_unref(qdict);
> > > }
> > >
> > > static void cmd_completion(MonitorHMP *mon, const char *name, const char
> > > *list)
> > > --
> > > 2.41.0
> > >
> > >
> > --
> > -Open up your eyes, open up your mind, open up your code ---
> > / Dr. David Alan Gilbert| Running GNU/Linux | Happy \
> > \dave @ treblig.org | | In Hex /
> > \ _|_ http://www.treblig.org |___/
> >
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [RFC 1/3] hmp: avoid the nested event loop in handle_hmp_command()
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> Coroutine HMP commands currently run to completion in a nested event
> loop with the Big QEMU Lock (BQL) held. The call_rcu thread also uses
> the BQL and cannot process work while the coroutine monitor command is
> running. A deadlock occurs when monitor commands attempt to wait for
> call_rcu work to finish.
I hate to think if there's anywhere else that ends up doing that
other than the monitors.
But, not knowing the semantics of the rcu code, it looks kind of OK to
me from the monitor.
(Do you ever get anything like qemu quitting from one of the other
monitors while this coroutine hasn't been run?)
Dave
> This patch refactors the HMP monitor to use the existing event loop
> instead of creating a nested event loop. This will allow the next
> patches to rely on draining call_rcu work.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> monitor/hmp.c | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/monitor/hmp.c b/monitor/hmp.c
> index 69c1b7e98a..6cff2810aa 100644
> --- a/monitor/hmp.c
> +++ b/monitor/hmp.c
> @@ -,15 +,17 @@ typedef struct HandleHmpCommandCo {
> Monitor *mon;
> const HMPCommand *cmd;
> QDict *qdict;
> -bool done;
> } HandleHmpCommandCo;
>
> -static void handle_hmp_command_co(void *opaque)
> +static void coroutine_fn handle_hmp_command_co(void *opaque)
> {
> HandleHmpCommandCo *data = opaque;
> +
> handle_hmp_command_exec(data->mon, data->cmd, data->qdict);
> monitor_set_cur(qemu_coroutine_self(), NULL);
> -data->done = true;
> +qobject_unref(data->qdict);
> +monitor_resume(data->mon);
> +g_free(data);
> }
>
> void handle_hmp_command(MonitorHMP *mon, const char *cmdline)
> @@ -1157,20 +1159,20 @@ void handle_hmp_command(MonitorHMP *mon, const char
> *cmdline)
> Monitor *old_mon = monitor_set_cur(qemu_coroutine_self(),
> >common);
> handle_hmp_command_exec(>common, cmd, qdict);
> monitor_set_cur(qemu_coroutine_self(), old_mon);
> +qobject_unref(qdict);
> } else {
> -HandleHmpCommandCo data = {
> -.mon = >common,
> -.cmd = cmd,
> -.qdict = qdict,
> -.done = false,
> -};
> -Coroutine *co = qemu_coroutine_create(handle_hmp_command_co, );
> +HandleHmpCommandCo *data; /* freed by handle_hmp_command_co() */
> +
> +data = g_new(HandleHmpCommandCo, 1);
> +data->mon = >common;
> +data->cmd = cmd;
> +data->qdict = qdict; /* freed by handle_hmp_command_co() */
> +
> +Coroutine *co = qemu_coroutine_create(handle_hmp_command_co, data);
> +monitor_suspend(>common); /* resumed by handle_hmp_command_co()
> */
> monitor_set_cur(co, >common);
> aio_co_enter(qemu_get_aio_context(), co);
> -AIO_WAIT_WHILE_UNLOCKED(NULL, !data.done);
> }
> -
> -qobject_unref(qdict);
> }
>
> static void cmd_completion(MonitorHMP *mon, const char *name, const char
> *list)
> --
> 2.41.0
>
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH v14 08/10] Adding info [tb-list|tb] commands to HMP (WIP)
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Thu, 8 Jun 2023 at 08:44, Wu, Fei wrote: > > > > On 6/7/2023 8:49 PM, Wu, Fei wrote: > > > On 6/1/2023 10:40 AM, Richard Henderson wrote: > > >> Did you really need something different than monitor_disas? You almost > > >> certainly want to read physical memory and not virtual anyway. > > >> > > > Yes, it's usually okay for kernel address, but cannot re-gen the code > > > for userspace virtual address (guest kernel panic on riscv guest). I > > > tried monitor_disas() but it failed to disas too: > > > monitor_disas(mon, mon_get_cpu(mon), tbs->phys_pc, num_inst, true); > > > > > > How to use this function correctly? > > > > > 'phys_pc' in tbs is returned by get_page_addr_code_hostp(), which is not > > guest phys address actually, but ram_addr_t instead, so it's always > > wrong for monitor_disas. After some dirty changes, tbs can record the > > guest pa. Now we can disas both kernel and user space code. But still, > > no code is regenerated, disas in 'info tb' is just a convenient way to 'xp'. > > > > Is there any existing function to convert ram_addr_t to guest pa? > > Such a function would not be well-defined, because a block of RAM > as specified by a ram_addr_t could be present at (aliased to) multiple > guest physical addresses, or even currently not mapped to any guest > physical address at all. And it could be present at different physical > addresses for different vCPUs. True, but isn't there a similar mechanism for when an MCE happens in the host memory? Dave > thanks > -- PMM -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [RFC PATCH 1/1] virtio-balloon: Add Working Set Reporting feature
* T.J. Alumbaugh (talum...@google.com) wrote:
> On Tue, May 16, 2023 at 5:03 AM Dr. David Alan Gilbert
> wrote:
> >
> > * T.J. Alumbaugh (talum...@google.com) wrote:
> > > Working Set Reporting supported in virtio-balloon.
> > > - adds working set reporting and notification vqueues
> > > - QMP API additions:
> > >- guest-ws property on balloon
> > >- generates QMP WS_EVENT when new reports available
> > >- ws_config, ws_request commands
> >
> > Hi,
> > 1st it's probably best to split this patch up into a few
> > separate patches; something like:
> > 1) Updating the virtio_balloon header
> > 2) the main virtio-balloon code
> > 3) Adding the qmp code
> > 4) Adding the HMP code
> > 5) The migration code
> >
> > That would make it easier for people to review
> > the bits they know.
> >
> > Also, please make sure migration works between a host
> > without this feature and one which does; I suggest
> > turning the feature off in older machine types, and
> > also just checking that it works.
> >
>
> Thanks very much for this feedback. This makes sense to me. I had
> originally attempted to split the patch into 2 (all device changes and
> all qmp + HMP) but got compilation warnings (that became errors) on
> uncalled functions due to the default compiler settings (since some of
> the new functions in the device only exist in order to be called by
> QMP). It sounds like that's OK for the purposes of review. I'll do as
> you suggest and update with a v2 soon.
You can add __attribute__((unused)) in the earlier patch and remove
them in the later one; but that should be fairly rare.
Dave
> -T.J.
>
> > See more comments below.
> >
> > Dave
> >
> > > Signed-off-by: T.J. Alumbaugh
> > > ---
> > > hmp-commands.hx | 26 ++
> > > hw/core/machine-hmp-cmds.c| 21 ++
> > > hw/virtio/virtio-balloon-pci.c| 2 +
> > > hw/virtio/virtio-balloon.c| 225 +-
> > > include/hw/virtio/virtio-balloon.h| 17 +-
> > > include/monitor/hmp.h | 2 +
> > > .../standard-headers/linux/virtio_balloon.h | 17 ++
> > > include/sysemu/balloon.h | 8 +-
> > > monitor/monitor.c | 1 +
> > > qapi/machine.json | 66 +
> > > qapi/misc.json| 26 ++
> > > softmmu/balloon.c | 32 ++-
> > > 12 files changed, 437 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/hmp-commands.hx b/hmp-commands.hx
> > > index 9afbb54a51..f3548a148f 100644
> > > --- a/hmp-commands.hx
> > > +++ b/hmp-commands.hx
> > > @@ -1396,6 +1396,32 @@ SRST
> > >Request VM to change its memory allocation to *value* (in MB).
> > > ERST
> > >
> > > +{
> > > +.name = "ws_config",
> > > +.args_type = "i0:i,i1:i,i2:i,refresh:i,report:i",
> > > +.params = "bin intervals 0-2, refresh and report thresholds",
> > > +.help = "Working Set intervals, refresh/report thresholds
> > > (ms)",
> > > +.cmd= hmp_ws_config,
> > > +},
> > > +
> > > +SRST
> > > +``ws_config``
> > > + Set the intervals (in ms), refresh, and report thresholds for WS
> > > reporting
> > > +ERST
> > > +
> > > +{
> > > +.name = "ws_request",
> > > +.args_type = "",
> > > +.params = "",
> > > +.help = "Request the Working Set of the guest.",
> > > +.cmd= hmp_ws_request,
> > > +},
> > > +
> > > +SRST
> > > +``wss_request``
> >
> > Typo 'ws*s*'
> >
> > Some other comments on that:
> > a) When you've split the hmp stuff out into a separate patch you can
> > give an example of the command (especially ws_config) in the
> > commit message.
> >
> > b) Would it make sense to have a query-ws/info ws to display the last
> > received
> > working set info?
> >
> > c) Some may feel 'ws' is a bit terse and want the unabbreviated
> > version. (Is it also general, or is it actually virtio balloon
> >
Re: [RFC PATCH 1/1] virtio-balloon: Add Working Set Reporting feature
100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -523,6 +523,32 @@
> { 'struct': 'CommandLineOptionInfo',
>'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
>
> +##
> +# @MemoryBin:
> +#
> +# A bin of memory with a size in bytes. File-backed and
> +# anonymous memory are tracked separately.
> +#
> +# @anon: number of bytes of anonymous memory
> +# @file: number of bytes of file-backed memory
> +##
> +{ 'struct': 'MemoryBin',
> + 'data': { 'anon': 'uint64',
> +'file': 'uint64' } }
> +
> +##
> +# @WorkingSetInfo:
> +#
> +# A bin of memory of the given size that has been idle at most `idle-age` ms
> +#
> +# @idle-age: guest-relative time (in milliseconds)
> +#
> +# @memory-size-bytes: A MemoryBin with file and anon info.
> +##
> +{ 'struct': 'WorkingSetInfo',
> + 'data': { 'idle-age': 'uint64',
> +'memory-size-bytes': 'MemoryBin' } }
> +
> ##
> # @query-command-line-options:
> #
> diff --git a/softmmu/balloon.c b/softmmu/balloon.c
> index e0e8969a4b..8ff30fe43b 100644
> --- a/softmmu/balloon.c
> +++ b/softmmu/balloon.c
> @@ -35,6 +35,8 @@
>
> static QEMUBalloonEvent *balloon_event_fn;
> static QEMUBalloonStatus *balloon_stat_fn;
> +static QEMUBalloonWSRequest *balloon_ws_request_fn;
> +static QEMUBalloonWSConfig *balloon_ws_config_fn;
> static void *balloon_opaque;
>
> static bool have_balloon(Error **errp)
> @@ -53,9 +55,12 @@ static bool have_balloon(Error **errp)
> }
>
> int qemu_add_balloon_handler(QEMUBalloonEvent *event_func,
> - QEMUBalloonStatus *stat_func, void *opaque)
> + QEMUBalloonStatus *stat_func,
> + QEMUBalloonWSRequest *ws_request_func,
> + QEMUBalloonWSConfig *ws_config_func, void
> *opaque)
> {
> -if (balloon_event_fn || balloon_stat_fn || balloon_opaque) {
> +if (balloon_event_fn || balloon_stat_fn || balloon_ws_request_fn \
> +|| balloon_ws_config_fn || balloon_opaque) {
> /* We're already registered one balloon handler. How many can
> * a guest really have?
> */
> @@ -63,6 +68,8 @@ int qemu_add_balloon_handler(QEMUBalloonEvent *event_func,
> }
> balloon_event_fn = event_func;
> balloon_stat_fn = stat_func;
> +balloon_ws_request_fn = ws_request_func;
> +balloon_ws_config_fn = ws_config_func;
> balloon_opaque = opaque;
> return 0;
> }
> @@ -74,6 +81,8 @@ void qemu_remove_balloon_handler(void *opaque)
> }
> balloon_event_fn = NULL;
> balloon_stat_fn = NULL;
> +balloon_ws_request_fn = NULL;
> +balloon_ws_config_fn = NULL;
> balloon_opaque = NULL;
> }
>
> @@ -104,3 +113,22 @@ void qmp_balloon(int64_t target, Error **errp)
> trace_balloon_event(balloon_opaque, target);
> balloon_event_fn(balloon_opaque, target);
> }
> +
> +void qmp_ws_request(Error **errp)
> +{
> +if (!have_balloon(errp)) {
> +return;
> +}
> +
> +balloon_ws_request_fn(balloon_opaque);
> +}
> +
> +void qmp_ws_config(uint64_t i0, uint64_t i1, uint64_t i2, uint64_t refresh,
> + uint64_t report, Error **errp)
> +{
> +if (!have_balloon(errp)) {
> +return;
> +}
> +
> +balloon_ws_config_fn(balloon_opaque, i0, i1, i2, refresh, report);
> +}
> --
> 2.40.1.521.gf1e218fcd8-goog
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION
* Vladimir Sementsov-Ogievskiy (vsement...@yandex-team.ru) wrote:
> We don't allow to use x-colo capability when replication is not
> configured. So, no reason to build COLO when replication is disabled,
> it's unusable in this case.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> hmp-commands.hx| 2 ++
> migration/colo.c | 6 +
> migration/meson.build | 6 +++--
> migration/migration-hmp-cmds.c | 2 ++
> migration/migration.c | 19 +++---
> net/meson.build| 5 +++-
> qapi/migration.json| 12 ++---
> stubs/colo.c | 47 ++
> stubs/meson.build | 1 +
> 9 files changed, 78 insertions(+), 22 deletions(-)
> create mode 100644 stubs/colo.c
>
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index bb85ee1d26..fbd0932232 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -1035,6 +1035,7 @@ SRST
>migration (or once already in postcopy).
> ERST
>
> +#ifdef CONFIG_REPLICATION
> {
> .name = "x_colo_lost_heartbeat",
> .args_type = "",
> @@ -1043,6 +1044,7 @@ ERST
>"a failover or takeover is needed.",
> .cmd = hmp_x_colo_lost_heartbeat,
> },
> +#endif
We seem to be inconsistent about whether the ifdef includes the
SRST/ERST doc section; some ifdef do and some don't; and thus
it depends whether or not you want the command documented
even though it's compiled out.
I think it's probably OK, but maybe worth reconsidering:
Acked-by: Dr. David Alan Gilbert
> SRST
> ``x_colo_lost_heartbeat``
> diff --git a/migration/colo.c b/migration/colo.c
> index 0716e64689..089c491d70 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -196,6 +196,12 @@ COLOMode get_colo_mode(void)
> }
> }
>
> +bool migrate_colo_enabled(void)
> +{
> +MigrationState *s = migrate_get_current();
> +return s->enabled_capabilities[MIGRATION_CAPABILITY_X_COLO];
> +}
> +
> void colo_do_failover(void)
> {
> /* Make sure VM stopped while failover happened. */
> diff --git a/migration/meson.build b/migration/meson.build
> index 0d1bb9f96e..3fccf79f12 100644
> --- a/migration/meson.build
> +++ b/migration/meson.build
> @@ -13,8 +13,6 @@ softmmu_ss.add(files(
>'block-dirty-bitmap.c',
>'channel.c',
>'channel-block.c',
> - 'colo-failover.c',
> - 'colo.c',
>'exec.c',
>'fd.c',
>'global_state.c',
> @@ -29,6 +27,10 @@ softmmu_ss.add(files(
>'threadinfo.c',
> ), gnutls)
>
> +if get_option('replication').allowed()
> + softmmu_ss.add(files('colo-failover.c', 'colo.c'))
> +endif
> +
> softmmu_ss.add(when: rdma, if_true: files('rdma.c'))
> if get_option('live_block_migration').allowed()
>softmmu_ss.add(files('block.c'))
> diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
> index 72519ea99f..4601c48f41 100644
> --- a/migration/migration-hmp-cmds.c
> +++ b/migration/migration-hmp-cmds.c
> @@ -640,6 +640,7 @@ void hmp_migrate_start_postcopy(Monitor *mon, const QDict
> *qdict)
> hmp_handle_error(mon, err);
> }
>
> +#ifdef CONFIG_REPLICATION
> void hmp_x_colo_lost_heartbeat(Monitor *mon, const QDict *qdict)
> {
> Error *err = NULL;
> @@ -647,6 +648,7 @@ void hmp_x_colo_lost_heartbeat(Monitor *mon, const QDict
> *qdict)
> qmp_x_colo_lost_heartbeat();
> hmp_handle_error(mon, err);
> }
> +#endif
>
> typedef struct HMPMigrationStatus {
> QEMUTimer *timer;
> diff --git a/migration/migration.c b/migration/migration.c
> index bda4789193..2382958364 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -165,7 +165,9 @@
> INITIALIZE_MIGRATE_CAPS_SET(check_caps_background_snapshot,
> MIGRATION_CAPABILITY_RDMA_PIN_ALL,
> MIGRATION_CAPABILITY_COMPRESS,
> MIGRATION_CAPABILITY_XBZRLE,
> +#ifdef CONFIG_REPLICATION
> MIGRATION_CAPABILITY_X_COLO,
> +#endif
> MIGRATION_CAPABILITY_VALIDATE_UUID,
> MIGRATION_CAPABILITY_ZERO_COPY_SEND);
>
> @@ -1329,15 +1331,6 @@ static bool migrate_caps_check(bool *cap_list,
> }
> #endif
>
> -#ifndef CONFIG_REPLICATION
> -if (cap_list[MIGRATION_CAPABILITY_X_COLO]) {
> -error_setg(errp, "QEMU compiled without replication module"
> - " can't enable COLO");
> -error_append_hint(errp, "Please enable replication before COLO.\n");
> -return false;
> -}
> -#endif
> -
> if (cap_list[MIGRATION_CAPABILITY_POSTCOPY_RAM]) {
>
Re: [PATCH v2 10/10] hmp: Deprecate 'singlestep' member of StatusInfo
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Wed, 5 Apr 2023 at 15:56, Dr. David Alan Gilbert > wrote: > > > > * Peter Maydell (peter.mayd...@linaro.org) wrote: > > > I think on balance I would go for: > > > * remove (ie deprecate-and-drop) 'singlestep' from the QMP struct, > > >rather than merely renaming it > > > * if anybody comes along and says they want to do this via QMP, > > >implement Paolo's idea of putting the accelerator object > > >somewhere they can get at it and use qom-get/qom-set on it > > >[My guess is this is very unlikely: nobody's complained so > > >far that QMP doesn't permit setting 'singlestep'; and > > >wanting read without write seems even more marginal.] > > > * keep the HMP commands, but have both read and write directly > > >talk to the accel object. I favour splitting the 'read' > > >part out into its own 'info one-insn-per-tb', for consistency > > >(then 'info status' matches the QMP query-status) > > > > If it's pretty obscure, then the qom-set/get is fine; as long > > as there is a way to do it, then just make sure in the commit > > message you say what the replacement command is > > The point is that there isn't a replacement way to do it > *right now*, but that we have a sketch of how we'd do it if > anybody showed up and really cared about it. I think the chances > of that happening are quite close to zero, so I don't > want to do the work to actually implement the mechanism > on spec... Sure, then just drop it. Dave > -- PMM > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2 10/10] hmp: Deprecate 'singlestep' member of StatusInfo
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 4 Apr 2023 at 14:25, Markus Armbruster wrote: > > > > Peter Maydell writes: > > > > > On Tue, 4 Apr 2023 at 09:25, Markus Armbruster wrote: > > >> Hmm. We report it in query-status, which means it's relevant to QMP > > >> clients. We provide the command to control it only in HMP, which means > > >> it's not relevant to QMP clients. > > >> > > >> Why is reading it relevant to QMP clients, but not writing? > > > > > > I suspect that neither is very relevant to QMP clients, but I > > > thought we had a requirement that HMP interfaces went > > > via QMP ones ? > > > > Kind of. Here's my current boilerplate on the subject: > > > > HMP commands without a QMP equivalent are okay if their > > functionality makes no sense in QMP, or is of use only for human > > users. > > > > Example for "makes no sense in QMP": setting the current CPU, > > because a QMP monitor doesn't have a current CPU. > > > > Examples for "is of use only for human users": HMP command "help", > > the integrated pocket calculator. > > > > Debugging commands are kind of borderline. Debugging is commonly a > > human activity, where HMP is just fine. However, humans create > > tools to assist with their activities, and then QMP is useful. > > While I wouldn't encourage HMP-only for the debugging use case, I > > wouldn't veto it. > > > > When adding an HMP-only command, explain why it is HMP-only in the > > commit message. > > > > >If not, we could just make the HMP query > > > interface directly look at the TCG property, the way the > > > write interface does. > > > > How useful is it HMP? > > Well, as usual, we have no idea if anybody really uses any feature. > I've never used it myself but I have a vague recollection of reading > list mail once from somebody who used it. You can construct theoretical > scenarios where it might be nice (eg "boot guest OS quickly and then > turn on the one-insn-per-tb mode once you get to the point of interest"), > I guess. These theoretical scenarios are equally valid (or esoteric) > whether you're trying to control QEMU via QMP or HMP. > > I think on balance I would go for: > * remove (ie deprecate-and-drop) 'singlestep' from the QMP struct, >rather than merely renaming it > * if anybody comes along and says they want to do this via QMP, >implement Paolo's idea of putting the accelerator object >somewhere they can get at it and use qom-get/qom-set on it >[My guess is this is very unlikely: nobody's complained so >far that QMP doesn't permit setting 'singlestep'; and >wanting read without write seems even more marginal.] > * keep the HMP commands, but have both read and write directly >talk to the accel object. I favour splitting the 'read' >part out into its own 'info one-insn-per-tb', for consistency >(then 'info status' matches the QMP query-status) If it's pretty obscure, then the qom-set/get is fine; as long as there is a way to do it, then just make sure in the commit message you say what the replacement command is. Dave > In particular, the fact that messing with this obscure debug > functionality requires updating the reference-output for a > bunch of io tests that have no interest at all in it rather > suggests that even if we did want to expose this to QMP that > the query-status command is the wrong place to do it. > > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH 13/13] aio: remove aio_disable_external() API
* Juan Quintela (quint...@redhat.com) wrote:
> Stefan Hajnoczi wrote:
> > All callers now pass is_external=false to aio_set_fd_handler() and
> > aio_set_event_notifier(). The aio_disable_external() API that
> > temporarily disables fd handlers that were registered is_external=true
> > is therefore dead code.
> >
> > Remove aio_disable_external(), aio_enable_external(), and the
> > is_external arguments to aio_set_fd_handler() and
> > aio_set_event_notifier().
> >
> > The entire test-fdmon-epoll test is removed because its sole purpose was
> > testing aio_disable_external().
> >
> > Parts of this patch were generated using the following coccinelle
> > (https://coccinelle.lip6.fr/) semantic patch:
> >
> > @@
> > expression ctx, fd, is_external, io_read, io_write, io_poll,
> > io_poll_ready, opaque;
> > @@
> > - aio_set_fd_handler(ctx, fd, is_external, io_read, io_write, io_poll,
> > io_poll_ready, opaque)
> > + aio_set_fd_handler(ctx, fd, io_read, io_write, io_poll, io_poll_ready,
> > opaque)
> >
> > @@
> > expression ctx, notifier, is_external, io_read, io_poll, io_poll_ready;
> > @@
> > - aio_set_event_notifier(ctx, notifier, is_external, io_read, io_poll,
> > io_poll_ready)
> > + aio_set_event_notifier(ctx, notifier, io_read, io_poll, io_poll_ready)
> >
> > Signed-off-by: Stefan Hajnoczi
>
> []
>
> > diff --git a/migration/rdma.c b/migration/rdma.c
> > index df646be35e..aee41ca43e 100644
> > --- a/migration/rdma.c
> > +++ b/migration/rdma.c
> > @@ -3104,15 +3104,15 @@ static void
> > qio_channel_rdma_set_aio_fd_handler(QIOChannel *ioc,
> > {
> > QIOChannelRDMA *rioc = QIO_CHANNEL_RDMA(ioc);
> > if (io_read) {
> > -aio_set_fd_handler(ctx, rioc->rdmain->recv_comp_channel->fd,
> > - false, io_read, io_write, NULL, NULL, opaque);
> > -aio_set_fd_handler(ctx, rioc->rdmain->send_comp_channel->fd,
> > - false, io_read, io_write, NULL, NULL, opaque);
> > +aio_set_fd_handler(ctx, rioc->rdmain->recv_comp_channel->fd,
> > io_read,
> > + io_write, NULL, NULL, opaque);
> > +aio_set_fd_handler(ctx, rioc->rdmain->send_comp_channel->fd,
> > io_read,
> > + io_write, NULL, NULL, opaque);
> > } else {
> > -aio_set_fd_handler(ctx, rioc->rdmaout->recv_comp_channel->fd,
> > - false, io_read, io_write, NULL, NULL, opaque);
> > -aio_set_fd_handler(ctx, rioc->rdmaout->send_comp_channel->fd,
> > - false, io_read, io_write, NULL, NULL, opaque);
> > +aio_set_fd_handler(ctx, rioc->rdmaout->recv_comp_channel->fd,
> > io_read,
> > + io_write, NULL, NULL, opaque);
> > +aio_set_fd_handler(ctx, rioc->rdmaout->send_comp_channel->fd,
> > io_read,
> > + io_write, NULL, NULL, opaque);
> > }
> > }
>
> Reviewed-by: Juan Quintela
>
> For the migration bits.
> I don't even want to know why the RDMA code uses a low level block layer API.
I don't think it's block specific.
It looks like it's because qio_channel uses aio in the case where
something QIO_CHANNEL_ERR_BLOCK and then waits for the recovery; see
4d9f675 that added it.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2 07/10] hmp: Add 'one-insn-per-tb' command equivalent to 'singlestep'
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> The 'singlestep' HMP command is confusing, because it doesn't
> actually have anything to do with single-stepping the CPU. What it
> does do is force TCG emulation to put one guest instruction in each
> TB, which can be useful in some situations.
>
> Create a new HMP command 'one-insn-per-tb', so we can document that
> 'singlestep' is just a deprecated synonym for it, and eventually
> perhaps drop it.
>
> We aren't obliged to do deprecate-and-drop for HMP commands,
> but it's easy enough to do so, so we do.
>
> Signed-off-by: Peter Maydell
> ---
> docs/about/deprecated.rst | 9 +
> include/monitor/hmp.h | 2 +-
> softmmu/runstate-hmp-cmds.c | 2 +-
> tests/qtest/test-hmp.c | 1 +
> hmp-commands.hx | 25 +
> 5 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 3c62671dac1..6f5e689aa45 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -199,6 +199,15 @@ accepted incorrect commands will return an error. Users
> should make sure that
> all arguments passed to ``device_add`` are consistent with the documented
> property types.
>
> +Human Monitor Protocol (HMP) commands
> +-
> +
> +``singlestep`` (since 8.1)
> +''
> +
> +The ``singlestep`` command has been replaced by the ``one-insn-per-tb``
> +command, which has the same behaviour but a less misleading name.
> +
> Host Architectures
> --
>
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index fdb69b7f9ca..13f9a2dedb8 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -158,7 +158,7 @@ void hmp_info_vcpu_dirty_limit(Monitor *mon, const QDict
> *qdict);
> void hmp_human_readable_text_helper(Monitor *mon,
> HumanReadableText *(*qmp_handler)(Error
> **));
> void hmp_info_stats(Monitor *mon, const QDict *qdict);
> -void hmp_singlestep(Monitor *mon, const QDict *qdict);
> +void hmp_one_insn_per_tb(Monitor *mon, const QDict *qdict);
> void hmp_watchdog_action(Monitor *mon, const QDict *qdict);
> void hmp_pcie_aer_inject_error(Monitor *mon, const QDict *qdict);
> void hmp_info_capture(Monitor *mon, const QDict *qdict);
> diff --git a/softmmu/runstate-hmp-cmds.c b/softmmu/runstate-hmp-cmds.c
> index 127521a483a..76d1399ed85 100644
> --- a/softmmu/runstate-hmp-cmds.c
> +++ b/softmmu/runstate-hmp-cmds.c
> @@ -41,7 +41,7 @@ void hmp_info_status(Monitor *mon, const QDict *qdict)
> qapi_free_StatusInfo(info);
> }
>
> -void hmp_singlestep(Monitor *mon, const QDict *qdict)
> +void hmp_one_insn_per_tb(Monitor *mon, const QDict *qdict)
> {
> const char *option = qdict_get_try_str(qdict, "option");
> AccelState *accel = current_accel();
> diff --git a/tests/qtest/test-hmp.c b/tests/qtest/test-hmp.c
> index b4a920df898..cb3530df722 100644
> --- a/tests/qtest/test-hmp.c
> +++ b/tests/qtest/test-hmp.c
> @@ -64,6 +64,7 @@ static const char *hmp_cmds[] = {
> "screendump /dev/null",
> "sendkey x",
> "singlestep on",
> +"one-insn-per-tb on",
OK, it wouldn't be bad if this list got a bit back into near alphabetic
order.
Reviewed-by: Dr. David Alan Gilbert
> "wavcapture /dev/null",
> "stopcapture 0",
> "sum 0 512",
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index bb85ee1d267..9afbb54a515 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -378,18 +378,35 @@ SRST
>only *tag* as parameter.
> ERST
>
> +{
> +.name = "one-insn-per-tb",
> +.args_type = "option:s?",
> +.params = "[on|off]",
> +.help = "run emulation with one guest instruction per
> translation block",
> +.cmd= hmp_one_insn_per_tb,
> +},
> +
> +SRST
> +``one-insn-per-tb [off]``
> + Run the emulation with one guest instruction per translation block.
> + This slows down emulation a lot, but can be useful in some situations,
> + such as when trying to analyse the logs produced by the ``-d`` option.
> + This only has an effect when using TCG, not with KVM or other accelerators.
> +
> + If called with option off, the emulation returns to normal mode.
> +ERST
> +
> {
> .name = "singlestep",
> .args_type = "option:s?",
> .params = "[on|off]",
> -.help
Re: [RFC PATCH v1 1/1] migration: Disable postcopy + multifd migration
ifd in both precopy and postcopy phase (currently > > definitely not supported) > > > > So that mgmt app will be aware whether multifd will be enabled in postcopy > > or not. Currently we can't identify it. > > > > I assume we can say by default "mutlifd+postcopy" means a) above, but we > > need to document it, and when b) is wanted and implemented someday, we'll > > need some other flag/cap for it. > > As I've mentioned a few times, I think we need to throw away the idea > of exposing capabilities that mgmt apps need to learn about, and make > the migration protocol fully bi-directional so src + dst QEMU can > directly negotiate features. Apps shouldn't have to care about the > day-to-day improvements in the migration impl to the extent that they > are today. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] MAINTAINERS: Remove and change David Gilbert maintainer entries
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote: > From: "Dr. David Alan Gilbert" > > I'm leaving Red Hat next week, so clean up the maintainer entries. > > 'virtiofs' is just the device code now, so is pretty small, and > Stefan is still a maintainer there. > > 'migration' still has Juan. > > For 'HMP' I'll swing that over to my personal email. > > Signed-off-by: Dr. David Alan Gilbert Acked-by: Dr. David Alan Gilbert > --- > MAINTAINERS | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ef45b5e71e..f0f7fb3746 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2119,7 +2119,6 @@ T: git https://github.com/borntraeger/qemu.git s390-next > L: qemu-s3...@nongnu.org > > virtiofs > -M: Dr. David Alan Gilbert > M: Stefan Hajnoczi > S: Supported > F: hw/virtio/vhost-user-fs* > @@ -2863,7 +2862,7 @@ F: tests/unit/test-rcu-*.c > F: util/rcu.c > > Human Monitor (HMP) > -M: Dr. David Alan Gilbert > +M: Dr. David Alan Gilbert > S: Maintained > F: monitor/monitor-internal.h > F: monitor/misc.c > @@ -3136,7 +3135,6 @@ F: scripts/checkpatch.pl > > Migration > M: Juan Quintela > -M: Dr. David Alan Gilbert > S: Maintained > F: hw/core/vmstate-if.c > F: include/hw/vmstate-if.h > -- > 2.39.2 > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
[PATCH] MAINTAINERS: Remove and change David Gilbert maintainer entries
From: "Dr. David Alan Gilbert" I'm leaving Red Hat next week, so clean up the maintainer entries. 'virtiofs' is just the device code now, so is pretty small, and Stefan is still a maintainer there. 'migration' still has Juan. For 'HMP' I'll swing that over to my personal email. Signed-off-by: Dr. David Alan Gilbert --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ef45b5e71e..f0f7fb3746 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2119,7 +2119,6 @@ T: git https://github.com/borntraeger/qemu.git s390-next L: qemu-s3...@nongnu.org virtiofs -M: Dr. David Alan Gilbert M: Stefan Hajnoczi S: Supported F: hw/virtio/vhost-user-fs* @@ -2863,7 +2862,7 @@ F: tests/unit/test-rcu-*.c F: util/rcu.c Human Monitor (HMP) -M: Dr. David Alan Gilbert +M: Dr. David Alan Gilbert S: Maintained F: monitor/monitor-internal.h F: monitor/misc.c @@ -3136,7 +3135,6 @@ F: scripts/checkpatch.pl Migration M: Juan Quintela -M: Dr. David Alan Gilbert S: Maintained F: hw/core/vmstate-if.c F: include/hw/vmstate-if.h -- 2.39.2
Re: [RFC PATCH v1 1/1] migration: Disable postcopy + multifd migration
* Leonardo Bras (leob...@redhat.com) wrote:
> Since the introduction of multifd, it's possible to perform a multifd
> migration and finish it using postcopy.
>
> A bug introduced by yank (fixed on cfc3bcf373) was previously preventing
> a successful use of this migration scenario, and now it should be
> working on most cases.
>
> But since there is not enough testing/support nor any reported users for
> this scenario, we should disable this combination before it may cause any
> problems for users.
>
> Suggested-by: Dr. David Alan Gilbert
> Signed-off-by: Leonardo Bras
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/migration.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index ae2025d9d8..c601964b0e 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1356,6 +1356,11 @@ static bool migrate_caps_check(bool *cap_list,
> error_setg(errp, "Postcopy is not compatible with
> ignore-shared");
> return false;
> }
> +
> +if (cap_list[MIGRATION_CAPABILITY_MULTIFD]) {
> +error_setg(errp, "Postcopy is not yet compatible with multifd");
> +return false;
> + }
> }
>
> if (cap_list[MIGRATION_CAPABILITY_BACKGROUND_SNAPSHOT]) {
> --
> 2.40.0
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: s390 migration crash
* Peter Xu (pet...@redhat.com) wrote:
> On Wed, Mar 22, 2023 at 02:05:06PM +0000, Dr. David Alan Gilbert wrote:
> > * Peter Xu (pet...@redhat.com) wrote:
> > > On Tue, Mar 21, 2023 at 08:24:37PM +0000, Dr. David Alan Gilbert wrote:
> > > > Hi Peter's,
> > > > Peter M pointed me to a seg in a migration test in CI; I can reproduce
> > > > it:
> > > > * On an s390 host
> > >
> > > How easy to reproduce?
> >
> > Pretty much every time when run as:
> > make check -j 4
> >
> > > > * only as part of a make check - running migration-test by itself
> > > > doesn't trigger for me.
> > > > * It looks like it's postcopy preempt
> > > >
> > > > (gdb) bt full
> > > > #0 iov_size (iov=iov@entry=0x2aa00e60670, iov_cnt=) at
> > > > ../util/iov.c:88
> > > > len = 13517923312037845750
> > > > i = 17305
> > > > #1 0x02aa004d068c in qemu_fflush (f=0x2aa00e58630) at
> > > > ../migration/qemu-file.c:307
> > > > local_error = 0x0
> > > > #2 0x02aa004d0e04 in qemu_fflush (f=) at
> > > > ../migration/qemu-file.c:297
> > > > #3 0x02aa00613962 in postcopy_preempt_shutdown_file
> > > > (s=s@entry=0x2aa00d1b4e0) at ../migration/ram.c:4657
> > > > #4 0x02aa004e12b4 in migration_completion (s=0x2aa00d1b4e0) at
> > > > ../migration/migration.c:3469
> > > > ret =
> > > > current_active_state = 5
> > > > must_precopy = 0
> > > > can_postcopy = 0
> > > > in_postcopy = true
> > > > pending_size = 0
> > > > __func__ = "migration_iteration_run"
> > > > iter_state =
> > > > s = 0x2aa00d1b4e0
> > > > thread =
> > > > setup_start =
> > > > thr_error =
> > > > urgent =
> > > > #5 migration_iteration_run (s=0x2aa00d1b4e0) at
> > > > ../migration/migration.c:3882
> > > > must_precopy = 0
> > > > can_postcopy = 0
> > > > in_postcopy = true
> > > > pending_size = 0
> > > > __func__ = "migration_iteration_run"
> > > > iter_state =
> > > > s = 0x2aa00d1b4e0
> > > > thread =
> > > > setup_start =
> > > > thr_error =
> > > > urgent =
> > > > #6 migration_thread (opaque=opaque@entry=0x2aa00d1b4e0) at
> > > > ../migration/migration.c:4124
> > > > iter_state =
> > > > s = 0x2aa00d1b4e0
> > > > --Type for more, q to quit, c to continue without paging--
> > > > thread =
> > > > setup_start =
> > > > thr_error =
> > > > urgent =
> > > > #7 0x02aa00819b8c in qemu_thread_start (args=) at
> > > > ../util/qemu-thread-posix.c:541
> > > > __cancel_buf =
> > > > {__cancel_jmp_buf = {{__cancel_jmp_buf = {{__gregs =
> > > > {4396782422080, 4393751543808, 4397299389454, 4396844235904,
> > > > 2929182727824, 2929182933488, 4396843986792, 4397299389455,
> > > > 33679382915066768, 33678512846981306}, __fpregs = {4396774031360,
> > > > 8392704, 2929182933488, 0, 4396782422272, 2929172491858, 4396774031360,
> > > > 1}}}, __mask_was_saved = 0}}, __pad = {0x3ffb4a77a60, 0x0, 0x0, 0x0}}
> > > > __cancel_routine = 0x2aa00819bf0
> > > > __not_first_call =
> > > > start_routine = 0x2aa004e08f0
> > > > arg = 0x2aa00d1b4e0
> > > > r =
> > > > #8 0x03ffb7b1e2e6 in start_thread () at /lib64/libc.so.6
> > > > #9 0x03ffb7aafdbe in thread_start () at /lib64/libc.so.6
> > > >
> > > > It looks like it's in the preempt test:
> > > >
> > > > (gdb) where
> > > > #0 0x03ffb17a0126 in __pthread_kill_implementation () from
> > > > /lib64/libc.so.6
> > > > #1 0x03ffb1750890 in raise () from /lib64/libc.so.6
> > > > #2 0x03ffb172a340 in abort () from /lib64/libc.so.6
> > > > #3 0x02aa0041c130 in qtest_check_status (s=) at
> > > > ../tests/qtest/libqtest.c:194
> > > > #4 0x03ffb1a3b5de in g_hook_lis
Re: s390 migration crash
* Peter Xu (pet...@redhat.com) wrote:
> On Tue, Mar 21, 2023 at 08:24:37PM +0000, Dr. David Alan Gilbert wrote:
> > Hi Peter's,
> > Peter M pointed me to a seg in a migration test in CI; I can reproduce
> > it:
> > * On an s390 host
>
> How easy to reproduce?
Pretty much every time when run as:
make check -j 4
> > * only as part of a make check - running migration-test by itself
> > doesn't trigger for me.
> > * It looks like it's postcopy preempt
> >
> > (gdb) bt full
> > #0 iov_size (iov=iov@entry=0x2aa00e60670, iov_cnt=) at
> > ../util/iov.c:88
> > len = 13517923312037845750
> > i = 17305
> > #1 0x02aa004d068c in qemu_fflush (f=0x2aa00e58630) at
> > ../migration/qemu-file.c:307
> > local_error = 0x0
> > #2 0x02aa004d0e04 in qemu_fflush (f=) at
> > ../migration/qemu-file.c:297
> > #3 0x02aa00613962 in postcopy_preempt_shutdown_file
> > (s=s@entry=0x2aa00d1b4e0) at ../migration/ram.c:4657
> > #4 0x02aa004e12b4 in migration_completion (s=0x2aa00d1b4e0) at
> > ../migration/migration.c:3469
> > ret =
> > current_active_state = 5
> > must_precopy = 0
> > can_postcopy = 0
> > in_postcopy = true
> > pending_size = 0
> > __func__ = "migration_iteration_run"
> > iter_state =
> > s = 0x2aa00d1b4e0
> > thread =
> > setup_start =
> > thr_error =
> > urgent =
> > #5 migration_iteration_run (s=0x2aa00d1b4e0) at
> > ../migration/migration.c:3882
> > must_precopy = 0
> > can_postcopy = 0
> > in_postcopy = true
> > pending_size = 0
> > __func__ = "migration_iteration_run"
> > iter_state =
> > s = 0x2aa00d1b4e0
> > thread =
> > setup_start =
> > thr_error =
> > urgent =
> > #6 migration_thread (opaque=opaque@entry=0x2aa00d1b4e0) at
> > ../migration/migration.c:4124
> > iter_state =
> > s = 0x2aa00d1b4e0
> > --Type for more, q to quit, c to continue without paging--
> > thread =
> > setup_start =
> > thr_error =
> > urgent =
> > #7 0x02aa00819b8c in qemu_thread_start (args=) at
> > ../util/qemu-thread-posix.c:541
> > __cancel_buf =
> > {__cancel_jmp_buf = {{__cancel_jmp_buf = {{__gregs =
> > {4396782422080, 4393751543808, 4397299389454, 4396844235904, 2929182727824,
> > 2929182933488, 4396843986792, 4397299389455, 33679382915066768,
> > 33678512846981306}, __fpregs = {4396774031360, 8392704, 2929182933488, 0,
> > 4396782422272, 2929172491858, 4396774031360, 1}}}, __mask_was_saved = 0}},
> > __pad = {0x3ffb4a77a60, 0x0, 0x0, 0x0}}
> > __cancel_routine = 0x2aa00819bf0
> > __not_first_call =
> > start_routine = 0x2aa004e08f0
> > arg = 0x2aa00d1b4e0
> > r =
> > #8 0x03ffb7b1e2e6 in start_thread () at /lib64/libc.so.6
> > #9 0x03ffb7aafdbe in thread_start () at /lib64/libc.so.6
> >
> > It looks like it's in the preempt test:
> >
> > (gdb) where
> > #0 0x03ffb17a0126 in __pthread_kill_implementation () from
> > /lib64/libc.so.6
> > #1 0x03ffb1750890 in raise () from /lib64/libc.so.6
> > #2 0x03ffb172a340 in abort () from /lib64/libc.so.6
> > #3 0x02aa0041c130 in qtest_check_status (s=) at
> > ../tests/qtest/libqtest.c:194
> > #4 0x03ffb1a3b5de in g_hook_list_invoke () from /lib64/libglib-2.0.so.0
> > #5
> > #6 0x03ffb17a0126 in __pthread_kill_implementation () from
> > /lib64/libc.so.6
> > #7 0x03ffb1750890 in raise () from /lib64/libc.so.6
> > #8 0x03ffb172a340 in abort () from /lib64/libc.so.6
> > #9 0x02aa00420318 in qmp_fd_receive (fd=) at
> > ../tests/qtest/libqmp.c:80
> > #10 0x02aa0041d5ee in qtest_qmp_receive_dict (s=0x2aa01eb2700) at
> > ../tests/qtest/libqtest.c:713
> > #11 qtest_qmp_receive (s=0x2aa01eb2700) at ../tests/qtest/libqtest.c:701
> > #12 qtest_vqmp (s=s@entry=0x2aa01eb2700, fmt=fmt@entry=0x2aa00487100 "{
> > 'execute': 'query-migrate' }", ap=ap@entry=0x3ffc247cc68)
> > at ../tests/qtest/libqtest.c:765
> > #13 0x02aa00413f1e in wait_command (who=who@entry=0x2aa01eb2700,
> > command=command@entry=0x2aa00487100 "{ 'execute': 'query-migrate' }")
> > at ../tests/qtest/migration-helpers.c:73
> >
s390 migration crash
Hi Peter's,
Peter M pointed me to a seg in a migration test in CI; I can reproduce
it:
* On an s390 host
* only as part of a make check - running migration-test by itself
doesn't trigger for me.
* It looks like it's postcopy preempt
(gdb) bt full
#0 iov_size (iov=iov@entry=0x2aa00e60670, iov_cnt=) at
../util/iov.c:88
len = 13517923312037845750
i = 17305
#1 0x02aa004d068c in qemu_fflush (f=0x2aa00e58630) at
../migration/qemu-file.c:307
local_error = 0x0
#2 0x02aa004d0e04 in qemu_fflush (f=) at
../migration/qemu-file.c:297
#3 0x02aa00613962 in postcopy_preempt_shutdown_file
(s=s@entry=0x2aa00d1b4e0) at ../migration/ram.c:4657
#4 0x02aa004e12b4 in migration_completion (s=0x2aa00d1b4e0) at
../migration/migration.c:3469
ret =
current_active_state = 5
must_precopy = 0
can_postcopy = 0
in_postcopy = true
pending_size = 0
__func__ = "migration_iteration_run"
iter_state =
s = 0x2aa00d1b4e0
thread =
setup_start =
thr_error =
urgent =
#5 migration_iteration_run (s=0x2aa00d1b4e0) at ../migration/migration.c:3882
must_precopy = 0
can_postcopy = 0
in_postcopy = true
pending_size = 0
__func__ = "migration_iteration_run"
iter_state =
s = 0x2aa00d1b4e0
thread =
setup_start =
thr_error =
urgent =
#6 migration_thread (opaque=opaque@entry=0x2aa00d1b4e0) at
../migration/migration.c:4124
iter_state =
s = 0x2aa00d1b4e0
--Type for more, q to quit, c to continue without paging--
thread =
setup_start =
thr_error =
urgent =
#7 0x02aa00819b8c in qemu_thread_start (args=) at
../util/qemu-thread-posix.c:541
__cancel_buf =
{__cancel_jmp_buf = {{__cancel_jmp_buf = {{__gregs =
{4396782422080, 4393751543808, 4397299389454, 4396844235904, 2929182727824,
2929182933488, 4396843986792, 4397299389455, 33679382915066768,
33678512846981306}, __fpregs = {4396774031360, 8392704, 2929182933488, 0,
4396782422272, 2929172491858, 4396774031360, 1}}}, __mask_was_saved = 0}},
__pad = {0x3ffb4a77a60, 0x0, 0x0, 0x0}}
__cancel_routine = 0x2aa00819bf0
__not_first_call =
start_routine = 0x2aa004e08f0
arg = 0x2aa00d1b4e0
r =
#8 0x03ffb7b1e2e6 in start_thread () at /lib64/libc.so.6
#9 0x03ffb7aafdbe in thread_start () at /lib64/libc.so.6
It looks like it's in the preempt test:
(gdb) where
#0 0x03ffb17a0126 in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x03ffb1750890 in raise () from /lib64/libc.so.6
#2 0x03ffb172a340 in abort () from /lib64/libc.so.6
#3 0x02aa0041c130 in qtest_check_status (s=) at
../tests/qtest/libqtest.c:194
#4 0x03ffb1a3b5de in g_hook_list_invoke () from /lib64/libglib-2.0.so.0
#5
#6 0x03ffb17a0126 in __pthread_kill_implementation () from /lib64/libc.so.6
#7 0x03ffb1750890 in raise () from /lib64/libc.so.6
#8 0x03ffb172a340 in abort () from /lib64/libc.so.6
#9 0x02aa00420318 in qmp_fd_receive (fd=) at
../tests/qtest/libqmp.c:80
#10 0x02aa0041d5ee in qtest_qmp_receive_dict (s=0x2aa01eb2700) at
../tests/qtest/libqtest.c:713
#11 qtest_qmp_receive (s=0x2aa01eb2700) at ../tests/qtest/libqtest.c:701
#12 qtest_vqmp (s=s@entry=0x2aa01eb2700, fmt=fmt@entry=0x2aa00487100 "{
'execute': 'query-migrate' }", ap=ap@entry=0x3ffc247cc68)
at ../tests/qtest/libqtest.c:765
#13 0x02aa00413f1e in wait_command (who=who@entry=0x2aa01eb2700,
command=command@entry=0x2aa00487100 "{ 'execute': 'query-migrate' }")
at ../tests/qtest/migration-helpers.c:73
#14 0x02aa00414078 in migrate_query (who=who@entry=0x2aa01eb2700) at
../tests/qtest/migration-helpers.c:139
#15 migrate_query_status (who=who@entry=0x2aa01eb2700) at
../tests/qtest/migration-helpers.c:161
#16 0x02aa00414480 in check_migration_status (ungoals=0x0,
goal=0x2aa00495c7e "completed", who=0x2aa01eb2700) at
../tests/qtest/migration-helpers.c:177
#17 wait_for_migration_status (who=0x2aa01eb2700, goal=,
ungoals=0x0) at ../tests/qtest/migration-helpers.c:202
#18 0x02aa0041300e in migrate_postcopy_complete
(from=from@entry=0x2aa01eb2700, to=to@entry=0x2aa01eb3000,
args=args@entry=0x3ffc247cf48)
at ../tests/qtest/migration-test.c:1137
#19 0x02aa004131a4 in test_postcopy_common (args=0x3ffc247cf48) at
../tests/qtest/migration-test.c:1162
#20 test_postcopy_preempt () at ../tests/qtest/migration-test.c:1178
Looking at the iov and file it's garbage; so it makes me think this is
something like a flush on a closed file.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v3 3/3] qapi: Generate enum count as definition
udio/audio_template.h > @@ -376,9 +376,6 @@ AudiodevPerDirectionOptions *glue(audio_get_pdo_, > TYPE)(Audiodev *dev) > #endif > case AUDIODEV_DRIVER_WAV: > return dev->u.wav.TYPE; > - > -case AUDIODEV_DRIVER__MAX: > -break; > } > abort(); > } > diff --git a/audio/audio.c b/audio/audio.c > index 70b096713c..ea372288eb 100644 > --- a/audio/audio.c > +++ b/audio/audio.c > @@ -2071,9 +2071,6 @@ void audio_create_pdos(Audiodev *dev) > CASE(SPICE, spice, ); > #endif > CASE(WAV, wav, ); > - > -case AUDIODEV_DRIVER__MAX: > -abort(); > }; > } > > @@ -2219,9 +2216,6 @@ int audioformat_bytes_per_sample(AudioFormat fmt) > case AUDIO_FORMAT_S32: > case AUDIO_FORMAT_F32: > return 4; > - > -case AUDIO_FORMAT__MAX: > -; > } > abort(); > } > diff --git a/migration/migration.c b/migration/migration.c > index ae2025d9d8..bdadab3b5e 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -2220,8 +2220,6 @@ bool migration_is_idle(void) > case MIGRATION_STATUS_DEVICE: > case MIGRATION_STATUS_WAIT_UNPLUG: > return false; > -case MIGRATION_STATUS__MAX: > -g_assert_not_reached(); Acked-by: Dr. David Alan Gilbert > } > > return false; > diff --git a/replay/replay-input.c b/replay/replay-input.c > index 1147e3d34e..c6de8e33ac 100644 > --- a/replay/replay-input.c > +++ b/replay/replay-input.c > @@ -38,9 +38,6 @@ void replay_save_input_event(InputEvent *evt) > replay_put_dword(key->key->u.qcode.data); > replay_put_byte(key->down); > break; > -case KEY_VALUE_KIND__MAX: > -/* keep gcc happy */ > -break; > } > break; > case INPUT_EVENT_KIND_BTN: > @@ -58,9 +55,6 @@ void replay_save_input_event(InputEvent *evt) > replay_put_dword(move->axis); > replay_put_qword(move->value); > break; > -case INPUT_EVENT_KIND__MAX: > -/* keep gcc happy */ > -break; > } > } > > @@ -89,9 +83,6 @@ InputEvent *replay_read_input_event(void) > evt.u.key.data->key->u.qcode.data = (QKeyCode)replay_get_dword(); > evt.u.key.data->down = replay_get_byte(); > break; > -case KEY_VALUE_KIND__MAX: > -/* keep gcc happy */ > -break; > } > break; > case INPUT_EVENT_KIND_BTN: > @@ -109,9 +100,6 @@ InputEvent *replay_read_input_event(void) > evt.u.abs.data->axis = (InputAxis)replay_get_dword(); > evt.u.abs.data->value = replay_get_qword(); > break; > -case INPUT_EVENT_KIND__MAX: > -/* keep gcc happy */ > -break; > } > > return QAPI_CLONE(InputEvent, ); > diff --git a/softmmu/tpm-hmp-cmds.c b/softmmu/tpm-hmp-cmds.c > index 9ed6ad6c4d..5a354cf6ac 100644 > --- a/softmmu/tpm-hmp-cmds.c > +++ b/softmmu/tpm-hmp-cmds.c > @@ -52,8 +52,6 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict) > teo = ti->options->u.emulator.data; > monitor_printf(mon, ",chardev=%s", teo->chardev); > break; > -case TPM_TYPE__MAX: > -break; > } > monitor_printf(mon, "\n"); > c++; > diff --git a/ui/input-linux.c b/ui/input-linux.c > index e572a2e905..a6e7574422 100644 > --- a/ui/input-linux.c > +++ b/ui/input-linux.c > @@ -120,10 +120,6 @@ static bool input_linux_check_toggle(InputLinux *il) > return (il->keydown[KEY_LEFTCTRL] || > il->keydown[KEY_RIGHTCTRL]) && > il->keydown[KEY_SCROLLLOCK]; > - > -case GRAB_TOGGLE_KEYS__MAX: > -/* avoid gcc error */ > -break; > } > return false; > } > diff --git a/ui/input.c b/ui/input.c > index f2d1e7a3a7..ca8f49a403 100644 > --- a/ui/input.c > +++ b/ui/input.c > @@ -230,9 +230,6 @@ static void qemu_input_event_trace(QemuConsole *src, > InputEvent *evt) > name = QKeyCode_str(key->key->u.qcode.data); > trace_input_event_key_qcode(idx, name, key->down); > break; > -case KEY_VALUE_KIND__MAX: > -/* keep gcc happy */ > -break; > } > break; > case INPUT_EVENT_KIND_BTN: > @@ -250,9 +247,6 @@ static void qemu_input_event_trace(QemuConsole *src, > InputEvent *evt) > name = InputAxis_str(move->axis); > trace_input_event_abs(idx, name, move->value); > break; > -case INPUT_EVENT_KIND__MAX: > -/* keep gcc happy */ > -break; > } > } > > -- > 2.38.1 > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RESEND v2 2/2] migration/xbzrle: fix out-of-bounds write with axv512
* Matheus Tavares Bernardino (quic_mathb...@quicinc.com) wrote:
> xbzrle_encode_buffer_avx512() checks for overflows too scarcely in its
> outer loop, causing out-of-bounds writes:
>
> $ ../configure --target-list=aarch64-softmmu --enable-sanitizers
> --enable-avx512bw
> $ make tests/unit/test-xbzrle && ./tests/unit/test-xbzrle
>
> ==5518==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6210b100 at pc 0x561109a7714d bp 0x7ffed712a440 sp 0x7ffed712a430
> WRITE of size 1 at 0x6210b100 thread T0
> #0 0x561109a7714c in uleb128_encode_small ../util/cutils.c:831
> #1 0x561109b67f6a in xbzrle_encode_buffer_avx512 ../migration/xbzrle.c:275
> #2 0x5611099a7428 in test_encode_decode_overflow
> ../tests/unit/test-xbzrle.c:153
> #3 0x7fb2fb65a58d (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7a58d)
> #4 0x7fb2fb65a333 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7a333)
> #5 0x7fb2fb65aa79 in g_test_run_suite
> (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7aa79)
> #6 0x7fb2fb65aa94 in g_test_run
> (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7aa94)
> #7 0x5611099a3a23 in main ../tests/unit/test-xbzrle.c:218
> #8 0x7fb2fa78c082 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
> #9 0x5611099a608d in _start (/qemu/build/tests/unit/test-xbzrle+0x28408d)
>
> 0x6210b100 is located 0 bytes to the right of 4096-byte region
> [0x6210a100,0x6210b100)
> allocated by thread T0 here:
> #0 0x7fb2fb823a06 in __interceptor_calloc
> ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
> #1 0x7fb2fb637ef0 in g_malloc0
> (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ef0)
>
> Fix that by performing the overflow check in the inner loop, instead.
>
> Signed-off-by: Matheus Tavares Bernardino
> ---
> migration/xbzrle.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/migration/xbzrle.c b/migration/xbzrle.c
> index 21b92d4eae..c6f8b20917 100644
> --- a/migration/xbzrle.c
> +++ b/migration/xbzrle.c
> @@ -197,10 +197,6 @@ int xbzrle_encode_buffer_avx512(uint8_t *old_buf,
> uint8_t *new_buf, int slen,
> __m512i r = _mm512_set1_epi32(0);
>
> while (count512s) {
> -if (d + 2 > dlen) {
> -return -1;
> -}
> -
> int bytes_to_check = 64;
> uint64_t mask = 0x;
> if (count512s == 1) {
> @@ -216,6 +212,9 @@ int xbzrle_encode_buffer_avx512(uint8_t *old_buf, uint8_t
> *new_buf, int slen,
>
> bool is_same = (comp & 0x1);
> while (bytes_to_check) {
> +if (d + 2 > dlen) {
> +return -1;
> +}
I agree that's better, so:
Reviewed-by: Dr. David Alan Gilbert
but is it sufficient?
In that bytes_to_check loop there are 4 calls to uleb128_encode_small
with another one just off the end of the loop.
I've not figured out all the legal combos, but I'm pretty sure at least
a few can trigger in one iteration - so don't we need those checks
before ecah call?
Dave
> if (is_same) {
> if (nzrun_len) {
> d += uleb128_encode_small(dst + d, nzrun_len);
> --
> 2.39.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RESEND v2 1/2] migration/xbzrle: use ctz64 to avoid undefined result
* Matheus Tavares Bernardino (quic_mathb...@quicinc.com) wrote: > __builtin_ctzll() produces undefined results when the argument is 0. > This can be seen through test-xbzrle, which produces the following > warning: > > ../migration/xbzrle.c:265: runtime error: passing zero to ctz(), which is not > a valid argument > > Replace __builtin_ctzll() with our ctz64() wrapper which properly > handles 0. > > Signed-off-by: Matheus Tavares Bernardino Reviewed-by: Dr. David Alan Gilbert > --- > migration/xbzrle.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/migration/xbzrle.c b/migration/xbzrle.c > index 05366e86c0..21b92d4eae 100644 > --- a/migration/xbzrle.c > +++ b/migration/xbzrle.c > @@ -12,6 +12,7 @@ > */ > #include "qemu/osdep.h" > #include "qemu/cutils.h" > +#include "qemu/host-utils.h" > #include "xbzrle.h" > > /* > @@ -233,7 +234,7 @@ int xbzrle_encode_buffer_avx512(uint8_t *old_buf, uint8_t > *new_buf, int slen, > break; > } > never_same = false; > -num = __builtin_ctzll(~comp); > +num = ctz64(~comp); > num = (num < bytes_to_check) ? num : bytes_to_check; > zrun_len += num; > bytes_to_check -= num; > @@ -262,7 +263,7 @@ int xbzrle_encode_buffer_avx512(uint8_t *old_buf, uint8_t > *new_buf, int slen, > nzrun_len += 64; > break; > } > -num = __builtin_ctzll(comp); > +num = ctz64(comp); > num = (num < bytes_to_check) ? num : bytes_to_check; > nzrun_len += num; > bytes_to_check -= num; > -- > 2.39.1 > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] migration/rdma: Fix return-path case
* Peter Xu (pet...@redhat.com) wrote:
> On Tue, Mar 14, 2023 at 05:15:58PM +0000, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > The RDMA code has return-path handling code, but it's only enabled
> > if postcopy is enabled; if the 'return-path' migration capability
> > is enabled, the return path is NOT setup but the core migration
> > code still tries to use it and breaks.
> >
> > Enable the RDMA return path if either postcopy or the return-path
> > capability is enabled.
> >
> > bz: https://bugzilla.redhat.com/show_bug.cgi?id=2063615
> >
> > Signed-off-by: Dr. David Alan Gilbert
>
> Acked-by: Peter Xu
>
> > @@ -3373,7 +3373,8 @@ static int qemu_rdma_accept(RDMAContext *rdma)
> > * initialize the RDMAContext for return path for postcopy after first
> > * connection request reached.
> > */
> > -if (migrate_postcopy() && !rdma->is_return_path) {
> > +if ((migrate_postcopy() || migrate_use_return_path())
> > +&& !rdma->is_return_path) {
> > rdma_return_path = qemu_rdma_data_init(rdma->host_port, NULL);
> > if (rdma_return_path == NULL) {
> > rdma_ack_cm_event(cm_event);
>
> It's not extremely clear to me yet on when we should use migrate_postcopy()
> and when to use migrate_postcopy_ram(). I think it's because I don't know
> enough on the dirty-bitmaps capability. Do we have some good documentation
> somewhere?
Hmm that's probably a good point.
> Not much I get from the qapi doc..
>
> # @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps.
> # (since 2.12)
I don't know of any good docs; I think this is a blocks mechanism; I'm
not even sure if it needs the return path.
Dave
> Thanks,
>
> --
> Peter Xu
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PATCH] migration/rdma: Fix return-path case
From: "Dr. David Alan Gilbert"
The RDMA code has return-path handling code, but it's only enabled
if postcopy is enabled; if the 'return-path' migration capability
is enabled, the return path is NOT setup but the core migration
code still tries to use it and breaks.
Enable the RDMA return path if either postcopy or the return-path
capability is enabled.
bz: https://bugzilla.redhat.com/show_bug.cgi?id=2063615
Signed-off-by: Dr. David Alan Gilbert
---
migration/rdma.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/migration/rdma.c b/migration/rdma.c
index 288eadc2d2..9d70e9885b 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -3373,7 +3373,8 @@ static int qemu_rdma_accept(RDMAContext *rdma)
* initialize the RDMAContext for return path for postcopy after first
* connection request reached.
*/
-if (migrate_postcopy() && !rdma->is_return_path) {
+if ((migrate_postcopy() || migrate_use_return_path())
+&& !rdma->is_return_path) {
rdma_return_path = qemu_rdma_data_init(rdma->host_port, NULL);
if (rdma_return_path == NULL) {
rdma_ack_cm_event(cm_event);
@@ -3455,7 +3456,8 @@ static int qemu_rdma_accept(RDMAContext *rdma)
}
/* Accept the second connection request for return path */
-if (migrate_postcopy() && !rdma->is_return_path) {
+if ((migrate_postcopy() || migrate_use_return_path())
+&& !rdma->is_return_path) {
qemu_set_fd_handler(rdma->channel->fd, rdma_accept_incoming_migration,
NULL,
(void *)(intptr_t)rdma->return_path);
@@ -4192,7 +4194,7 @@ void rdma_start_outgoing_migration(void *opaque,
}
/* RDMA postcopy need a separate queue pair for return path */
-if (migrate_postcopy()) {
+if (migrate_postcopy() || migrate_use_return_path()) {
rdma_return_path = qemu_rdma_data_init(host_port, errp);
if (rdma_return_path == NULL) {
--
2.39.2
Re: [PATCH] tests/qtest/migration-test: Disable postcopy/preempt tests
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> The postcopy/preempt tests seem to have a race which makes them hang
> on the s390x CI runner. Disable them for the moment, while we
> investigate. As with the other disabled subtest, you can opt back in
> by setting QEMU_TEST_FLAKY_TESTS=1 in your environment.
>
> Suggested-by: Dr. David Alan Gilbert
> Signed-off-by: Peter Maydell
Reviewed-by: Dr. David Alan Gilbert
> ---
> tests/qtest/migration-test.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
> index d4ab3934ed2..4643f7f49dc 100644
> --- a/tests/qtest/migration-test.c
> +++ b/tests/qtest/migration-test.c
> @@ -2464,6 +2464,11 @@ int main(int argc, char **argv)
> const char *arch = qtest_get_arch();
> g_autoptr(GError) err = NULL;
> int ret;
> +/*
> + * Race condition suspected in the postcopy/preempt tests: see
> + *
> https://lore.kernel.org/qemu-devel/CAFEAcA-q1UwPePdHTzXNSX4i6Urh3j6h51kymy6=7szdafu...@mail.gmail.com/
> + */
> +bool skip_postcopy_preempt = getenv("QEMU_TEST_FLAKY_TESTS");
>
> g_test_init(, , NULL);
>
> @@ -2500,9 +2505,11 @@ int main(int argc, char **argv)
> qtest_add_func("/migration/postcopy/plain", test_postcopy);
> qtest_add_func("/migration/postcopy/recovery/plain",
> test_postcopy_recovery);
> -qtest_add_func("/migration/postcopy/preempt/plain",
> test_postcopy_preempt);
> -qtest_add_func("/migration/postcopy/preempt/recovery/plain",
> - test_postcopy_preempt_recovery);
> +if (!skip_postcopy_preempt) {
> +qtest_add_func("/migration/postcopy/preempt/plain",
> test_postcopy_preempt);
> +qtest_add_func("/migration/postcopy/preempt/recovery/plain",
> + test_postcopy_preempt_recovery);
> +}
> }
>
> qtest_add_func("/migration/bad_dest", test_baddest);
> @@ -2521,10 +2528,12 @@ int main(int argc, char **argv)
> qtest_add_func("/migration/postcopy/tls/psk", test_postcopy_tls_psk);
> qtest_add_func("/migration/postcopy/recovery/tls/psk",
> test_postcopy_recovery_tls_psk);
> -qtest_add_func("/migration/postcopy/preempt/tls/psk",
> - test_postcopy_preempt_tls_psk);
> -qtest_add_func("/migration/postcopy/preempt/recovery/tls/psk",
> - test_postcopy_preempt_all);
> +if (!skip_postcopy_preempt) {
> +qtest_add_func("/migration/postcopy/preempt/tls/psk",
> + test_postcopy_preempt_tls_psk);
> +qtest_add_func("/migration/postcopy/preempt/recovery/tls/psk",
> + test_postcopy_preempt_all);
> +}
> }
> #ifdef CONFIG_TASN1
> qtest_add_func("/migration/precopy/unix/tls/x509/default-host",
> --
> 2.34.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 14 Mar 2023 at 10:12, Dr. David Alan Gilbert > wrote: > > > > Copying Peter Xu on this one since it's poscopy, especially the newer > > postcopy preempt. > > > > * Peter Maydell (peter.mayd...@linaro.org) wrote: > > > On Sun, 12 Mar 2023 at 14:06, Peter Maydell > > > wrote: > > > > Here's another one, on the s390x CI runner: > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3917587994 > > > > > > And here's a backtrace from a hung migration-test on the s390x > > > runner (looks like a deadlock, none of these processes were > > > using CPU): > > > > Ah a backtrace! > > I've attached another 2 -- migration-test seems to fairly > commonly hang on the s390 CI runner; there are several > stuck tests on it at the moment. These are the same as the last one I replied to; it's probably best if we disable /migration/postcopy/preempt/* until peterx has attacked it. Dave > -- PMM > Process tree: > migration-test(1841031)-+-qemu-system-x86(1841381) > `-qemu-system-x86(1841387) > === > PROCESS: 1841031 > gitlab-+ 1841031 1838397 0 Mar13 ?00:00:02 > /home/gitlab-runner/builds/FLaZkdt1/0/qemu-project/qemu/build/tests/qtest/migration-test > --tap -k > [New LWP 1841033] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". > __libc_recv (fd=fd@entry=5, buf=buf@entry=0x3ffdac792e7, len=len@entry=1, > flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/recv.c:30 > > Thread 2 (Thread 0x3ffb01ff900 (LWP 1841033)): > #0 syscall () at ../sysdeps/unix/sysv/linux/s390/s390-64/syscall.S:37 > #1 0x02aa133dae34 in qemu_futex_wait (val=, f= out>) at > /home/gitlab-runner/builds/FLaZkdt1/0/qemu-project/qemu/include/qemu/futex.h:29 > #2 qemu_event_wait (ev=ev@entry=0x2aa135596b8 ) at > ../util/qemu-thread-posix.c:464 > #3 0x02aa134079ea in call_rcu_thread (opaque=opaque@entry=0x0) at > ../util/rcu.c:261 > #4 0x02aa133d9e9a in qemu_thread_start (args=) at > ../util/qemu-thread-posix.c:541 > #5 0x03ffb0b87e66 in start_thread (arg=0x3ffb01ff900) at > pthread_create.c:477 > #6 0x03ffb0a7cbe6 in thread_start () at > ../sysdeps/unix/sysv/linux/s390/s390-64/clone.S:65 > > Thread 1 (Thread 0x3ffb126d990 (LWP 1841031)): > #0 __libc_recv (fd=fd@entry=5, buf=buf@entry=0x3ffdac792e7, len=len@entry=1, > flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/recv.c:30 > #1 0x02aa133aba22 in recv (__flags=0, __n=1, __buf=0x3ffdac792e7, > __fd=5) at /usr/include/s390x-linux-gnu/bits/socket2.h:44 > #2 qmp_fd_receive (fd=) at ../tests/qtest/libqmp.c:73 > #3 0x02aa133a9b8e in qtest_qmp_receive_dict (s=0x2aa135fb800) at > ../tests/qtest/libqtest.c:837 > #4 qtest_qmp_eventwait_ref (event=, s=) at > ../tests/qtest/libqtest.c:837 > #5 qtest_qmp_eventwait_ref (s=0x2aa135fb800, event=) at > ../tests/qtest/libqtest.c:828 > #6 0x02aa133a9c1a in qtest_qmp_eventwait (s=, > event=) at ../tests/qtest/libqtest.c:850 > #7 0x02aa1339ec56 in test_postcopy_common (args=0x3ffdac795e8) at > ../tests/qtest/migration-test.c:1161 > #8 0x02aa1339edb4 in test_postcopy_preempt () at > ../tests/qtest/migration-test.c:1178 > #9 0x03ffb0d7e608 in ?? () from /lib/s390x-linux-gnu/libglib-2.0.so.0 > #10 0x03ffb0d7e392 in ?? () from /lib/s390x-linux-gnu/libglib-2.0.so.0 > #11 0x03ffb0d7e392 in ?? () from /lib/s390x-linux-gnu/libglib-2.0.so.0 > #12 0x03ffb0d7e392 in ?? () from /lib/s390x-linux-gnu/libglib-2.0.so.0 > #13 0x03ffb0d7e392 in ?? () from /lib/s390x-linux-gnu/libglib-2.0.so.0 > #14 0x03ffb0d7eada in g_test_run_suite () from > /lib/s390x-linux-gnu/libglib-2.0.so.0 > #15 0x03ffb0d7eb10 in g_test_run () from > /lib/s390x-linux-gnu/libglib-2.0.so.0 > #16 0x02aa1339ab14 in main (argc=, argv=) > at ../tests/qtest/migration-test.c:2615 > [Inferior 1 (process 1841031) detached] > > === > PROCESS: 1841381 > gitlab-+ 1841381 1841031 0 Mar13 ?00:00:06 ./qemu-system-x86_64 > -qtest unix:/tmp/qtest-1841031.sock -qtest-log /dev/null -chardev > socket,path=/tmp/qtest-1841031.qmp,id=char0 -mon chardev=char0,mode=control > -display none -accel kvm -accel tcg -name source,debug-threads=on -m 150M > -serial file:/tmp/migration-test-RM5901/src_serial -drive > file=/tmp/migration-test-RM5901/bootsect,format=raw -accel qtest > [New LWP 1841383] > [New LWP 1841384] > [New LWP 1841385] > [New LWP 1841394] > [New LWP 1841395] > [Thread
Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
> pthread_create.c:477 > #6 0x03ff858fcbe6 in thread_start () at > ../sysdeps/unix/sysv/linux/s390/s390-64/clone.S:65 > > Thread 1 (Thread 0x3ff8927e4a0 (LWP 1465125)): > #0 futex_wait_cancelable (private=0, expected=0, > futex_word=0x2aa2b37b560) at ../sysdeps/nptl/futex-internal.h:183 > #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, > mutex=0x2aa2b37b508, cond=0x2aa2b37b538) at pthread_cond_wait.c:508 > #2 __pthread_cond_wait (cond=cond@entry=0x2aa2b37b538, > mutex=mutex@entry=0x2aa2b37b508) at pthread_cond_wait.c:647 > #3 0x02aa28ac500e in qemu_cond_wait_impl (cond=0x2aa2b37b538, > mutex=0x2aa2b37b508, file=0x2aa28d70dee "../util/qemu-thread-posix.c", > line=) at ../util/qemu-thread-posix.c:225 > #4 0x02aa28ac542e in qemu_sem_wait (sem=0x2aa2b37b508) at > ../util/qemu-thread-posix.c:314 > #5 0x02aa284f485a in postcopy_ram_incoming_setup > (mis=0x2aa2b37b3a0, mis@entry=postcopy_qemufile_dst_done); > optimized out>) at ../migration/postcopy-ram.c:1204 > #6 0x02aa284fbf70 in loadvm_postcopy_handle_listen > (mis=) at ../migration/savevm.c:2016 > #7 loadvm_process_command (f=0x2aa2b85b7a0) at ../migration/savevm.c:2379 > #8 qemu_loadvm_state_main (f=f@entry=0x2aa2b85b7a0, > mis=0x2aa2b37b3a0) at ../migration/savevm.c:2724 > #9 0x02aa284fc2fe in loadvm_handle_cmd_packaged (mis= out>) at ../migration/savevm.c:2248 > #10 loadvm_process_command (f=0x2aa2b6a3490) at ../migration/savevm.c:2373 > #11 qemu_loadvm_state_main (f=f@entry=0x2aa2b6a3490, > mis=mis@entry=0x2aa2b37b3a0) at ../migration/savevm.c:2724 > #12 0x02aa284fcf14 in qemu_loadvm_state (f=0x2aa2b6a3490) at > ../migration/savevm.c:2790 > #13 0x02aa284e9f64 in process_incoming_migration_co > (opaque=) at ../migration/migration.c:606 > #14 0x02aa28ad92e6 in coroutine_trampoline (i0=, > i1=) at ../util/coroutine-ucontext.c:177 > #15 0x03ff858569c2 in __makecontext_ret () at > ../sysdeps/unix/sysv/linux/s390/s390-64/__makecontext_ret.S:23 > [Inferior 1 (process 1465125) detached] > > -- PMM > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH 03/43] migration: Create migration_cap_set()
* Juan Quintela (quint...@redhat.com) wrote:
> And remove the convoluted use of qmp_migrate_set_capabilities() to
> enable disable MIGRATION_CAPABILITY_BLOCK.
>
> Signed-off-by: Juan Quintela
> ---
> migration/migration.c | 34 --
> 1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 119027a656..e3062530f0 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1910,25 +1910,24 @@ void migrate_set_state(int *state, int old_state, int
> new_state)
> }
> }
>
> -static MigrationCapabilityStatus *migrate_cap_add(MigrationCapability index,
> - bool state)
> +static bool migrate_cap_set(int cap, bool value, Error **errp)
Why int cap rather than MigrationCapability ?
Dave
> {
> -MigrationCapabilityStatus *cap;
> +MigrationState *s = migrate_get_current();
> +bool new_caps[MIGRATION_CAPABILITY__MAX];
>
> -cap = g_new0(MigrationCapabilityStatus, 1);
> -cap->capability = index;
> -cap->state = state;
> +if (migration_is_running(s->state)) {
> +error_setg(errp, QERR_MIGRATION_ACTIVE);
> +return false;
> +}
>
> -return cap;
> -}
> +memcpy(new_caps, s->capabilities, sizeof(new_caps));
> +new_caps[cap] = value;
>
> -void migrate_set_block_enabled(bool value, Error **errp)
> -{
> -MigrationCapabilityStatusList *cap = NULL;
> -
> -QAPI_LIST_PREPEND(cap, migrate_cap_add(MIGRATION_CAPABILITY_BLOCK,
> value));
> -qmp_migrate_set_capabilities(cap, errp);
> -qapi_free_MigrationCapabilityStatusList(cap);
> +if (!migrate_caps_check(s->capabilities, new_caps, errp)) {
> +return false;
> +}
> +s->capabilities[cap] = value;
> +return true;
> }
>
> static void migrate_set_block_incremental(MigrationState *s, bool value)
> @@ -1940,7 +1939,7 @@ static void block_cleanup_parameters(MigrationState *s)
> {
> if (s->must_remove_block_options) {
> /* setting to false can never fail */
> -migrate_set_block_enabled(false, _abort);
> +migrate_cap_set(MIGRATION_CAPABILITY_BLOCK, false, _abort);
> migrate_set_block_incremental(s, false);
> s->must_remove_block_options = false;
> }
> @@ -2427,8 +2426,7 @@ static bool migrate_prepare(MigrationState *s, bool
> blk, bool blk_inc,
> "current migration capabilities");
> return false;
> }
> -migrate_set_block_enabled(true, _err);
> -if (local_err) {
> +if (!migrate_cap_set(MIGRATION_CAPABILITY_BLOCK, true, _err)) {
> error_propagate(errp, local_err);
> return false;
> }
> --
> 2.39.2
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH 04/43] migration: create options.c
* Juan Quintela (quint...@redhat.com) wrote: > We move there all capabilities helpers from migration.c. > > Signed-off-by: Juan Quintela > --- > migration/migration.h | 12 > migration/options.h| 34 + > hw/virtio/virtio-balloon.c | 1 + > migration/block-dirty-bitmap.c | 1 + > migration/block.c | 1 + > migration/colo.c | 1 + > migration/migration.c | 109 +--- > migration/options.c| 126 + > migration/postcopy-ram.c | 1 + > migration/ram.c| 1 + > migration/savevm.c | 1 + > migration/socket.c | 1 + > migration/meson.build | 1 + > 13 files changed, 170 insertions(+), 120 deletions(-) > create mode 100644 migration/options.h > create mode 100644 migration/options.c > > diff --git a/migration/migration.h b/migration/migration.h > index b07efaf259..68851e485d 100644 > --- a/migration/migration.h > +++ b/migration/migration.h > @@ -410,16 +410,7 @@ MigrationState *migrate_get_current(void); > > bool migrate_postcopy(void); > > -bool migrate_release_ram(void); > -bool migrate_postcopy_ram(void); > -bool migrate_zero_blocks(void); > -bool migrate_dirty_bitmaps(void); > -bool migrate_ignore_shared(void); > -bool migrate_validate_uuid(void); > - > -bool migrate_auto_converge(void); > bool migrate_use_multifd(void); > -bool migrate_pause_before_switchover(void); > int migrate_multifd_channels(void); > MultiFDCompression migrate_multifd_compression(void); > int migrate_multifd_zlib_level(void); > @@ -448,9 +439,6 @@ int migrate_compress_threads(void); > int migrate_compress_wait_thread(void); > int migrate_decompress_threads(void); > bool migrate_use_events(void); > -bool migrate_postcopy_blocktime(void); > -bool migrate_background_snapshot(void); > -bool migrate_postcopy_preempt(void); > > /* Sending on the return path - generic and then for each message type */ > void migrate_send_rp_shut(MigrationIncomingState *mis, > diff --git a/migration/options.h b/migration/options.h > new file mode 100644 > index 00..bae032375a > --- /dev/null > +++ b/migration/options.h > @@ -0,0 +1,34 @@ > +/* > + * QEMU migration options > + * > + * Copyright IBM, Corp. 2008 > + * > + * Authors: > + * Anthony Liguori > + * > + * This work is licensed under the terms of the GNU GPL, version 2. See > + * the COPYING file in the top-level directory. > + * > + * Contributions after 2012-01-13 are licensed under the terms of the > + * GNU GPL, version 2 or (at your option) any later version. I don't think any of these functions were written by Anthony, and I think they're all after 2012 aren't they? If so we can update to a more modern header. Other than that, Reviewed-by: Dr. David Alan Gilbert Dave > + */ > + > +#ifndef QEMU_MIGRATION_OPTIONS_H > +#define QEMU_MIGRATION_OPTIONS_H > + > +/* capabilities */ > + > +bool migrate_auto_converge(void); > +bool migrate_background_snapshot(void); > +bool migrate_dirty_bitmaps(void); > +bool migrate_ignore_shared(void); > +bool migrate_late_block_activate(void); > +bool migrate_pause_before_switchover(void); > +bool migrate_postcopy_blocktime(void); > +bool migrate_postcopy_preempt(void); > +bool migrate_postcopy_ram(void); > +bool migrate_release_ram(void); > +bool migrate_validate_uuid(void); > +bool migrate_zero_blocks(void); > + > +#endif > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c > index 746f07c4d2..43092aa634 100644 > --- a/hw/virtio/virtio-balloon.c > +++ b/hw/virtio/virtio-balloon.c > @@ -32,6 +32,7 @@ > #include "qemu/error-report.h" > #include "migration/misc.h" > #include "migration/migration.h" > +#include "migration/options.h" > > #include "hw/virtio/virtio-bus.h" > #include "hw/virtio/virtio-access.h" > diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c > index fe73aa94b1..a6ffae0002 100644 > --- a/migration/block-dirty-bitmap.c > +++ b/migration/block-dirty-bitmap.c > @@ -79,6 +79,7 @@ > #include "qapi/qapi-visit-migration.h" > #include "qapi/clone-visitor.h" > #include "trace.h" > +#include "options.h" > > #define CHUNK_SIZE (1 << 10) > > diff --git a/migration/block.c b/migration/block.c > index 426a25bb19..c4fe9fea56 100644 > --- a/migration/block.c > +++ b/migration/block.c > @@ -28,6 +28,7 @@ > #include "migration/vmstate.h" > #include "sysemu/block-backend.h
Re: [PATCH V2] migration: fix populate_vfio_info
* Steven Sistare (steven.sist...@oracle.com) wrote:
> On 3/7/2023 6:32 AM, Dr. David Alan Gilbert wrote:
> > * Steve Sistare (steven.sist...@oracle.com) wrote:
> >> Include CONFIG_DEVICES so that populate_vfio_info is instantiated for
> >> CONFIG_VFIO. Without it, the 'info migrate' command never returns
> >> info about vfio.
> >>
> >> Fixes: 43bd0bf30f ("migration: Move populate_vfio_info() into a separate
> >> file")
> >> Signed-off-by: Steve Sistare
> >> Reviewed-by: Marc-André Lureau
> >> ---
> >> migration/target.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/migration/target.c b/migration/target.c
> >> index 907ebf0..00ca007 100644
> >> --- a/migration/target.c
> >> +++ b/migration/target.c
> >> @@ -8,6 +8,7 @@
> >> #include "qemu/osdep.h"
> >> #include "qapi/qapi-types-migration.h"
> >> #include "migration.h"
> >> +#include CONFIG_DEVICES
> >>
> >> #ifdef CONFIG_VFIO
> >> #include "hw/vfio/vfio-common.h"
> >> @@ -17,7 +18,6 @@ void populate_vfio_info(MigrationInfo *info)
> >> {
> >> #ifdef CONFIG_VFIO
> >> if (vfio_mig_active()) {
> >> - info->has_vfio = true;
> >
> > Why this removal?
>
> The has_vfio member was removed by:
> 720a252c2651 ("qapi migration: Elide redundant has_FOO in generated C")
> The stale reference was not noticed at the time because the ifdef was never
> true.
Oh ok, that makes sense,
Reviewed-by: Dr. David Alan Gilbert
> - Steve
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH V2] migration: fix populate_vfio_info
* Steve Sistare (steven.sist...@oracle.com) wrote:
> Include CONFIG_DEVICES so that populate_vfio_info is instantiated for
> CONFIG_VFIO. Without it, the 'info migrate' command never returns
> info about vfio.
>
> Fixes: 43bd0bf30f ("migration: Move populate_vfio_info() into a separate
> file")
> Signed-off-by: Steve Sistare
> Reviewed-by: Marc-André Lureau
> ---
> migration/target.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/target.c b/migration/target.c
> index 907ebf0..00ca007 100644
> --- a/migration/target.c
> +++ b/migration/target.c
> @@ -8,6 +8,7 @@
> #include "qemu/osdep.h"
> #include "qapi/qapi-types-migration.h"
> #include "migration.h"
> +#include CONFIG_DEVICES
>
> #ifdef CONFIG_VFIO
> #include "hw/vfio/vfio-common.h"
> @@ -17,7 +18,6 @@ void populate_vfio_info(MigrationInfo *info)
> {
> #ifdef CONFIG_VFIO
> if (vfio_mig_active()) {
> -info->has_vfio = true;
Why this removal?
Dave
> info->vfio = g_malloc0(sizeof(*info->vfio));
> info->vfio->transferred = vfio_mig_bytes_transferred();
> }
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PATCH] tests/migration: Tweek auto converge limits check
From: "Dr. David Alan Gilbert"
Thomas found an autoconverge test failure where the
migration completed before the autoconverge had kicked in.
To try and avoid this again:
a) Reduce the usleep in test_migrate_auto_converge
so that it should exit quicker when autoconverge kicks in
b) Make the loop exit immediately rather than have the sleep
when it does start autoconverge, otherwise the autoconverge
might succeed during the sleep.
c) Reduce inc_pct so auto converge happens more slowly
d) Reduce the max-bandwidth in migrate_ensure_non_converge
to make the ensure more ensure.
Signed-off-by: Dr. David Alan Gilbert
---
tests/qtest/migration-test.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index d4ab3934ed..75d4f1d4a9 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -408,8 +408,8 @@ static void migrate_set_parameter_str(QTestState *who,
const char *parameter,
static void migrate_ensure_non_converge(QTestState *who)
{
-/* Can't converge with 1ms downtime + 30 mbs bandwidth limit */
-migrate_set_parameter_int(who, "max-bandwidth", 30 * 1000 * 1000);
+/* Can't converge with 1ms downtime + 3 mbs bandwidth limit */
+migrate_set_parameter_int(who, "max-bandwidth", 3 * 1000 * 1000);
migrate_set_parameter_int(who, "downtime-limit", 1);
}
@@ -1808,7 +1808,7 @@ static void test_migrate_auto_converge(void)
* E.g., with 1Gb/s bandwith migration may pass without throttling,
* so we need to decrease a bandwidth.
*/
-const int64_t init_pct = 5, inc_pct = 50, max_pct = 95;
+const int64_t init_pct = 5, inc_pct = 25, max_pct = 95;
if (test_migrate_start(, , uri, )) {
return;
@@ -1835,13 +1835,16 @@ static void test_migrate_auto_converge(void)
/* Wait for throttling begins */
percentage = 0;
-while (percentage == 0) {
+do {
percentage = read_migrate_property_int(from,
"cpu-throttle-percentage");
-usleep(100);
+if (percentage != 0) {
+break;
+}
+usleep(20);
g_assert_false(got_stop);
-}
-/* The first percentage of throttling should be equal to init_pct */
-g_assert_cmpint(percentage, ==, init_pct);
+} while (true);
+/* The first percentage of throttling should be at least init_pct */
+g_assert_cmpint(percentage, >=, init_pct);
/* Now, when we tested that throttling works, let it converge */
migrate_ensure_converge(from);
--
2.39.2
Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Mon, Mar 06, 2023 at 01:44:38PM +0000, Dr. David Alan Gilbert wrote: > > * Thomas Huth (th...@redhat.com) wrote: > > > On 03/03/2023 13.05, Peter Maydell wrote: > > > > On Fri, 3 Mar 2023 at 11:29, Thomas Huth wrote: > > > > > > > > > > On 03/03/2023 12.18, Peter Maydell wrote: > > > > > > On Fri, 3 Mar 2023 at 09:10, Juan Quintela > > > > > > wrote: > > > > > > > > > > > > > > Daniel P. Berrangé wrote: > > > > > > > > On Thu, Mar 02, 2023 at 05:22:11PM +, Peter Maydell wrote: > > > > > > > > > migration-test has been flaky for a long time, both in CI and > > > > > > > > > otherwise: > > > > > > > > > > > > > > > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3806090216 > > > > > > > > > (a FreeBSD job) > > > > > > > > > 32/648 > > > > > > > > > ERROR:../tests/qtest/migration-helpers.c:205:wait_for_migration_status: > > > > > > > > > assertion failed: (g_test_timer_elapsed() < > > > > > > > > > MIGRATION_STATUS_WAIT_TIMEOUT) ERROR > > > > > > > > > > > > > > > > > > on a local macos x86 box: > > > > > > > > > > > > > > > > > > > > > > > > > What is really weird with this failure is that: > > > > > > > - it only happens on non-x86 > > > > > > > > > > > > No, I have seen it on x86 macos, and x86 OpenBSD > > > > > > > > > > > > > - on code that is not arch dependent > > > > > > > - on cancel, what we really do there is close fd's for the multifd > > > > > > > channel threads to get out of the recv, i.e. again, nothing > > > > > > > that > > > > > > > should be arch dependent. > > > > > > > > > > > > I'm pretty sure that it tends to happen when the machine that's > > > > > > running the test is heavily loaded. You probably have a race > > > > > > condition. > > > > > > > > > > I think I can second that. IIRC I've seen it a couple of times on my > > > > > x86 > > > > > laptop when running "make check -j$(nproc) SPEED=slow" here. > > > > > > > > And another on-x86 failure case, just now, on the FreeBSD x86 CI job: > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3870165180 > > > > > > And FWIW, I just saw this while doing "make vm-build-netbsd J=4": > > > > > > ▶ 31/645 > > > ERROR:../src/tests/qtest/migration-test.c:1841:test_migrate_auto_converge: > > > 'got_stop' should be FALSE ERROR > > > > That one is kind of interesting; this is an auto converge test - so it > > tries to setup migration so it won't finish, to check that the auto > > converge kicks in. Except in this case the migration *did* finish > > without the autoconverge (significantly) kicking in. > > > > So I guess any of: > > a) The CPU thread never got much CPU time so not much dirtying > > happened. > > b) The bandwidth calculations might be bad enough/course enough > > that it's passing the (very low) bandwidth limit due to bad > > approximation at bandwidth needed. > > c) The autoconverge jump happens fast enough for that loop > > to hit the got_stop in the loop time of that loop. > > > > I guess we could: > > i) Reduce the usleep in test_migrate_auto_converge > > (So it is more likely to correctly drop out of that loop > > as soon as autoconverge kicks in) > > The CPU time spent by the dirtying guest CPUs should dominate > here, so we can afford to reduce that timeout down a bit to > be more responsive. > > > ii) Reduce inc_pct so that autoconverge kicks in slower > > iii) Reduce max-bandwidth in migrate_ensure_non_converge > > even further. > > migrate_ensure_non_converge is trying to guarantee non-convergance, > but obviously we're only achieving a probibalistic chance of > non-converage. To get the probably closer to 100% we should make > it massively smaller, say 100kbs instead of 30mbs. Interestingly that doesn't work; I've not quite worked out why yet; I pushed it to 30kbps and it got stuck in the basic fd test. My guess is that it's starving something so it never makes any forward progress. Dave > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Mon, Mar 06, 2023 at 01:44:38PM +0000, Dr. David Alan Gilbert wrote: > > * Thomas Huth (th...@redhat.com) wrote: > > > On 03/03/2023 13.05, Peter Maydell wrote: > > > > On Fri, 3 Mar 2023 at 11:29, Thomas Huth wrote: > > > > > > > > > > On 03/03/2023 12.18, Peter Maydell wrote: > > > > > > On Fri, 3 Mar 2023 at 09:10, Juan Quintela > > > > > > wrote: > > > > > > > > > > > > > > Daniel P. Berrangé wrote: > > > > > > > > On Thu, Mar 02, 2023 at 05:22:11PM +, Peter Maydell wrote: > > > > > > > > > migration-test has been flaky for a long time, both in CI and > > > > > > > > > otherwise: > > > > > > > > > > > > > > > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3806090216 > > > > > > > > > (a FreeBSD job) > > > > > > > > > 32/648 > > > > > > > > > ERROR:../tests/qtest/migration-helpers.c:205:wait_for_migration_status: > > > > > > > > > assertion failed: (g_test_timer_elapsed() < > > > > > > > > > MIGRATION_STATUS_WAIT_TIMEOUT) ERROR > > > > > > > > > > > > > > > > > > on a local macos x86 box: > > > > > > > > > > > > > > > > > > > > > > > > > What is really weird with this failure is that: > > > > > > > - it only happens on non-x86 > > > > > > > > > > > > No, I have seen it on x86 macos, and x86 OpenBSD > > > > > > > > > > > > > - on code that is not arch dependent > > > > > > > - on cancel, what we really do there is close fd's for the multifd > > > > > > > channel threads to get out of the recv, i.e. again, nothing > > > > > > > that > > > > > > > should be arch dependent. > > > > > > > > > > > > I'm pretty sure that it tends to happen when the machine that's > > > > > > running the test is heavily loaded. You probably have a race > > > > > > condition. > > > > > > > > > > I think I can second that. IIRC I've seen it a couple of times on my > > > > > x86 > > > > > laptop when running "make check -j$(nproc) SPEED=slow" here. > > > > > > > > And another on-x86 failure case, just now, on the FreeBSD x86 CI job: > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3870165180 > > > > > > And FWIW, I just saw this while doing "make vm-build-netbsd J=4": > > > > > > ▶ 31/645 > > > ERROR:../src/tests/qtest/migration-test.c:1841:test_migrate_auto_converge: > > > 'got_stop' should be FALSE ERROR > > > > That one is kind of interesting; this is an auto converge test - so it > > tries to setup migration so it won't finish, to check that the auto > > converge kicks in. Except in this case the migration *did* finish > > without the autoconverge (significantly) kicking in. > > > > So I guess any of: > > a) The CPU thread never got much CPU time so not much dirtying > > happened. > > b) The bandwidth calculations might be bad enough/course enough > > that it's passing the (very low) bandwidth limit due to bad > > approximation at bandwidth needed. > > c) The autoconverge jump happens fast enough for that loop > > to hit the got_stop in the loop time of that loop. > > > > I guess we could: > > i) Reduce the usleep in test_migrate_auto_converge > > (So it is more likely to correctly drop out of that loop > > as soon as autoconverge kicks in) > > The CPU time spent by the dirtying guest CPUs should dominate > here, so we can afford to reduce that timeout down a bit to > be more responsive. > > > ii) Reduce inc_pct so that autoconverge kicks in slower > > iii) Reduce max-bandwidth in migrate_ensure_non_converge > > even further. > > migrate_ensure_non_converge is trying to guarantee non-convergance, > but obviously we're only achieving a probibalistic chance of > non-converage. To get the probably closer to 100% we should make > it massively smaller, say 100kbs instead of 30mbs. Yeh, I'll cut a patch for this. Dave > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
* Thomas Huth (th...@redhat.com) wrote: > On 03/03/2023 13.05, Peter Maydell wrote: > > On Fri, 3 Mar 2023 at 11:29, Thomas Huth wrote: > > > > > > On 03/03/2023 12.18, Peter Maydell wrote: > > > > On Fri, 3 Mar 2023 at 09:10, Juan Quintela wrote: > > > > > > > > > > Daniel P. Berrangé wrote: > > > > > > On Thu, Mar 02, 2023 at 05:22:11PM +, Peter Maydell wrote: > > > > > > > migration-test has been flaky for a long time, both in CI and > > > > > > > otherwise: > > > > > > > > > > > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3806090216 > > > > > > > (a FreeBSD job) > > > > > > > 32/648 > > > > > > > ERROR:../tests/qtest/migration-helpers.c:205:wait_for_migration_status: > > > > > > > assertion failed: (g_test_timer_elapsed() < > > > > > > > MIGRATION_STATUS_WAIT_TIMEOUT) ERROR > > > > > > > > > > > > > > on a local macos x86 box: > > > > > > > > > > > > > > > > > What is really weird with this failure is that: > > > > > - it only happens on non-x86 > > > > > > > > No, I have seen it on x86 macos, and x86 OpenBSD > > > > > > > > > - on code that is not arch dependent > > > > > - on cancel, what we really do there is close fd's for the multifd > > > > > channel threads to get out of the recv, i.e. again, nothing that > > > > > should be arch dependent. > > > > > > > > I'm pretty sure that it tends to happen when the machine that's > > > > running the test is heavily loaded. You probably have a race condition. > > > > > > I think I can second that. IIRC I've seen it a couple of times on my x86 > > > laptop when running "make check -j$(nproc) SPEED=slow" here. > > > > And another on-x86 failure case, just now, on the FreeBSD x86 CI job: > > https://gitlab.com/qemu-project/qemu/-/jobs/3870165180 > > And FWIW, I just saw this while doing "make vm-build-netbsd J=4": > > ▶ 31/645 > ERROR:../src/tests/qtest/migration-test.c:1841:test_migrate_auto_converge: > 'got_stop' should be FALSE ERROR That one is kind of interesting; this is an auto converge test - so it tries to setup migration so it won't finish, to check that the auto converge kicks in. Except in this case the migration *did* finish without the autoconverge (significantly) kicking in. So I guess any of: a) The CPU thread never got much CPU time so not much dirtying happened. b) The bandwidth calculations might be bad enough/course enough that it's passing the (very low) bandwidth limit due to bad approximation at bandwidth needed. c) The autoconverge jump happens fast enough for that loop to hit the got_stop in the loop time of that loop. I guess we could: i) Reduce the usleep in test_migrate_auto_converge (So it is more likely to correctly drop out of that loop as soon as autoconverge kicks in) ii) Reduce inc_pct so that autoconverge kicks in slower iii) Reduce max-bandwidth in migrate_ensure_non_converge even further. Dave > 31/645 qemu:qtest+qtest-i386 / qtest-i386/migration-test > ERROR 25.21s killed by signal 6 SIGABRT > > > > QTEST_QEMU_BINARY=./qemu-system-i386 MALLOC_PERTURB_=35 > > > > G_TEST_DBUS_DAEMON=/home/qemu/qemu-test.fYHKFz/src/tests/dbus-vmstate-daemon.sh > > > > QTEST_QEMU_IMG=./qemu-img > > > > /home/qemu/qemu-test.fYHKFz/build/tests/qtest/migration-test --tap -k > ―― ✀ > ――― > stderr: > qemu: thread naming not supported on this host > qemu: thread naming not supported on this host > qemu: thread naming not supported on this host > qemu: thread naming not supported on this host > qemu: thread naming not supported on this host > qemu: thread naming not supported on this host > ** > ERROR:../src/tests/qtest/migration-test.c:1841:test_migrate_auto_converge: > 'got_stop' should be FALSE > > (test program exited with status code -6) > > Thomas > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RESEND v7 5/9] tests/avocado: Pass parameters to migration test
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Tue, 28 Feb 2023 at 19:28, Fabiano Rosas wrote:
> >
> > The migration tests are currently broken for an aarch64 host because
> > the tests pass no 'machine' and 'cpu' options on the QEMU command
> > line.
> >
> > Add a separate class to each architecture so that we can specify
> > 'machine' and 'cpu' options instead of relying on defaults.
> >
> > Add a skip decorator to keep the current behavior of only running
> > migration tests when the qemu target matches the host architecture.
>
> I still don't understand this patch. Don't we run the
> migration-test on all hosts already? David ?
I don't run the avocado tests.
Dave
> > Signed-off-by: Fabiano Rosas
> > ---
> > tests/avocado/migration.py | 83 +++---
> > 1 file changed, 78 insertions(+), 5 deletions(-)
> >
> > diff --git a/tests/avocado/migration.py b/tests/avocado/migration.py
> > index 4b25680c50..8b2ec0e3c4 100644
> > --- a/tests/avocado/migration.py
> > +++ b/tests/avocado/migration.py
> > @@ -11,6 +11,8 @@
> >
> >
> > import tempfile
> > +import os
> > +
> > from avocado_qemu import QemuSystemTest
> > from avocado import skipUnless
> >
> > @@ -19,7 +21,7 @@
> > from avocado.utils.path import find_command
> >
> >
> > -class Migration(QemuSystemTest):
> > +class MigrationTest(QemuSystemTest):
> > """
> > :avocado: tags=migration
> > """
> > @@ -62,20 +64,91 @@ def _get_free_port(self):
> > self.cancel('Failed to find a free port')
> > return port
> >
> > -
> > -def test_migration_with_tcp_localhost(self):
> > +def migration_with_tcp_localhost(self):
> > dest_uri = 'tcp:localhost:%u' % self._get_free_port()
> > self.do_migrate(dest_uri)
> >
> > -def test_migration_with_unix(self):
> > +def migration_with_unix(self):
> > with tempfile.TemporaryDirectory(prefix='socket_') as socket_path:
> > dest_uri = 'unix:%s/qemu-test.sock' % socket_path
> > self.do_migrate(dest_uri)
> >
> > @skipUnless(find_command('nc', default=False), "'nc' command not
> > found")
> > -def test_migration_with_exec(self):
> > +def migration_with_exec(self):
> > """The test works for both netcat-traditional and netcat-openbsd
> > packages."""
> > free_port = self._get_free_port()
> > dest_uri = 'exec:nc -l localhost %u' % free_port
> > src_uri = 'exec:nc localhost %u' % free_port
> > self.do_migrate(dest_uri, src_uri)
> > +
> > +
> > +@skipUnless('aarch64' in os.uname()[4], "host != target")
> > +class Aarch64(MigrationTest):
> > +"""
> > +:avocado: tags=arch:aarch64
> > +:avocado: tags=machine:virt
> > +:avocado: tags=cpu:max
> > +"""
> > +
> > +def test_migration_with_tcp_localhost(self):
> > +self.migration_with_tcp_localhost()
> > +
> > +def test_migration_with_unix(self):
> > +self.migration_with_unix()
> > +
> > +def test_migration_with_exec(self):
> > +self.migration_with_exec()
> > +
> > +
> > +@skipUnless('x86_64' in os.uname()[4], "host != target")
> > +class X86_64(MigrationTest):
> > +"""
> > +:avocado: tags=arch:x86_64
> > +:avocado: tags=machine:pc
> > +:avocado: tags=cpu:qemu64
> > +"""
> > +
> > +def test_migration_with_tcp_localhost(self):
> > +self.migration_with_tcp_localhost()
> > +
> > +def test_migration_with_unix(self):
> > +self.migration_with_unix()
> > +
> > +def test_migration_with_exec(self):
> > +self.migration_with_exec()
> > +
> > +
> > +@skipUnless('ppc64le' in os.uname()[4], "host != target")
> > +class PPC64(MigrationTest):
> > +"""
> > +:avocado: tags=arch:ppc64
> > +:avocado: tags=machine:pseries
> > +:avocado: tags=cpu:power9_v2.0
> > +"""
> > +
> > + def test_migration_with_tcp_localhost(self):
> > +self.migration_with_tcp_localhost()
> > +
> > +def test_migration_with_unix(self):
> > +self.migration_with_unix()
> > +
> > +def test_migration_with_exec(self):
> > +self.migration_with_exec()
> > +
> > +
> > +@skipUnless('s390x' in os.uname()[4], "host != target")
> > +class S390X(MigrationTest):
> > +"""
> > +:avocado: tags=arch:s390x
> > +:avocado: tags=machine:s390-ccw-virtio
> > +:avocado: tags=cpu:qemu
> > +"""
> > +
> > +def test_migration_with_tcp_localhost(self):
> > +self.migration_with_tcp_localhost()
> > +
> > +def test_migration_with_unix(self):
> > +self.migration_with_unix()
> > +
> > +def test_migration_with_exec(self):
> > +self.migration_with_exec()
> > --
> > 2.35.3
>
> thanks
> -- PMM
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PULL 14/53] virtio-rng-pci: fix transitional migration compat for vectors
* Michael Tokarev (m...@tls.msk.ru) wrote:
> 02.03.2023 11:25, Michael S. Tsirkin wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > In bad9c5a516 ("virtio-rng-pci: fix migration compat for vectors") I
> > fixed the virtio-rng-pci migration compatibility, but it was discovered
> > that we also need to fix the other aliases of the device for the
> > transitional cases.
> >
> > Fixes: 9ea02e8f1 ('virtio-rng-pci: Allow setting nvectors, so we can use
> > MSI-X')
> > bz: https://bugzilla.redhat.com/show_bug.cgi?id=2162569
> > Signed-off-by: Dr. David Alan Gilbert
> > Message-Id: <20230207174944.138255-1-dgilb...@redhat.com>
> > Reviewed-by: Michael S. Tsirkin
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > hw/core/machine.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index f29e700ee4..1cf6822e06 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -47,6 +47,8 @@ const size_t hw_compat_7_2_len =
> > G_N_ELEMENTS(hw_compat_7_2);
> > GlobalProperty hw_compat_7_1[] = {
> > { "virtio-device", "queue_reset", "false" },
> > { "virtio-rng-pci", "vectors", "0" },
> > +{ "virtio-rng-pci-transitional", "vectors", "0" },
> > + { "virtio-rng-pci-non-transitional", "vectors", "0" },
> > };
>
> If we consider this one for 7.2 stable, the previous change here, which
> added "virtio-rng-pci" right before the lines being added, should also
> be picked up, which is bad9c5a5166fd5e3a892b7b0477cf2f4bd3a959a:
> From: "Dr. David Alan Gilbert"
> Date: Mon, 9 Jan 2023 10:58:09 +
> Subject: virtio-rng-pci: fix migration compat for vectors
>
> Should the two both be included in -stable, or both omitted?
I think both included; however note the warning in the original patch
(that's also true in this one); live migration from an unpatched world
to the patched would will break, but it fixes live migration from older
Qemu; you get to pick your favourite breakage.
Dave
> Thanks,
>
> /mjt
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> migration-test has been flaky for a long time, both in CI and
> otherwise:
>
> https://gitlab.com/qemu-project/qemu/-/jobs/3806090216
> (a FreeBSD job)
> 32/648
> ERROR:../tests/qtest/migration-helpers.c:205:wait_for_migration_status:
> assertion failed: (g_test_timer_elapsed() < MIGRATION_STATUS_WAIT_TIMEOUT)
> ERROR
>
> on a local macos x86 box:
> ▶ 34/621
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed")) ERROR
> 34/621 qemu:qtest+qtest-i386 / qtest-i386/migration-test
> ERROR 168.12s killed by signal 6 SIGABRT
> ― ✀ ―
> stderr:
> qemu-system-i386: Failed to peek at channel
> query-migrate shows failed migration: Unable to write to socket: Broken pipe
> **
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed"))
>
> (test program exited with status code -6)
> ――
>
> ▶ 37/621
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed")) ERROR
> 37/621 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test
> ERROR 174.37s killed by signal 6 SIGABRT
> ― ✀ ―
> stderr:
> query-migrate shows failed migration: Unable to write to socket: Broken pipe
> **
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed"))
>
> (test program exited with status code -6)
>
> In the cases where I've looked at the underlying log, this seems to
> be in the migration/multifd/tcp/plain/cancel subtest. Disable that
> specific subtest by default until somebody can track down the
> underlying cause. Enthusiasts can opt back in by setting
> QEMU_TEST_FLAKY_TESTS=1 in their environment.
>
> We might need to disable more parts of this test if this isn't
> sufficient to fix the flakiness.
>
> Signed-off-by: Peter Maydell
> ---
> This is a slightly more targeted variation on my original
> modest proposal.
> ---
> tests/qtest/migration-test.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
> index 109bc8e7b13..d4ab3934ed2 100644
> --- a/tests/qtest/migration-test.c
> +++ b/tests/qtest/migration-test.c
> @@ -2572,8 +2572,14 @@ int main(int argc, char **argv)
> qtest_add_func("/migration/auto_converge", test_migrate_auto_converge);
> qtest_add_func("/migration/multifd/tcp/plain/none",
> test_multifd_tcp_none);
> -qtest_add_func("/migration/multifd/tcp/plain/cancel",
> - test_multifd_tcp_cancel);
> +/*
> + * This test is flaky and sometimes fails in CI and otherwise:
> + * don't run unless user opts in via environment variable.
> + */
> +if (getenv("QEMU_TEST_FLAKY_TESTS")) {
> +qtest_add_func("/migration/multifd/tcp/plain/cancel",
> + test_multifd_tcp_cancel);
> +}
OK, that seems reasonably selective.
Reviewed-by: Dr. David Alan Gilbert
(Cancel tests are always a pain; they can be racy with the test
completing before you fire the cancel; or 'cancel' itself
can hit lots of races inside the migration code if it's not written
carefully enough to expect a cancel).
Dave
> qtest_add_func("/migration/multifd/tcp/plain/zlib",
> test_multifd_tcp_zlib);
> #ifdef CONFIG_ZSTD
> --
> 2.34.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v5 07/12] hmp: add cryptodev info command
* zhenwei pi (pizhen...@bytedance.com) wrote:
> Example of this command:
> # virsh qemu-monitor-command vm --hmp info cryptodev
> cryptodev1: service=[akcipher|mac|hash|cipher]
> queue 0: type=builtin
> cryptodev0: service=[akcipher]
> queue 0: type=lkcf
>
> Signed-off-by: zhenwei pi
Yes, I think that's fine from HMP; you might want to use some of the
qapi list macros;
Acked-by: Dr. David Alan Gilbert
> ---
> backends/cryptodev-hmp-cmds.c | 54 +++
> backends/meson.build | 1 +
> hmp-commands-info.hx | 14 +
> include/monitor/hmp.h | 1 +
> 4 files changed, 70 insertions(+)
> create mode 100644 backends/cryptodev-hmp-cmds.c
>
> diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
> new file mode 100644
> index 00..4f7220bb13
> --- /dev/null
> +++ b/backends/cryptodev-hmp-cmds.c
> @@ -0,0 +1,54 @@
> +/*
> + * HMP commands related to cryptodev
> + *
> + * Copyright (c) 2023 Bytedance.Inc
> + *
> + * Authors:
> + *zhenwei pi
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or
> + * (at your option) any later version.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "monitor/hmp.h"
> +#include "monitor/monitor.h"
> +#include "qapi/qapi-commands-cryptodev.h"
> +#include "qapi/qmp/qdict.h"
> +
> +
> +void hmp_info_cryptodev(Monitor *mon, const QDict *qdict)
> +{
> +QCryptodevInfoList *il;
> +QCryptodevBackendServiceTypeList *sl;
> +QCryptodevBackendClientList *cl;
> +
> +for (il = qmp_query_cryptodev(NULL); il; il = il->next) {
> +g_autofree char *services = NULL;
> +QCryptodevInfo *info = il->value;
> +char *tmp_services;
> +
> +/* build a string like 'service=[akcipher|mac|hash|cipher]' */
> +for (sl = info->service; sl; sl = sl->next) {
> +const char *service =
> QCryptodevBackendServiceType_str(sl->value);
> +
> +if (!services) {
> +services = g_strdup(service);
> +} else {
> +tmp_services = g_strjoin("|", services, service, NULL);
> +g_free(services);
> +services = tmp_services;
> +}
> +}
> +monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
> +
> +for (cl = info->client; cl; cl = cl->next) {
> +QCryptodevBackendClient *client = cl->value;
> +monitor_printf(mon, "queue %" PRIu32 ": type=%s\n",
> + client->queue,
> + QCryptodevBackendType_str(client->type));
> +}
> +}
> +
> +qapi_free_QCryptodevInfoList(il);
> +}
> diff --git a/backends/meson.build b/backends/meson.build
> index 954e658b25..b369e0a9d0 100644
> --- a/backends/meson.build
> +++ b/backends/meson.build
> @@ -1,5 +1,6 @@
> softmmu_ss.add([files(
>'cryptodev-builtin.c',
> + 'cryptodev-hmp-cmds.c',
>'cryptodev.c',
>'hostmem-ram.c',
>'hostmem.c',
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 754b1e8408..47d63d26db 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -993,3 +993,17 @@ SRST
>``info virtio-queue-element`` *path* *queue* [*index*]
> Display element of a given virtio queue
> ERST
> +
> +{
> +.name = "cryptodev",
> +.args_type = "",
> +.params = "",
> +.help = "show the crypto devices",
> +.cmd= hmp_info_cryptodev,
> +.flags = "p",
> +},
> +
> +SRST
> + ``info cryptodev``
> +Show the crypto devices.
> +ERST
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 2220f14fc9..e6cf0b7aa7 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -178,5 +178,6 @@ void hmp_ioport_read(Monitor *mon, const QDict *qdict);
> void hmp_ioport_write(Monitor *mon, const QDict *qdict);
> void hmp_boot_set(Monitor *mon, const QDict *qdict);
> void hmp_info_mtree(Monitor *mon, const QDict *qdict);
> +void hmp_info_cryptodev(Monitor *mon, const QDict *qdict);
>
> #endif
> --
> 2.34.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v5 07/12] hmp: add cryptodev info command
* zhenwei pi (pizhen...@bytedance.com) wrote:
> Example of this command:
> # virsh qemu-monitor-command vm --hmp info cryptodev
> cryptodev1: service=[akcipher|mac|hash|cipher]
> queue 0: type=builtin
> cryptodev0: service=[akcipher]
> queue 0: type=lkcf
>
> Signed-off-by: zhenwei pi
Acked-by: Dr. David Alan Gilbert
> ---
> backends/cryptodev-hmp-cmds.c | 54 +++
> backends/meson.build | 1 +
> hmp-commands-info.hx | 14 +
> include/monitor/hmp.h | 1 +
> 4 files changed, 70 insertions(+)
> create mode 100644 backends/cryptodev-hmp-cmds.c
>
> diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
> new file mode 100644
> index 00..4f7220bb13
> --- /dev/null
> +++ b/backends/cryptodev-hmp-cmds.c
> @@ -0,0 +1,54 @@
> +/*
> + * HMP commands related to cryptodev
> + *
> + * Copyright (c) 2023 Bytedance.Inc
> + *
> + * Authors:
> + *zhenwei pi
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or
> + * (at your option) any later version.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "monitor/hmp.h"
> +#include "monitor/monitor.h"
> +#include "qapi/qapi-commands-cryptodev.h"
> +#include "qapi/qmp/qdict.h"
> +
> +
> +void hmp_info_cryptodev(Monitor *mon, const QDict *qdict)
> +{
> +QCryptodevInfoList *il;
> +QCryptodevBackendServiceTypeList *sl;
> +QCryptodevBackendClientList *cl;
> +
> +for (il = qmp_query_cryptodev(NULL); il; il = il->next) {
> +g_autofree char *services = NULL;
> +QCryptodevInfo *info = il->value;
> +char *tmp_services;
> +
> +/* build a string like 'service=[akcipher|mac|hash|cipher]' */
> +for (sl = info->service; sl; sl = sl->next) {
> +const char *service =
> QCryptodevBackendServiceType_str(sl->value);
> +
> +if (!services) {
> +services = g_strdup(service);
> +} else {
> +tmp_services = g_strjoin("|", services, service, NULL);
> +g_free(services);
> +services = tmp_services;
> +}
> +}
> +monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
> +
> +for (cl = info->client; cl; cl = cl->next) {
> +QCryptodevBackendClient *client = cl->value;
> +monitor_printf(mon, "queue %" PRIu32 ": type=%s\n",
> + client->queue,
> + QCryptodevBackendType_str(client->type));
> +}
> +}
> +
> +qapi_free_QCryptodevInfoList(il);
> +}
> diff --git a/backends/meson.build b/backends/meson.build
> index 954e658b25..b369e0a9d0 100644
> --- a/backends/meson.build
> +++ b/backends/meson.build
> @@ -1,5 +1,6 @@
> softmmu_ss.add([files(
>'cryptodev-builtin.c',
> + 'cryptodev-hmp-cmds.c',
>'cryptodev.c',
>'hostmem-ram.c',
>'hostmem.c',
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 754b1e8408..47d63d26db 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -993,3 +993,17 @@ SRST
>``info virtio-queue-element`` *path* *queue* [*index*]
> Display element of a given virtio queue
> ERST
> +
> +{
> +.name = "cryptodev",
> +.args_type = "",
> +.params = "",
> +.help = "show the crypto devices",
> +.cmd= hmp_info_cryptodev,
> +.flags = "p",
> +},
> +
> +SRST
> + ``info cryptodev``
> +Show the crypto devices.
> +ERST
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 2220f14fc9..e6cf0b7aa7 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -178,5 +178,6 @@ void hmp_ioport_read(Monitor *mon, const QDict *qdict);
> void hmp_ioport_write(Monitor *mon, const QDict *qdict);
> void hmp_boot_set(Monitor *mon, const QDict *qdict);
> void hmp_info_mtree(Monitor *mon, const QDict *qdict);
> +void hmp_info_cryptodev(Monitor *mon, const QDict *qdict);
>
> #endif
> --
> 2.34.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v3 06/10] monitor: release the lock before calling close()
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Feb 14, 2023 at 05:36:32PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, Feb 14, 2023 at 5:34 PM Markus Armbruster wrote:
> > >
> > > marcandre.lur...@redhat.com writes:
> > >
> > > > From: Marc-André Lureau
> > > >
> > > > As per comment, presumably to avoid syscall in critical section.
> > > >
> > > > Fixes: 0210c3b39bef08 ("monitor: Use LOCK_GUARD macros")
> > > > Signed-off-by: Marc-André Lureau
> > > > ---
> > > > monitor/fds.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/monitor/fds.c b/monitor/fds.c
> > > > index 26b39a0ce6..03c5e97c35 100644
> > > > --- a/monitor/fds.c
> > > > +++ b/monitor/fds.c
> > > > @@ -80,7 +80,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > > > return;
> > > > }
> > > >
> > > > -QEMU_LOCK_GUARD(_mon->mon_lock);
> > > > +qemu_mutex_lock(_mon->mon_lock);
> > > > QLIST_FOREACH(monfd, _mon->fds, next) {
> > > > if (strcmp(monfd->name, fdname) != 0) {
> > > > continue;
> > > > @@ -88,6 +88,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > > >
> > > > tmp_fd = monfd->fd;
> > > > monfd->fd = fd;
> > > > +qemu_mutex_unlock(_mon->mon_lock);
> > > > /* Make sure close() is outside critical section */
> > > > close(tmp_fd);
> > > > return;
> > > > @@ -98,6 +99,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > > > monfd->fd = fd;
> > > >
> > > > QLIST_INSERT_HEAD(_mon->fds, monfd, next);
> > > > +qemu_mutex_unlock(_mon->mon_lock);
> > > > }
> > > >
> > > > void qmp_closefd(const char *fdname, Error **errp)
> > >
> > > This confused me. I think I understand now, but let's double-check.
> > >
> > > You're reverting commit 0210c3b39bef08 for qmp_getfd() because it
> > > extended the criticial section beyond the close(), invalidating the
> > > comment. Correct?
> >
> > Correct
> >
> > > Did it actually break anything?
> >
> > Not that I know of (David admitted over IRC that this was not intended)
>
> Conceptually the only risk here is that 'close()' blocks for a
> prolonged period of time, which prevents another thread from
> acquiring the mutex.
>
> First, the chances of close() blocking are incredibly low for
> socket FDs which have not yet been used to transmit data. It
> would require a malicious mgmt app to pass an unexpected FD
> type that could block but that's quite hard, and we consider
> the QMP client be a trusted entity anyway.
I agree it's unlikely; I'm not sure it actually requires something
malicious though; e.g. a managmeent app that is itself blocked,
a socket connection connection over a dead network etc are the ones
we're worrying about - stuff that's not so much slow
as either deadlocked or taking minutes for recovery/timeout.
Dave
> As for another thread blocking on the mutex I'm not convinced
> that'll happen either. The FD set is scoped to the current
> monitor. Almost certainly the FD is going to be consumed by
> a later QMP device-add/object-add command, in the same thread.
> Processing of that later QMP command will be delayed regardless
> of whether the close is inside or outside the critical section.
>
> AFAICT keeping close() oujtside the critical section serves
> no purpose and we could just stick with the lock guard and
> delete the comment.
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] cpu/i386: update xsave components after CPUID filtering
* Huanyu ZHAI (huanyu.z...@outlook.com) wrote: > Subject: [PATCH] cpu/i386: update xsave components after CPUID filtering > > On i386 platform, CPUID data are setup through three consecutive steps: CPU > model definition, expansion and filtering. > XSAVE components are enabled during the expansion stage, by checking if they > are enabled in CPUID. However, it is still > probable that some XSAVE features will be enabled/disabled during the > filtering stage and the XSAVE components left unchanged. > Inconsistency between XSAVE features and enabled XSAVE components can lead to > problems on some Linux guests in the absence of > the following patch in the kernel: > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1452368.html > > A simple case to reproduce this problem is to start a SUSE 12 SP3 guest with > cpu model set to Skylake-Server: > $ qemu-system-x86_64 -cpu Skylake-Server ... > > In the SUSE 12 SP3 guest, one can observe that PKRU will be enabled without > Intel PKU's presence. > That's because on platform with Skylake-Server cpus, Intel PKU is disabled > during x86_cpu_filter_features(), > but the XSAVE PKRU bit was enabled by x86_cpu_expand_features(). I just spotted this when trying to clear out my mail folder; this isn't a 'trivial'! I'm not sure if it's right or not, but I've cc'd in Paolo and Marcelo as x86 maintainers. Dave > Signed-off-by: Huanyu ZHAI zhaihua...@huawei.com<mailto:zhaihua...@huawei.com> > Signed-off-by: Xin Wang > wangxinxin.w...@huawei.com<mailto:wangxinxin.w...@huawei.com> > --- > target/i386/cpu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index 22b681ca37..2ee574cf05 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -6362,6 +6362,9 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool > verbose) > mark_unavailable_features(cpu, FEAT_7_0_EBX, > CPUID_7_0_EBX_INTEL_PT, prefix); > } > } > + > +/* Update XSAVE components again based on the filtered CPU feature flags > */ > +x86_cpu_enable_xsave_components(cpu); > } > > static void x86_cpu_hyperv_realize(X86CPU *cpu) > -- > 2.27.0 > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] tests: Disable migration-test
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 21 Feb 2023 at 15:21, Dr. David Alan Gilbert > wrote: > > Damn this is really going to impact the stability of migration if we > > don't regularly test. > > But fundamentally, I've never been able to debug much of the reports > > that come from flakyness in gitlab ci; we're not getting the most basic > > information like which subtest or where we're upto in the test which > > makes it very very hard to debug. > > Right, but if you want more information you need to change the > tests and/or test harness to provide it. I don't think the migration test is doing anything odd in that respect; We've just got a bunch of qtest tests; having a test framework which doesn't tell you which test failed is very difficult. Dave > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] tests: Disable migration-test
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> The migration-test is annoyingly flaky. Examples:
>
> https://gitlab.com/qemu-project/qemu/-/jobs/3806090216
> (a FreeBSD job)
> 32/648
> ERROR:../tests/qtest/migration-helpers.c:205:wait_for_migration_status:
> assertion failed: (g_test_timer_elapsed() < MIGRATION_STATUS_WAIT_TIMEOUT)
> ERROR
>
> on a local macos x86 box:
> ▶ 34/621
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_
> str_equal(status, "failed")) ERROR
> 34/621 qemu:qtest+qtest-i386 / qtest-i386/migration-test
> ERROR 168.12s killed by signal 6 SIGABRT
> ― ✀ ―
> stderr:
> qemu-system-i386: Failed to peek at channel
> query-migrate shows failed migration: Unable to write to socket: Broken pipe
> **
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed"))
>
> (test program exited with status code -6)
> ――
>
> ▶ 37/621
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed")) ERROR
> 37/621 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test
> ERROR 174.37s killed by signal 6 SIGABRT
> ― ✀ ―
> stderr:
> query-migrate shows failed migration: Unable to write to socket: Broken pipe
> **
> ERROR:../../tests/qtest/migration-helpers.c:151:migrate_query_not_failed:
> assertion failed: (!g_str_equal(status, "failed"))
>
> (test program exited with status code -6)
> ――
>
> I've seen this on other CI jobs as well, but Gitlab's UI makes it
> pretty much impossible to re-find failed jobs, since you can't
> search for them by failure reason at all.
>
> I've also seen this fail on the OpenBSD vm build.
>
> I've seen the migration-test hang on the s390 private CI runner
> in such a way that even though the CI job has timed out, the
> stale QEMU and migration-test processes are still lying around on
> the host.
>
> I've complained about these before, but nobody has either investigated
> or suggested improvements to the test program that would let us gather
> more information about what's happening when these fail.
>
> https://lore.kernel.org/qemu-devel/cafeaca8x_im3hn2-p9f+huxnxfxy+d6fze+leq4erldg7zk...@mail.gmail.com/
Damn this is really going to impact the stability of migration if we
don't regularly test.
But fundamentally, I've never been able to debug much of the reports
that come from flakyness in gitlab ci; we're not getting the most basic
information like which subtest or where we're upto in the test which
makes it very very hard to debug.
Dave
> So this is the big hammer: disable the test entirely, so that we
> don't keep getting CI job intermittent failures because of it.
> When somebody has time to investigate, we can fix the underlying
> cause and reenable the job.
>
> Signed-off-by: Peter Maydell
> ---
> This is an "if you don't want this, propose something else" patch :-)
> ---
> tests/qtest/meson.build | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
> index 29a4efb4c24..0e362fcb1e0 100644
> --- a/tests/qtest/meson.build
> +++ b/tests/qtest/meson.build
> @@ -11,6 +11,12 @@ slow_qtests = {
>'test-hmp' : 120,
> }
>
> +# Temporarily disabled tests can be listed here
> +qtests_disabled = [
> + # This test is currently flaky and fails intermittently
> + 'migration-test',
> +]
> +
> qtests_generic = [
>'cdrom-test',
>'device-introspect-test',
> @@ -343,6 +349,9 @@ foreach dir : target_dirs
>endif
>
>foreach test : target_qtests
> +if test in qtests_disabled
> + continue
> +endif
> # Executables are shared across targets, declare them only the first
> time we
> # encounter them
> if not qtest_executables.has_key(test)
> --
> 2.34.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PULL 2/4] virtiofsd: Remove build and docs glue
From: "Dr. David Alan Gilbert"
Remove all the virtiofsd build and docs infrastructure.
Signed-off-by: Dr. David Alan Gilbert
Acked-by: Stefan Hajnoczi
---
MAINTAINERS| 2 --
docs/conf.py | 4
docs/meson.build | 1 -
docs/tools/index.rst | 1 -
meson.build| 1 -
meson_options.txt | 2 --
.../ci/org.centos/stream/8/x86_64/configure| 2 --
scripts/coverity-scan/COMPONENTS.md| 3 ---
scripts/meson-buildoptions.sh | 3 ---
tools/meson.build | 13 -
tools/virtiofsd/50-qemu-virtiofsd.json.in | 5 -
tools/virtiofsd/meson.build| 18 --
12 files changed, 55 deletions(-)
delete mode 100644 tools/virtiofsd/50-qemu-virtiofsd.json.in
delete mode 100644 tools/virtiofsd/meson.build
diff --git a/MAINTAINERS b/MAINTAINERS
index fd54c1f140..5090ba0e49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2096,10 +2096,8 @@ virtiofs
M: Dr. David Alan Gilbert
M: Stefan Hajnoczi
S: Supported
-F: tools/virtiofsd/*
F: hw/virtio/vhost-user-fs*
F: include/hw/virtio/vhost-user-fs.h
-F: docs/tools/virtiofsd.rst
L: virtio...@redhat.com
virtio-input
diff --git a/docs/conf.py b/docs/conf.py
index 73a287a4f2..00767b0e24 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -290,10 +290,6 @@
('tools/virtfs-proxy-helper', 'virtfs-proxy-helper',
'QEMU 9p virtfs proxy filesystem helper',
['M. Mohan Kumar'], 1),
-('tools/virtiofsd', 'virtiofsd',
- 'QEMU virtio-fs shared file system daemon',
- ['Stefan Hajnoczi ',
- 'Masayoshi Mizuma '], 1),
]
man_make_section_directory = False
diff --git a/docs/meson.build b/docs/meson.build
index 9136fed3b7..bbcdccce68 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -48,7 +48,6 @@ if build_docs
'qemu-storage-daemon.1': (have_tools ? 'man1' : ''),
'qemu-trace-stap.1': (stap.found() ? 'man1' : ''),
'virtfs-proxy-helper.1': (have_virtfs_proxy_helper ? 'man1' : ''),
-'virtiofsd.1': (have_virtiofsd ? 'man1' : ''),
'qemu.1': 'man1',
'qemu-block-drivers.7': 'man7',
'qemu-cpu-models.7': 'man7'
diff --git a/docs/tools/index.rst b/docs/tools/index.rst
index 2151adcf78..8e65ce0dfc 100644
--- a/docs/tools/index.rst
+++ b/docs/tools/index.rst
@@ -16,4 +16,3 @@ command line utilities and other standalone programs.
qemu-pr-helper
qemu-trace-stap
virtfs-proxy-helper
- virtiofsd
diff --git a/meson.build b/meson.build
index a76c855312..adfc0e28b5 100644
--- a/meson.build
+++ b/meson.build
@@ -3879,7 +3879,6 @@ if have_block
summary_info += {'Block whitelist (ro)':
get_option('block_drv_ro_whitelist')}
summary_info += {'Use block whitelist in tools':
get_option('block_drv_whitelist_in_tools')}
summary_info += {'VirtFS support':have_virtfs}
- summary_info += {'build virtiofs daemon': have_virtiofsd}
summary_info += {'Live block migration':
config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
summary_info += {'replication support':
config_host_data.get('CONFIG_REPLICATION')}
summary_info += {'bochs support': get_option('bochs').allowed()}
diff --git a/meson_options.txt b/meson_options.txt
index 7e5801db90..6b0900205e 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -272,8 +272,6 @@ option('vhost_user_blk_server', type: 'feature', value:
'auto',
description: 'build vhost-user-blk server')
option('virtfs', type: 'feature', value: 'auto',
description: 'virtio-9p support')
-option('virtiofsd', type: 'feature', value: 'auto',
- description: 'build virtiofs daemon (virtiofsd)')
option('libvduse', type: 'feature', value: 'auto',
description: 'build VDUSE Library')
option('vduse_blk_export', type: 'feature', value: 'auto',
diff --git a/scripts/ci/org.centos/stream/8/x86_64/configure
b/scripts/ci/org.centos/stream/8/x86_64/configure
index 65eacf3c56..6e8983f39c 100755
--- a/scripts/ci/org.centos/stream/8/x86_64/configure
+++ b/scripts/ci/org.centos/stream/8/x86_64/configure
@@ -138,7 +138,6 @@
--disable-vhost-vdpa \
--disable-virglrenderer \
--disable-virtfs \
---disable-virtiofsd \
--disable-vnc \
--disable-vnc-jpeg \
--disable-png \
@@ -191,7 +190,6 @@
--enable-tpm \
--enable-trace-backends=dtrace \
--enable-usb-redir \
---enable-virtiofsd \
--enable-vhost-kernel \
--enable-vhost-net \
--enable-vhost-user \
diff --git a/scripts/coverity-scan/COMPONENTS.md
b/scripts/coverity-scan/COMPONENTS.md
index 0e6ab4936e..639dcee45a 100644
--- a/scripts/coverity-scan/COMPONENTS.md
+++ b/scripts/coverity-scan/COMPONENTS.md
@@ -132,9 +132,6 @@ util
xen
~ (/qemu)?(.*/xen.*)
-virtiofsd
- ~ (/qemu)?(/tools/virtiofsd/.*)
-
(headers)
~ (/qemu)?(/include/.*)
diff --git a/scripts/meson-buildoptions.sh
[PULL 1/4] virtiofsd: Remove test
From: "Dr. David Alan Gilbert"
Rmove the avocado test for virtiofsd, since we're about to remove
the C implementation.
Signed-off-by: Dr. David Alan Gilbert
Acked-by: Stefan Hajnoczi
---
.../org.centos/stream/8/x86_64/test-avocado | 7 -
tests/avocado/virtiofs_submounts.py | 217 --
2 files changed, 224 deletions(-)
delete mode 100644 tests/avocado/virtiofs_submounts.py
diff --git a/scripts/ci/org.centos/stream/8/x86_64/test-avocado
b/scripts/ci/org.centos/stream/8/x86_64/test-avocado
index 7aeecbcfb8..f403e4e7ec 100755
--- a/scripts/ci/org.centos/stream/8/x86_64/test-avocado
+++ b/scripts/ci/org.centos/stream/8/x86_64/test-avocado
@@ -14,13 +14,6 @@
# * Require machine type "x-remote":
# - tests/avocado/multiprocess.py:Multiprocess.test_multiprocess_x86_64
#
-# * Needs superuser privileges:
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_pre_virtiofsd_set_up
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_pre_launch_set_up
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_post_launch_set_up
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_post_mount_set_up
-# - tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_two_runs
-#
# * Requires display type "egl-headless":
# - tests/avocado/virtio-gpu.py:VirtioGPUx86.test_virtio_vga_virgl
# - tests/avocado/virtio-gpu.py:VirtioGPUx86.test_vhost_user_vga_virgl
diff --git a/tests/avocado/virtiofs_submounts.py
b/tests/avocado/virtiofs_submounts.py
deleted file mode 100644
index e6dc32ffd4..00
--- a/tests/avocado/virtiofs_submounts.py
+++ /dev/null
@@ -1,217 +0,0 @@
-import logging
-import re
-import os
-import subprocess
-import time
-
-from avocado import skipUnless
-from avocado_qemu import LinuxTest, BUILD_DIR
-from avocado_qemu import has_cmds
-from avocado_qemu import run_cmd
-from avocado_qemu import wait_for_console_pattern
-from avocado.utils import ssh
-
-
-class VirtiofsSubmountsTest(LinuxTest):
-"""
-:avocado: tags=arch:x86_64
-:avocado: tags=accel:kvm
-"""
-
-def run(self, args, ignore_error=False):
-stdout, stderr, ret = run_cmd(args)
-
-if ret != 0:
-cmdline = ' '.join(args)
-if not ignore_error:
-self.fail(f'{cmdline}: Returned {ret}: {stderr}')
-else:
-self.log.warn(f'{cmdline}: Returned {ret}: {stderr}')
-
-return (stdout, stderr, ret)
-
-def set_up_shared_dir(self):
-self.shared_dir = os.path.join(self.workdir, 'virtiofs-shared')
-
-os.mkdir(self.shared_dir)
-
-self.run(('cp', self.get_data('guest.sh'),
- os.path.join(self.shared_dir, 'check.sh')))
-
-self.run(('cp', self.get_data('guest-cleanup.sh'),
- os.path.join(self.shared_dir, 'cleanup.sh')))
-
-def set_up_virtiofs(self):
-attmp = os.getenv('AVOCADO_TESTS_COMMON_TMPDIR')
-self.vfsdsock = os.path.join(attmp, 'vfsdsock')
-
-self.run(('sudo', '-n', 'rm', '-f', self.vfsdsock), ignore_error=True)
-
-self.virtiofsd = \
-subprocess.Popen(('sudo', '-n',
- 'tools/virtiofsd/virtiofsd',
- f'--socket-path={self.vfsdsock}',
- '-o', f'source={self.shared_dir}',
- '-o', 'cache=always',
- '-o', 'xattr',
- '-o', 'announce_submounts',
- '-f'),
- stdout=subprocess.DEVNULL,
- stderr=subprocess.PIPE,
- universal_newlines=True)
-
-while not os.path.exists(self.vfsdsock):
-if self.virtiofsd.poll() is not None:
-self.fail('virtiofsd exited prematurely: ' +
- self.virtiofsd.communicate()[1])
-time.sleep(0.1)
-
-self.run(('sudo', '-n', 'chmod', 'go+rw', self.vfsdsock))
-
-self.vm.add_args('-chardev',
- f'socket,id=vfsdsock,path={self.vfsdsock}',
- '-device',
- 'vhost-user-fs-pci,queue-size=1024,chardev=vfsdsock' \
- ',tag=host',
- '-object',
- 'memory-backend-file,id=mem,size=1G,' \
- 'mem-path=/dev/shm,share=on',
- '-numa',
- 'node,memdev=mem')
-
-def set_up_nested_mounts(self):
-scratch_dir = os.path.join(self.shared_dir, 'scratch')
-try:
-os.mkdir(scratch_dir)
-except FileExistsError:
-pass
-
-args = ['bash', self.get_data('host.sh'), scratch_dir]
-if self.seed:
-args += [self.seed]
-
-out, _, _ =
[PULL 4/4] virtiofsd: Swing deprecated message to removed-features
From: "Dr. David Alan Gilbert" Move the deprecation message, since it's now gone. Signed-off-by: Dr. David Alan Gilbert Acked-by: Stefan Hajnoczi --- docs/about/deprecated.rst | 18 -- docs/about/removed-features.rst | 13 + 2 files changed, 13 insertions(+), 18 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 2827b0c0be..ee95bcb1a6 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -330,24 +330,6 @@ versions, aliases will point to newer CPU model versions depending on the machine type, so management software must resolve CPU model aliases before starting a virtual machine. -Tools -- - -virtiofsd -' - -There is a new Rust implementation of ``virtiofsd`` at -``https://gitlab.com/virtio-fs/virtiofsd``; -since this is now marked stable, new development should be done on that -rather than the existing C version in the QEMU tree. -The C version will still accept fixes and patches that -are already in development for the moment, but will eventually -be deleted from this tree. -New deployments should use the Rust version, and existing systems -should consider moving to it. The command line and feature set -is very close and moving should be simple. - - QEMU guest agent diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index e901637ce5..5b258b446b 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -889,3 +889,16 @@ The VXHS code did not compile since v2.12.0. It was removed in 5.1. The corresponding upstream server project is no longer maintained. Users are recommended to switch to an alternative distributed block device driver such as RBD. + +Tools +- + +virtiofsd (removed in 8.0) +'' + +There is a newer Rust implementation of ``virtiofsd`` at +``https://gitlab.com/virtio-fs/virtiofsd``; this has been +stable for some time and is now widely used. +The command line and feature set is very close to the removed +C implementation. + -- 2.39.2
[PULL 0/4] virtiofs queue
From: "Dr. David Alan Gilbert" The following changes since commit 6dffbe36af79e26a4d23f94a9a1c1201de99c261: Merge tag 'migration-20230215-pull-request' of https://gitlab.com/juan.quintela/qemu into staging (2023-02-16 13:09:51 +) are available in the Git repository at: https://gitlab.com/dagrh/qemu.git tags/pull-virtiofs-20230216b for you to fetch changes up to a6bfdaed4a735a2cf59f265e6955fe2adcc99637: virtiofsd: Swing deprecated message to removed-features (2023-02-16 18:15:08 +) Remove C virtiofsd We deprecated the C virtiofsd in commit 34deee7b6a1418f3d62a in v7.0 in favour of the Rust implementation at https://gitlab.com/virtio-fs/virtiofsd since then, the Rust version has had more development and has held up well. It's time to say goodbye to the C version that got us going. Signed-off-by: Dr. David Alan Gilbert -------- Dr. David Alan Gilbert (4): virtiofsd: Remove test virtiofsd: Remove build and docs glue virtiofsd: Remove source virtiofsd: Swing deprecated message to removed-features MAINTAINERS|2 - docs/about/deprecated.rst | 18 - docs/about/removed-features.rst| 13 + docs/conf.py |4 - docs/meson.build |1 - docs/tools/index.rst |1 - docs/tools/virtiofsd.rst | 403 -- meson.build|1 - meson_options.txt |2 - scripts/ci/org.centos/stream/8/x86_64/configure|2 - scripts/ci/org.centos/stream/8/x86_64/test-avocado |7 - scripts/coverity-scan/COMPONENTS.md|3 - scripts/meson-buildoptions.sh |3 - tests/avocado/virtiofs_submounts.py| 217 - tools/meson.build | 13 - tools/virtiofsd/50-qemu-virtiofsd.json.in |5 - tools/virtiofsd/buffer.c | 350 -- tools/virtiofsd/fuse_common.h | 837 tools/virtiofsd/fuse_i.h | 107 - tools/virtiofsd/fuse_log.c | 40 - tools/virtiofsd/fuse_log.h | 75 - tools/virtiofsd/fuse_lowlevel.c| 2732 tools/virtiofsd/fuse_lowlevel.h| 1988 - tools/virtiofsd/fuse_misc.h| 59 - tools/virtiofsd/fuse_opt.c | 446 -- tools/virtiofsd/fuse_opt.h | 272 -- tools/virtiofsd/fuse_signals.c | 93 - tools/virtiofsd/fuse_virtio.c | 1081 - tools/virtiofsd/fuse_virtio.h | 33 - tools/virtiofsd/helper.c | 409 -- tools/virtiofsd/meson.build| 18 - tools/virtiofsd/passthrough_helpers.h | 51 - tools/virtiofsd/passthrough_ll.c | 4521 tools/virtiofsd/passthrough_seccomp.c | 182 - tools/virtiofsd/passthrough_seccomp.h | 14 - 35 files changed, 13 insertions(+), 13990 deletions(-) delete mode 100644 docs/tools/virtiofsd.rst delete mode 100644 tests/avocado/virtiofs_submounts.py delete mode 100644 tools/virtiofsd/50-qemu-virtiofsd.json.in delete mode 100644 tools/virtiofsd/buffer.c delete mode 100644 tools/virtiofsd/fuse_common.h delete mode 100644 tools/virtiofsd/fuse_i.h delete mode 100644 tools/virtiofsd/fuse_log.c delete mode 100644 tools/virtiofsd/fuse_log.h delete mode 100644 tools/virtiofsd/fuse_lowlevel.c delete mode 100644 tools/virtiofsd/fuse_lowlevel.h delete mode 100644 tools/virtiofsd/fuse_misc.h delete mode 100644 tools/virtiofsd/fuse_opt.c delete mode 100644 tools/virtiofsd/fuse_opt.h delete mode 100644 tools/virtiofsd/fuse_signals.c delete mode 100644 tools/virtiofsd/fuse_virtio.c delete mode 100644 tools/virtiofsd/fuse_virtio.h delete mode 100644 tools/virtiofsd/helper.c delete mode 100644 tools/virtiofsd/meson.build delete mode 100644 tools/virtiofsd/passthrough_helpers.h delete mode 100644 tools/virtiofsd/passthrough_ll.c delete mode 100644 tools/virtiofsd/passthrough_seccomp.c delete mode 100644 tools/virtiofsd/passthrough_seccomp.h
Re: [RFC PATCH v2 0/2] i386/sev: Support measured direct kernel boot on SNP
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Thu, Feb 16, 2023 at 08:49:11AM +, Dov Murik wrote: > > This RFC patch series is based on AMD's RFC upmv10-snpv3 tree [1]. > > I've seen postings of the kernel patches for SNP using the kernel > UPM support, but I don't recall ever seeing these QEMU pieces > posted for review. The code in that QEMU branch looks different > from the last posting of SNP to qemu-devel years ago. > > IMHO it would be very desirable if that QEMU UPM tree was submitted > to qemu-devel for review feedback Some of the patches in there look like they're not dependent on SNP or the UPM interface; (eg some CPU model updates). It's probably worth posting those separately so that they can be reviewed and merged and out of the way. > before requesting review of patches > that build on top of it. But at the same time it seems right for Dov to send these patches for review. Dave > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org -o-https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PATCH v2 1/4] virtiofsd: Remove test
From: "Dr. David Alan Gilbert"
Rmove the avocado test for virtiofsd, since we're about to remove
the C implementation.
Signed-off-by: Dr. David Alan Gilbert
---
.../org.centos/stream/8/x86_64/test-avocado | 7 -
tests/avocado/virtiofs_submounts.py | 217 --
2 files changed, 224 deletions(-)
delete mode 100644 tests/avocado/virtiofs_submounts.py
diff --git a/scripts/ci/org.centos/stream/8/x86_64/test-avocado
b/scripts/ci/org.centos/stream/8/x86_64/test-avocado
index 7aeecbcfb8..f403e4e7ec 100755
--- a/scripts/ci/org.centos/stream/8/x86_64/test-avocado
+++ b/scripts/ci/org.centos/stream/8/x86_64/test-avocado
@@ -14,13 +14,6 @@
# * Require machine type "x-remote":
# - tests/avocado/multiprocess.py:Multiprocess.test_multiprocess_x86_64
#
-# * Needs superuser privileges:
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_pre_virtiofsd_set_up
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_pre_launch_set_up
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_post_launch_set_up
-# -
tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_post_mount_set_up
-# - tests/avocado/virtiofs_submounts.py:VirtiofsSubmountsTest.test_two_runs
-#
# * Requires display type "egl-headless":
# - tests/avocado/virtio-gpu.py:VirtioGPUx86.test_virtio_vga_virgl
# - tests/avocado/virtio-gpu.py:VirtioGPUx86.test_vhost_user_vga_virgl
diff --git a/tests/avocado/virtiofs_submounts.py
b/tests/avocado/virtiofs_submounts.py
deleted file mode 100644
index e6dc32ffd4..00
--- a/tests/avocado/virtiofs_submounts.py
+++ /dev/null
@@ -1,217 +0,0 @@
-import logging
-import re
-import os
-import subprocess
-import time
-
-from avocado import skipUnless
-from avocado_qemu import LinuxTest, BUILD_DIR
-from avocado_qemu import has_cmds
-from avocado_qemu import run_cmd
-from avocado_qemu import wait_for_console_pattern
-from avocado.utils import ssh
-
-
-class VirtiofsSubmountsTest(LinuxTest):
-"""
-:avocado: tags=arch:x86_64
-:avocado: tags=accel:kvm
-"""
-
-def run(self, args, ignore_error=False):
-stdout, stderr, ret = run_cmd(args)
-
-if ret != 0:
-cmdline = ' '.join(args)
-if not ignore_error:
-self.fail(f'{cmdline}: Returned {ret}: {stderr}')
-else:
-self.log.warn(f'{cmdline}: Returned {ret}: {stderr}')
-
-return (stdout, stderr, ret)
-
-def set_up_shared_dir(self):
-self.shared_dir = os.path.join(self.workdir, 'virtiofs-shared')
-
-os.mkdir(self.shared_dir)
-
-self.run(('cp', self.get_data('guest.sh'),
- os.path.join(self.shared_dir, 'check.sh')))
-
-self.run(('cp', self.get_data('guest-cleanup.sh'),
- os.path.join(self.shared_dir, 'cleanup.sh')))
-
-def set_up_virtiofs(self):
-attmp = os.getenv('AVOCADO_TESTS_COMMON_TMPDIR')
-self.vfsdsock = os.path.join(attmp, 'vfsdsock')
-
-self.run(('sudo', '-n', 'rm', '-f', self.vfsdsock), ignore_error=True)
-
-self.virtiofsd = \
-subprocess.Popen(('sudo', '-n',
- 'tools/virtiofsd/virtiofsd',
- f'--socket-path={self.vfsdsock}',
- '-o', f'source={self.shared_dir}',
- '-o', 'cache=always',
- '-o', 'xattr',
- '-o', 'announce_submounts',
- '-f'),
- stdout=subprocess.DEVNULL,
- stderr=subprocess.PIPE,
- universal_newlines=True)
-
-while not os.path.exists(self.vfsdsock):
-if self.virtiofsd.poll() is not None:
-self.fail('virtiofsd exited prematurely: ' +
- self.virtiofsd.communicate()[1])
-time.sleep(0.1)
-
-self.run(('sudo', '-n', 'chmod', 'go+rw', self.vfsdsock))
-
-self.vm.add_args('-chardev',
- f'socket,id=vfsdsock,path={self.vfsdsock}',
- '-device',
- 'vhost-user-fs-pci,queue-size=1024,chardev=vfsdsock' \
- ',tag=host',
- '-object',
- 'memory-backend-file,id=mem,size=1G,' \
- 'mem-path=/dev/shm,share=on',
- '-numa',
- 'node,memdev=mem')
-
-def set_up_nested_mounts(self):
-scratch_dir = os.path.join(self.shared_dir, 'scratch')
-try:
-os.mkdir(scratch_dir)
-except FileExistsError:
-pass
-
-args = ['bash', self.get_data('host.sh'), scratch_dir]
-if self.seed:
-args += [self.seed]
-
-out, _, _ = self.run(args)
-seed
[PATCH v2 0/4] Remove C virtiofsd
From: "Dr. David Alan Gilbert" We deprecated the C virtiofsd in commit 34deee7b6a1418f3d62a in v7.0 in favour of the Rust implementation at https://gitlab.com/virtio-fs/virtiofsd since then, the Rust version has had more development and has held up well. It's time to say goodbye to the C version that got us going. v2: After comments on the v1 series, I've removed the Avocado test. Dr. David Alan Gilbert (4): virtiofsd: Remove test virtiofsd: Remove build and docs glue virtiofsd: Remove source virtiofsd: Swing deprecated message to removed-features MAINTAINERS |2 - docs/about/deprecated.rst | 18 - docs/about/removed-features.rst | 13 + docs/conf.py |4 - docs/meson.build |1 - docs/tools/index.rst |1 - docs/tools/virtiofsd.rst | 403 -- meson.build |1 - meson_options.txt |2 - .../ci/org.centos/stream/8/x86_64/configure |2 - .../org.centos/stream/8/x86_64/test-avocado |7 - scripts/coverity-scan/COMPONENTS.md |3 - scripts/meson-buildoptions.sh |3 - tests/avocado/virtiofs_submounts.py | 217 - tools/meson.build | 13 - tools/virtiofsd/50-qemu-virtiofsd.json.in |5 - tools/virtiofsd/buffer.c | 350 -- tools/virtiofsd/fuse_common.h | 837 --- tools/virtiofsd/fuse_i.h | 107 - tools/virtiofsd/fuse_log.c| 40 - tools/virtiofsd/fuse_log.h| 75 - tools/virtiofsd/fuse_lowlevel.c | 2732 -- tools/virtiofsd/fuse_lowlevel.h | 1988 tools/virtiofsd/fuse_misc.h | 59 - tools/virtiofsd/fuse_opt.c| 446 -- tools/virtiofsd/fuse_opt.h| 272 - tools/virtiofsd/fuse_signals.c| 93 - tools/virtiofsd/fuse_virtio.c | 1081 tools/virtiofsd/fuse_virtio.h | 33 - tools/virtiofsd/helper.c | 409 -- tools/virtiofsd/meson.build | 18 - tools/virtiofsd/passthrough_helpers.h | 51 - tools/virtiofsd/passthrough_ll.c | 4521 - tools/virtiofsd/passthrough_seccomp.c | 182 - tools/virtiofsd/passthrough_seccomp.h | 14 - 35 files changed, 13 insertions(+), 13990 deletions(-) delete mode 100644 docs/tools/virtiofsd.rst delete mode 100644 tests/avocado/virtiofs_submounts.py delete mode 100644 tools/virtiofsd/50-qemu-virtiofsd.json.in delete mode 100644 tools/virtiofsd/buffer.c delete mode 100644 tools/virtiofsd/fuse_common.h delete mode 100644 tools/virtiofsd/fuse_i.h delete mode 100644 tools/virtiofsd/fuse_log.c delete mode 100644 tools/virtiofsd/fuse_log.h delete mode 100644 tools/virtiofsd/fuse_lowlevel.c delete mode 100644 tools/virtiofsd/fuse_lowlevel.h delete mode 100644 tools/virtiofsd/fuse_misc.h delete mode 100644 tools/virtiofsd/fuse_opt.c delete mode 100644 tools/virtiofsd/fuse_opt.h delete mode 100644 tools/virtiofsd/fuse_signals.c delete mode 100644 tools/virtiofsd/fuse_virtio.c delete mode 100644 tools/virtiofsd/fuse_virtio.h delete mode 100644 tools/virtiofsd/helper.c delete mode 100644 tools/virtiofsd/meson.build delete mode 100644 tools/virtiofsd/passthrough_helpers.h delete mode 100644 tools/virtiofsd/passthrough_ll.c delete mode 100644 tools/virtiofsd/passthrough_seccomp.c delete mode 100644 tools/virtiofsd/passthrough_seccomp.h -- 2.39.1
[PATCH v2 2/4] virtiofsd: Remove build and docs glue
From: "Dr. David Alan Gilbert"
Remove all the virtiofsd build and docs infrastructure.
Signed-off-by: Dr. David Alan Gilbert
---
MAINTAINERS| 2 --
docs/conf.py | 4
docs/meson.build | 1 -
docs/tools/index.rst | 1 -
meson.build| 1 -
meson_options.txt | 2 --
.../ci/org.centos/stream/8/x86_64/configure| 2 --
scripts/coverity-scan/COMPONENTS.md| 3 ---
scripts/meson-buildoptions.sh | 3 ---
tools/meson.build | 13 -
tools/virtiofsd/50-qemu-virtiofsd.json.in | 5 -
tools/virtiofsd/meson.build| 18 --
12 files changed, 55 deletions(-)
delete mode 100644 tools/virtiofsd/50-qemu-virtiofsd.json.in
delete mode 100644 tools/virtiofsd/meson.build
diff --git a/MAINTAINERS b/MAINTAINERS
index 96e25f62ac..5c926e7396 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2097,10 +2097,8 @@ virtiofs
M: Dr. David Alan Gilbert
M: Stefan Hajnoczi
S: Supported
-F: tools/virtiofsd/*
F: hw/virtio/vhost-user-fs*
F: include/hw/virtio/vhost-user-fs.h
-F: docs/tools/virtiofsd.rst
L: virtio...@redhat.com
virtio-input
diff --git a/docs/conf.py b/docs/conf.py
index 73a287a4f2..00767b0e24 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -290,10 +290,6 @@
('tools/virtfs-proxy-helper', 'virtfs-proxy-helper',
'QEMU 9p virtfs proxy filesystem helper',
['M. Mohan Kumar'], 1),
-('tools/virtiofsd', 'virtiofsd',
- 'QEMU virtio-fs shared file system daemon',
- ['Stefan Hajnoczi ',
- 'Masayoshi Mizuma '], 1),
]
man_make_section_directory = False
diff --git a/docs/meson.build b/docs/meson.build
index 9136fed3b7..bbcdccce68 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -48,7 +48,6 @@ if build_docs
'qemu-storage-daemon.1': (have_tools ? 'man1' : ''),
'qemu-trace-stap.1': (stap.found() ? 'man1' : ''),
'virtfs-proxy-helper.1': (have_virtfs_proxy_helper ? 'man1' : ''),
-'virtiofsd.1': (have_virtiofsd ? 'man1' : ''),
'qemu.1': 'man1',
'qemu-block-drivers.7': 'man7',
'qemu-cpu-models.7': 'man7'
diff --git a/docs/tools/index.rst b/docs/tools/index.rst
index 2151adcf78..8e65ce0dfc 100644
--- a/docs/tools/index.rst
+++ b/docs/tools/index.rst
@@ -16,4 +16,3 @@ command line utilities and other standalone programs.
qemu-pr-helper
qemu-trace-stap
virtfs-proxy-helper
- virtiofsd
diff --git a/meson.build b/meson.build
index c626ccfa82..6508b10a05 100644
--- a/meson.build
+++ b/meson.build
@@ -3870,7 +3870,6 @@ if have_block
summary_info += {'Block whitelist (ro)':
get_option('block_drv_ro_whitelist')}
summary_info += {'Use block whitelist in tools':
get_option('block_drv_whitelist_in_tools')}
summary_info += {'VirtFS support':have_virtfs}
- summary_info += {'build virtiofs daemon': have_virtiofsd}
summary_info += {'Live block migration':
config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
summary_info += {'replication support':
config_host_data.get('CONFIG_REPLICATION')}
summary_info += {'bochs support': get_option('bochs').allowed()}
diff --git a/meson_options.txt b/meson_options.txt
index e5f199119e..954abb859b 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -270,8 +270,6 @@ option('vhost_user_blk_server', type: 'feature', value:
'auto',
description: 'build vhost-user-blk server')
option('virtfs', type: 'feature', value: 'auto',
description: 'virtio-9p support')
-option('virtiofsd', type: 'feature', value: 'auto',
- description: 'build virtiofs daemon (virtiofsd)')
option('libvduse', type: 'feature', value: 'auto',
description: 'build VDUSE Library')
option('vduse_blk_export', type: 'feature', value: 'auto',
diff --git a/scripts/ci/org.centos/stream/8/x86_64/configure
b/scripts/ci/org.centos/stream/8/x86_64/configure
index 65eacf3c56..6e8983f39c 100755
--- a/scripts/ci/org.centos/stream/8/x86_64/configure
+++ b/scripts/ci/org.centos/stream/8/x86_64/configure
@@ -138,7 +138,6 @@
--disable-vhost-vdpa \
--disable-virglrenderer \
--disable-virtfs \
---disable-virtiofsd \
--disable-vnc \
--disable-vnc-jpeg \
--disable-png \
@@ -191,7 +190,6 @@
--enable-tpm \
--enable-trace-backends=dtrace \
--enable-usb-redir \
---enable-virtiofsd \
--enable-vhost-kernel \
--enable-vhost-net \
--enable-vhost-user \
diff --git a/scripts/coverity-scan/COMPONENTS.md
b/scripts/coverity-scan/COMPONENTS.md
index 0e6ab4936e..639dcee45a 100644
--- a/scripts/coverity-scan/COMPONENTS.md
+++ b/scripts/coverity-scan/COMPONENTS.md
@@ -132,9 +132,6 @@ util
xen
~ (/qemu)?(.*/xen.*)
-virtiofsd
- ~ (/qemu)?(/tools/virtiofsd/.*)
-
(headers)
~ (/qemu)?(/include/.*)
diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-build
[PATCH v2 4/4] virtiofsd: Swing deprecated message to removed-features
From: "Dr. David Alan Gilbert" Move the deprecation message, since it's now gone. Signed-off-by: Dr. David Alan Gilbert --- docs/about/deprecated.rst | 18 -- docs/about/removed-features.rst | 13 + 2 files changed, 13 insertions(+), 18 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index da2e6fe63d..9a749b342c 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -325,24 +325,6 @@ versions, aliases will point to newer CPU model versions depending on the machine type, so management software must resolve CPU model aliases before starting a virtual machine. -Tools -- - -virtiofsd -' - -There is a new Rust implementation of ``virtiofsd`` at -``https://gitlab.com/virtio-fs/virtiofsd``; -since this is now marked stable, new development should be done on that -rather than the existing C version in the QEMU tree. -The C version will still accept fixes and patches that -are already in development for the moment, but will eventually -be deleted from this tree. -New deployments should use the Rust version, and existing systems -should consider moving to it. The command line and feature set -is very close and moving should be simple. - - QEMU guest agent diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index a17d0554d6..8b69ab1674 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -872,3 +872,16 @@ The VXHS code did not compile since v2.12.0. It was removed in 5.1. The corresponding upstream server project is no longer maintained. Users are recommended to switch to an alternative distributed block device driver such as RBD. + +Tools +- + +virtiofsd (removed in 8.0) +'' + +There is a newer Rust implementation of ``virtiofsd`` at +``https://gitlab.com/virtio-fs/virtiofsd``; this has been +stable for some time and is now widely used. +The command line and feature set is very close to the removed +C implementation. + -- 2.39.1
Re: [RFC PATCH 0/5] Deprecate/rename singlestep command line option
* Markus Armbruster (arm...@redhat.com) wrote: > Peter Maydell writes: > > > The command line option '-singlestep' and its HMP equivalent > > the 'singlestep' command are very confusingly named, because > > they have nothing to do with single-stepping the guest (either > > via the gdb stub or by emulation of guest CPU architectural > > debug facilities). What they actually do is put TCG into a > > mode where it puts only one guest instruction into each > > translation block. This is useful for some circumstances > > such as when you want the -d debug logging to be easier to > > interpret, or if you have a finicky guest binary that wants > > to see interrupts delivered at something other than the end > > of a basic block. > > > > The confusing name is made worse by the fact that our > > documentation for these is so minimal as to be useless > > for telling users what they really do. > > > > This series: > > * renames the 'singlestep' global variable to 'one_insn_per_tb' > > * Adds new '-one-insn-per-tb' command line options and a > >HMP 'one-insn-per-tb' command > > * Documents the '-singlestep' options and 'singlestep' > >HMP command as deprecated synonyms for the new ones > > > > It does not do anything about the other place where we surface > > 'singlestep', which is in the QMP StatusInfo object returned by the > > 'query-status' command. This is incorrectly documented as "true if > > VCPUs are in single-step mode" and "singlestep is enabled through > > the GDB stub", because what it's actually returning is the > > one-insn-per-tb state. > > > > Things I didn't bother with because this is only an RFC but > > will do if it turns into a non-RFC patchset: > > * test the bsd-user changes :-) > > * add text to deprecated.rst > > > > So, questions: > > > > (1) is this worth bothering with at all? We could just > > name our global variable etc better, and document what > > -singlestep actually does, and not bother with the new > > names for the options/commands. > > The feature is kind of esoteric. Rather weak excuse for not fixing bad > UI, in my opinion. Weaker still since you already did a good part of > the actual work. > > > (2) if we do do it, do we retain the old name indefinitely, > > or actively put it on the deprecate-and-drop list? > > By "the old name", you mean the CLI option name, right? > > I'd prefer deprecate and drop. > > > (3) what should we do about the HMP StatusInfo object? > > I'm not sure how we handle compatibility for HMP. > > Uh, you mean *QMP*, don't you? > > As you wrote above, StatusInfo is returned by query-status, which is a > stable interface. Changes to members therefore require the usual > deprecation grace period. We'd add a new member with a sane name, and > deprecate the old one. > > The matching HMP command is "info status". It shows member @singlestep > as " (single step mode)". Changing that is fine; HMP is not a stable > interface. Right, and similarly you don't need to keep the old 'singlestep' command around; you can just rename. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2] migration: I messed state_pending_exact/estimate
* Juan Quintela (quint...@redhat.com) wrote:
> I called the helper function from the wrong top level function.
Oops yes; as Peter says, this needs a Fixes: line, bu tother than that.
Reviewed-by: Dr. David Alan Gilbert
> This code was introduced in:
>
> commit c8df4a7aeffcb46020f610526eea621fa5b0cd47
> Author: Juan Quintela
> Date: Mon Oct 3 02:00:03 2022 +0200
>
> migration: Split save_live_pending() into state_pending_*
>
> We split the function into to:
>
> - state_pending_estimate: We estimate the remaining state size without
> stopping the machine.
>
> - state pending_exact: We calculate the exact amount of remaining
> state.
>
> Thanks to Avihai Horon for finding it.
>
> Signed-off-by: Juan Quintela
> ---
> migration/savevm.c | 50 +++---
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/migration/savevm.c b/migration/savevm.c
> index e9cf4999ad..ce181e21e1 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -1551,31 +1551,6 @@ void qemu_savevm_state_pending_estimate(uint64_t
> *res_precopy_only,
> *res_compatible = 0;
> *res_postcopy_only = 0;
>
> -QTAILQ_FOREACH(se, _state.handlers, entry) {
> -if (!se->ops || !se->ops->state_pending_exact) {
> -continue;
> -}
> -if (se->ops->is_active) {
> -if (!se->ops->is_active(se->opaque)) {
> -continue;
> -}
> -}
> -se->ops->state_pending_exact(se->opaque,
> - res_precopy_only, res_compatible,
> - res_postcopy_only);
> -}
> -}
> -
> -void qemu_savevm_state_pending_exact(uint64_t *res_precopy_only,
> - uint64_t *res_compatible,
> - uint64_t *res_postcopy_only)
> -{
> -SaveStateEntry *se;
> -
> -*res_precopy_only = 0;
> -*res_compatible = 0;
> -*res_postcopy_only = 0;
> -
> QTAILQ_FOREACH(se, _state.handlers, entry) {
> if (!se->ops || !se->ops->state_pending_estimate) {
> continue;
> @@ -1591,6 +1566,31 @@ void qemu_savevm_state_pending_exact(uint64_t
> *res_precopy_only,
> }
> }
>
> +void qemu_savevm_state_pending_exact(uint64_t *res_precopy_only,
> + uint64_t *res_compatible,
> + uint64_t *res_postcopy_only)
> +{
> +SaveStateEntry *se;
> +
> +*res_precopy_only = 0;
> +*res_compatible = 0;
> +*res_postcopy_only = 0;
> +
> +QTAILQ_FOREACH(se, _state.handlers, entry) {
> +if (!se->ops || !se->ops->state_pending_exact) {
> +continue;
> +}
> +if (se->ops->is_active) {
> +if (!se->ops->is_active(se->opaque)) {
> +continue;
> + }
> + }
> +se->ops->state_pending_exact(se->opaque,
> + res_precopy_only, res_compatible,
> + res_postcopy_only);
> +}
> +}
> +
> void qemu_savevm_state_cleanup(void)
> {
> SaveStateEntry *se;
> --
> 2.39.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] virtio-rng-pci: fix transitional migration compat for vectors
* Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> On 7/2/23 18:49, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > In bad9c5a5166fd5e3a892b7b0477cf2f4bd3a959a I fixed the virito-rng-pci
>
> Typo "virtio-rng-pci".
I've made that typo SO many times...
> > migration compatibility, but it was discovered that we also need to fix
> > the other aliases of the device for the transitional cases.
> >
> > Fixes: 9ea02e8f1 ('virtio-rng-pci: Allow setting nvectors, so we can use
> > MSI-X')
> > bz: https://bugzilla.redhat.com/show_bug.cgi?id=2162569
> > Signed-off-by: Dr. David Alan Gilbert
> > ---
> > hw/core/machine.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index b5cd42cd8c..4627b274d9 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -49,6 +49,8 @@ const size_t hw_compat_7_2_len =
> > G_N_ELEMENTS(hw_compat_7_2);
> > GlobalProperty hw_compat_7_1[] = {
> > { "virtio-device", "queue_reset", "false" },
> > { "virtio-rng-pci", "vectors", "0" },
> > +{ "virtio-rng-pci-transitional", "vectors", "0" },
> > +{ "virtio-rng-pci-non-transitional", "vectors", "0" },
>
> Ouch :(
>
> Reviewed-by: Philippe Mathieu-Daudé
Thanks!
Dave
>
> > };
> > const size_t hw_compat_7_1_len = G_N_ELEMENTS(hw_compat_7_1);
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PATCH] virtio-rng-pci: fix transitional migration compat for vectors
From: "Dr. David Alan Gilbert"
In bad9c5a5166fd5e3a892b7b0477cf2f4bd3a959a I fixed the virito-rng-pci
migration compatibility, but it was discovered that we also need to fix
the other aliases of the device for the transitional cases.
Fixes: 9ea02e8f1 ('virtio-rng-pci: Allow setting nvectors, so we can use MSI-X')
bz: https://bugzilla.redhat.com/show_bug.cgi?id=2162569
Signed-off-by: Dr. David Alan Gilbert
---
hw/core/machine.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index b5cd42cd8c..4627b274d9 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -49,6 +49,8 @@ const size_t hw_compat_7_2_len = G_N_ELEMENTS(hw_compat_7_2);
GlobalProperty hw_compat_7_1[] = {
{ "virtio-device", "queue_reset", "false" },
{ "virtio-rng-pci", "vectors", "0" },
+{ "virtio-rng-pci-transitional", "vectors", "0" },
+{ "virtio-rng-pci-non-transitional", "vectors", "0" },
};
const size_t hw_compat_7_1_len = G_N_ELEMENTS(hw_compat_7_1);
--
2.39.1
Re: [PULL 23/26] monitor: Use LOCK_GUARD macros
* Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
> Hi David
>
> On Fri, Sep 25, 2020 at 4:27 PM Dr. David Alan Gilbert (git)
> wrote:
> >
> > From: "Dr. David Alan Gilbert"
> >
> > Use the lock guard macros in monitor/misc.c - saves
> > a lot of unlocks in error paths, and the occasional goto.
> >
> > Signed-off-by: Dr. David Alan Gilbert
> > Message-Id: <20200922095741.101911-1-dgilb...@redhat.com>
> > Reviewed-by: Markus Armbruster
> > Reviewed-by: Philippe Mathieu-Daudé
> > Signed-off-by: Dr. David Alan Gilbert
> > ---
> > monitor/misc.c | 44 ++--
> > 1 file changed, 14 insertions(+), 30 deletions(-)
> >
> > diff --git a/monitor/misc.c b/monitor/misc.c
> > index 262f2bd951..6e0da0cb96 100644
> > --- a/monitor/misc.c
> > +++ b/monitor/misc.c
> > @@ -141,13 +141,13 @@ char *qmp_human_monitor_command(const char
> > *command_line, bool has_cpu_index,
> > handle_hmp_command(, command_line);
> > cur_mon = old_mon;
> >
> > -qemu_mutex_lock(_lock);
> > -if (qstring_get_length(hmp.common.outbuf) > 0) {
> > -output = g_strdup(qstring_get_str(hmp.common.outbuf));
> > -} else {
> > -output = g_strdup("");
> > +WITH_QEMU_LOCK_GUARD(_lock) {
> > +if (qstring_get_length(hmp.common.outbuf) > 0) {
> > +output = g_strdup(qstring_get_str(hmp.common.outbuf));
> > +} else {
> > +output = g_strdup("");
> > +}
> > }
> > -qemu_mutex_unlock(_lock);
> >
> > out:
> > monitor_data_destroy();
> > @@ -1248,7 +1248,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > return;
> > }
> >
> > -qemu_mutex_lock(_mon->mon_lock);
> > +QEMU_LOCK_GUARD(_mon->mon_lock);
> > QLIST_FOREACH(monfd, _mon->fds, next) {
> > if (strcmp(monfd->name, fdname) != 0) {
> > continue;
> > @@ -1256,7 +1256,6 @@ void qmp_getfd(const char *fdname, Error **errp)
> >
> > tmp_fd = monfd->fd;
> > monfd->fd = fd;
> > -qemu_mutex_unlock(_mon->mon_lock);
> > /* Make sure close() is outside critical section */
> > close(tmp_fd);
>
> The comment doesn't look true after this patch, since the lock is
> released before returning. commit 9409fc05fe2 ("monitor: protect
> mon->fds with mon_lock") introduced the lock & comment. Apparently,
> you didn't convert qmp_closefd() to LOCK_GUARD, presumably because of
> the comment. But you did it in qmp_getfd. What's the reason for that
> though, avoiding syscalls while holding the lock or am I missing
> something?
No, I think you're right!
Yeh I think the reason was to avoid the (potentially blocking) syscall
with the lock held.
Dave
> thanks
>
> > return;
> > @@ -1267,7 +1266,6 @@ void qmp_getfd(const char *fdname, Error **errp)
> > monfd->fd = fd;
> >
> > QLIST_INSERT_HEAD(_mon->fds, monfd, next);
> > -qemu_mutex_unlock(_mon->mon_lock);
> > }
> >
> > void qmp_closefd(const char *fdname, Error **errp)
> > @@ -1299,7 +1297,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname,
> > Error **errp)
> > {
> > mon_fd_t *monfd;
> >
> > -qemu_mutex_lock(>mon_lock);
> > +QEMU_LOCK_GUARD(>mon_lock);
> > QLIST_FOREACH(monfd, >fds, next) {
> > int fd;
> >
> > @@ -1313,12 +1311,10 @@ int monitor_get_fd(Monitor *mon, const char
> > *fdname, Error **errp)
> > QLIST_REMOVE(monfd, next);
> > g_free(monfd->name);
> > g_free(monfd);
> > -qemu_mutex_unlock(>mon_lock);
> >
> > return fd;
> > }
> >
> > -qemu_mutex_unlock(>mon_lock);
> > error_setg(errp, "File descriptor named '%s' has not been found",
> > fdname);
> > return -1;
> > }
> > @@ -1350,11 +1346,10 @@ void monitor_fdsets_cleanup(void)
> > MonFdset *mon_fdset;
> > MonFdset *mon_fdset_next;
> >
> > -qemu_mutex_lock(_fdsets_lock);
> > +QEMU_LOCK_GUARD(_fdsets_lock);
> > QLIST_FOREACH_SAFE(mon_fdset, _fdsets, next, mon_fdset_next) {
> > monitor_fdset_cleanup(mon_fdset);
> > }
> > -qemu_mutex_unlock(_fdsets_lock);
> > }
> >
> > AddfdInfo *qmp_add_fd(bool has_fdset_id, int64_t fdset_id, bool has_opaque,
> >
Re: [PATCH 0/3] util/userfaultfd: Support /dev/userfaultfd
* Michal Prívozník (mpriv...@redhat.com) wrote: > On 1/25/23 23:40, Peter Xu wrote: > > The new /dev/userfaultfd handle is superior to the system call with a > > better permission control and also works for a restricted seccomp > > environment. > > > > The new device was only introduced in v6.1 so we need a header update. > > > > Please have a look, thanks. > > I was wondering whether it would make sense/be possible for mgmt app > (libvirt) to pass FD for /dev/userfaultfd instead of QEMU opening it > itself. But looking into the code, libvirt would need to do that when > spawning QEMU because that's when QEMU itself initializes internal state > and queries userfaultfd caps. You also have to be careful about what the userfaultfd semantics are; I can't remember them - but if you open it in one process and pass it to another process, which processes address space are you trying to monitor? Dave > Michal > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RFC 14/21] migration: Map hugetlbfs ramblocks twice, and pre-allocate
* Peter Xu (pet...@redhat.com) wrote:
> Add a RAMBlock.host_mirror for all the hugetlbfs backed guest memories.
> It'll be used to remap the same region twice and it'll be used to service
> page faults using UFFDIO_CONTINUE.
>
> To make sure all accesses to these ranges will generate minor page faults
> not missing page faults, we need to pre-allocate the files to make sure
> page cache exist start from the beginning.
>
> Signed-off-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
> ---
> include/exec/ramblock.h | 7 +
> migration/ram.c | 59 +
> 2 files changed, 66 insertions(+)
>
> diff --git a/include/exec/ramblock.h b/include/exec/ramblock.h
> index 3f31ce1591..c76683c3c8 100644
> --- a/include/exec/ramblock.h
> +++ b/include/exec/ramblock.h
> @@ -28,6 +28,13 @@ struct RAMBlock {
> struct rcu_head rcu;
> struct MemoryRegion *mr;
> uint8_t *host;
> +/*
> + * This is only used for hugetlbfs ramblocks where doublemap is
> + * enabled. The pointer is managed by dest host migration code, and
> + * should be NULL when migration is finished. On src host, it should
> + * always be NULL.
> + */
> +uint8_t *host_mirror;
> uint8_t *colo_cache; /* For colo, VM's ram cache */
> ram_addr_t offset;
> ram_addr_t used_length;
> diff --git a/migration/ram.c b/migration/ram.c
> index 2ebf414f5f..37d7b3553a 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3879,6 +3879,57 @@ void colo_release_ram_cache(void)
> ram_state_cleanup(_state);
> }
>
> +static int migrate_hugetlb_doublemap_init(void)
> +{
> +RAMBlock *rb;
> +void *addr;
> +int ret;
> +
> +if (!migrate_hugetlb_doublemap()) {
> +return 0;
> +}
> +
> +RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
> +if (qemu_ram_is_hugetlb(rb)) {
> +/*
> + * Firstly, we remap the same ramblock into another range of
> + * virtual address, so that we can write to the pages without
> + * touching the page tables that directly mapped for the guest.
> + */
> +addr = ramblock_file_map(rb);
> +if (addr == MAP_FAILED) {
> +ret = -errno;
> +error_report("%s: Duplicate mapping for hugetlb ramblock
> '%s'"
> + "failed: %s", __func__, qemu_ram_get_idstr(rb),
> + strerror(errno));
> +return ret;
> +}
> +rb->host_mirror = addr;
> +
> +/*
> + * We need to make sure we pre-allocate the range with
> + * hugetlbfs pages before hand, so that all the page fault will
> + * be trapped as MINOR faults always, rather than MISSING
> + * faults in userfaultfd.
> + */
> +ret = qemu_madvise(addr, rb->mmap_length,
> QEMU_MADV_POPULATE_WRITE);
> +if (ret) {
> +error_report("Failed to populate hugetlb ramblock '%s': "
> + "%s", qemu_ram_get_idstr(rb), strerror(-ret));
> +return ret;
> +}
> +}
> +}
> +
> +/*
> + * When reach here, it means we've setup the mirror mapping for all the
> + * hugetlbfs pages. Hence when page fault happens, we'll be able to
> + * resolve page faults using UFFDIO_CONTINUE for hugetlbfs pages, but
> + * we'll keep using UFFDIO_COPY for anonymous pages.
> + */
> +return 0;
> +}
> +
> /**
> * ram_load_setup: Setup RAM for migration incoming side
> *
> @@ -3893,6 +3944,10 @@ static int ram_load_setup(QEMUFile *f, void *opaque)
> return -1;
> }
>
> +if (migrate_hugetlb_doublemap_init()) {
> +return -1;
> +}
> +
> xbzrle_load_setup();
> ramblock_recv_map_init();
>
> @@ -3913,6 +3968,10 @@ static int ram_load_cleanup(void *opaque)
> RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
> g_free(rb->receivedmap);
> rb->receivedmap = NULL;
> +if (rb->host_mirror) {
> +munmap(rb->host_mirror, rb->mmap_length);
> +rb->host_mirror = NULL;
> +}
> }
>
> return 0;
> --
> 2.37.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RFC 10/21] ramblock: Add ramblock_file_map()
* Peter Xu (pet...@redhat.com) wrote:
> On Tue, Jan 24, 2023 at 10:06:48AM +0000, Dr. David Alan Gilbert wrote:
> > * Peter Xu (pet...@redhat.com) wrote:
> > > Add a helper to do mmap() for a ramblock based on the cached informations.
> > >
> > > A trivial thing to mention is we need to move ramblock->fd setup to be
> > > earlier, before the ramblock_file_map() call, because it'll need to
> > > reference the fd being mapped. However that should not be a problem at
> > > all, majorly because the fd won't be freed if successful, and if it failed
> > > the fd will be freeed (or to be explicit, close()ed) by the caller.
> > >
> > > Export it - prepare to be used outside this file.
> > >
> > > Signed-off-by: Peter Xu
> > > ---
> > > include/exec/ram_addr.h | 1 +
> > > softmmu/physmem.c | 25 +
> > > 2 files changed, 18 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> > > index 0bf9cfc659..56db25009a 100644
> > > --- a/include/exec/ram_addr.h
> > > +++ b/include/exec/ram_addr.h
> > > @@ -98,6 +98,7 @@ bool ramblock_is_pmem(RAMBlock *rb);
> > >
> > > long qemu_minrampagesize(void);
> > > long qemu_maxrampagesize(void);
> > > +void *ramblock_file_map(RAMBlock *block);
> > >
> > > /**
> > > * qemu_ram_alloc_from_file,
> > > diff --git a/softmmu/physmem.c b/softmmu/physmem.c
> > > index 6096eac286..cdda7eaea5 100644
> > > --- a/softmmu/physmem.c
> > > +++ b/softmmu/physmem.c
> > > @@ -1532,17 +1532,31 @@ static int file_ram_open(const char *path,
> > > return fd;
> > > }
> > >
> > > +/* Do the mmap() for a ramblock based on information already setup */
> > > +void *ramblock_file_map(RAMBlock *block)
> > > +{
> > > +uint32_t qemu_map_flags;
> > > +
> > > +qemu_map_flags = (block->flags & RAM_READONLY) ? QEMU_MAP_READONLY :
> > > 0;
> > > +qemu_map_flags |= (block->flags & RAM_SHARED) ? QEMU_MAP_SHARED : 0;
> > > +qemu_map_flags |= (block->flags & RAM_PMEM) ? QEMU_MAP_SYNC : 0;
> > > +qemu_map_flags |= (block->flags & RAM_NORESERVE) ?
> > > QEMU_MAP_NORESERVE : 0;
> > > +
> > > +return qemu_ram_mmap(block->fd, block->mmap_length, block->mr->align,
> > > + qemu_map_flags, block->file_offset);
> > > +}
> > > +
> > > static void *file_ram_alloc(RAMBlock *block,
> > > int fd,
> > > bool truncate,
> > > off_t offset,
> > > Error **errp)
> > > {
> > > -uint32_t qemu_map_flags;
> > > void *area;
> > >
> > > /* Remember the offset just in case we'll need to map the range
> > > again */
> >
> > Note that this comment is now wrong; you need to always set that for the
> > map call.
>
> This line is added in patch 7. After this patch, a ramblock should always
> be mapped with ramblock_file_map(), so it keeps being true?
With ramblock_file_map() it's not a 'just in case' any more though is
it? This value always goes through the block-> now?
Dave
> >
> > Other than that,
> >
> > Reviewed-by: Dr. David Alan Gilbert
>
> Thanks,
>
> --
> Peter Xu
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RFC 13/21] migration: Add migration_ram_pagesize_largest()
* Peter Xu (pet...@redhat.com) wrote:
> Let it replace the old qemu_ram_pagesize_largest() just to fetch the page
> sizes using migration_ram_pagesize(), because it'll start to consider
> double mapping effect in migrations.
>
> Also don't account the ignored ramblocks as they won't be migrated.
>
> Signed-off-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
> ---
> include/exec/cpu-common.h | 1 -
> migration/migration.c | 2 +-
> migration/ram.c | 12
> migration/ram.h | 1 +
> softmmu/physmem.c | 13 -
> 5 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
> index 94452aa17f..4c394ccdfc 100644
> --- a/include/exec/cpu-common.h
> +++ b/include/exec/cpu-common.h
> @@ -96,7 +96,6 @@ int qemu_ram_get_fd(RAMBlock *rb);
>
> size_t qemu_ram_pagesize(RAMBlock *block);
> bool qemu_ram_is_hugetlb(RAMBlock *rb);
> -size_t qemu_ram_pagesize_largest(void);
>
> /**
> * cpu_address_space_init:
> diff --git a/migration/migration.c b/migration/migration.c
> index f6fe474fc3..7724e00c47 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -604,7 +604,7 @@ process_incoming_migration_co(void *opaque)
>
> assert(mis->from_src_file);
> mis->migration_incoming_co = qemu_coroutine_self();
> -mis->largest_page_size = qemu_ram_pagesize_largest();
> +mis->largest_page_size = migration_ram_pagesize_largest();
> postcopy_state_set(POSTCOPY_INCOMING_NONE);
> migrate_set_state(>state, MIGRATION_STATUS_NONE,
>MIGRATION_STATUS_ACTIVE);
> diff --git a/migration/ram.c b/migration/ram.c
> index 945c6477fd..2ebf414f5f 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -135,6 +135,18 @@ size_t migration_ram_pagesize(RAMBlock *block)
> return qemu_ram_pagesize(block);
> }
>
> +size_t migration_ram_pagesize_largest(void)
> +{
> +RAMBlock *block;
> +size_t largest = 0;
> +
> +RAMBLOCK_FOREACH_NOT_IGNORED(block) {
> +largest = MAX(largest, migration_ram_pagesize(block));
> +}
> +
> +return largest;
> +}
> +
> static void XBZRLE_cache_lock(void)
> {
> if (migrate_use_xbzrle()) {
> diff --git a/migration/ram.h b/migration/ram.h
> index 162b3e7cb8..cefe166841 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -69,6 +69,7 @@ bool ramblock_is_ignored(RAMBlock *block);
>
> int xbzrle_cache_resize(uint64_t new_size, Error **errp);
> size_t migration_ram_pagesize(RAMBlock *block);
> +size_t migration_ram_pagesize_largest(void);
> uint64_t ram_bytes_remaining(void);
> uint64_t ram_bytes_total(void);
> void mig_throttle_counter_reset(void);
> diff --git a/softmmu/physmem.c b/softmmu/physmem.c
> index cdda7eaea5..536c204811 100644
> --- a/softmmu/physmem.c
> +++ b/softmmu/physmem.c
> @@ -1813,19 +1813,6 @@ bool qemu_ram_is_hugetlb(RAMBlock *rb)
> return rb->page_size > qemu_real_host_page_size();
> }
>
> -/* Returns the largest size of page in use */
> -size_t qemu_ram_pagesize_largest(void)
> -{
> -RAMBlock *block;
> -size_t largest = 0;
> -
> - RAMBLOCK_FOREACH(block) {
> -largest = MAX(largest, qemu_ram_pagesize(block));
> -}
> -
> -return largest;
> -}
> -
> static int memory_try_enable_merging(void *addr, size_t len)
> {
> if (!machine_mem_merge(current_machine)) {
> --
> 2.37.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH RFC 12/21] migration: Introduce page size for-migration-only
*rb, uint64_t
> offset)
> int postcopy_place_page(MigrationIncomingState *mis, void *host, void *from,
> RAMBlock *rb)
> {
> -size_t pagesize = qemu_ram_pagesize(rb);
> +size_t pagesize = migration_ram_pagesize(rb);
>
> /* copy also acks to the kernel waking the stalled thread up
> * TODO: We can inhibit that ack and only do it if it was requested
> @@ -1308,7 +1310,7 @@ int postcopy_place_page(MigrationIncomingState *mis,
> void *host, void *from,
> int postcopy_place_page_zero(MigrationIncomingState *mis, void *host,
> RAMBlock *rb)
> {
> -size_t pagesize = qemu_ram_pagesize(rb);
> +size_t pagesize = migration_ram_pagesize(rb);
> trace_postcopy_place_page_zero(host);
>
> /* Normal RAMBlocks can zero a page using UFFDIO_ZEROPAGE
> diff --git a/migration/ram.c b/migration/ram.c
> index 334309f1c6..945c6477fd 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -121,6 +121,20 @@ static struct {
> uint8_t *decoded_buf;
> } XBZRLE;
>
> +/* Get the page size we should use for migration purpose. */
> +size_t migration_ram_pagesize(RAMBlock *block)
> +{
> +/*
> + * When hugetlb doublemap is enabled, we should always use the smallest
> + * page for migration.
> + */
> +if (migrate_hugetlb_doublemap()) {
> +return qemu_real_host_page_size();
> +}
> +
> +return qemu_ram_pagesize(block);
> +}
> +
> static void XBZRLE_cache_lock(void)
> {
> if (migrate_use_xbzrle()) {
> @@ -1049,7 +1063,7 @@ bool ramblock_page_is_discarded(RAMBlock *rb,
> ram_addr_t start)
> MemoryRegionSection section = {
> .mr = rb->mr,
> .offset_within_region = start,
> -.size = int128_make64(qemu_ram_pagesize(rb)),
> +.size = int128_make64(migration_ram_pagesize(rb)),
> };
>
> return !ram_discard_manager_is_populated(rdm, );
> @@ -2152,7 +2166,7 @@ int ram_save_queue_pages(const char *rbname, ram_addr_t
> start, ram_addr_t len)
> */
> if (postcopy_preempt_active()) {
> ram_addr_t page_start = start >> TARGET_PAGE_BITS;
> -size_t page_size = qemu_ram_pagesize(ramblock);
> +size_t page_size = migration_ram_pagesize(ramblock);
> PageSearchStatus *pss = _state->pss[RAM_CHANNEL_POSTCOPY];
> int ret = 0;
>
> @@ -2316,7 +2330,7 @@ static int ram_save_target_page(RAMState *rs,
> PageSearchStatus *pss)
> static void pss_host_page_prepare(PageSearchStatus *pss)
> {
> /* How many guest pages are there in one host page? */
> -size_t guest_pfns = qemu_ram_pagesize(pss->block) >> TARGET_PAGE_BITS;
> +size_t guest_pfns = migration_ram_pagesize(pss->block) >>
> TARGET_PAGE_BITS;
>
> pss->host_page_sending = true;
> pss->host_page_start = ROUND_DOWN(pss->page, guest_pfns);
> @@ -2425,7 +2439,7 @@ static int ram_save_host_page(RAMState *rs,
> PageSearchStatus *pss)
> bool page_dirty, preempt_active = postcopy_preempt_active();
> int tmppages, pages = 0;
> size_t pagesize_bits =
> -qemu_ram_pagesize(pss->block) >> TARGET_PAGE_BITS;
> +migration_ram_pagesize(pss->block) >> TARGET_PAGE_BITS;
> unsigned long start_page = pss->page;
> int res;
>
> @@ -3518,7 +3532,7 @@ static void *host_page_from_ram_block_offset(RAMBlock
> *block,
> {
> /* Note: Explicitly no check against offset_in_ramblock(). */
> return (void *)QEMU_ALIGN_DOWN((uintptr_t)(block->host + offset),
> - block->page_size);
> + migration_ram_pagesize(block));
> }
>
> static ram_addr_t host_page_offset_from_ram_block_offset(RAMBlock *block,
> @@ -3970,7 +3984,8 @@ int ram_load_postcopy(QEMUFile *f, int channel)
> break;
> }
> tmp_page->target_pages++;
> -matches_target_page_size = block->page_size == TARGET_PAGE_SIZE;
> +matches_target_page_size =
> +migration_ram_pagesize(block) == TARGET_PAGE_SIZE;
> /*
> * Postcopy requires that we place whole host pages atomically;
> * these may be huge pages for RAMBlocks that are backed by
Hmm do you really want this change?
Dave
> @@ -4005,7 +4020,7 @@ int ram_load_postcopy(QEMUFile *f, int channel)
> * page
> */
> if (tmp_page->target_pages ==
> -(block->page_size / TARGET_PAGE_SIZE)) {
> +(migration_ram_pagesize(block) / TARGET_PAGE_SIZE)) {
> place_needed = true;
> }
> place_source = tmp_page->tmp_huge_page;
> diff --git a/migration/ram.h b/migration/ram.h
> index 81cbb0947c..162b3e7cb8 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -68,6 +68,7 @@ bool ramblock_is_ignored(RAMBlock *block);
> if (!qemu_ram_is_migratable(block)) {} else
>
> int xbzrle_cache_resize(uint64_t new_size, Error **errp);
> +size_t migration_ram_pagesize(RAMBlock *block);
> uint64_t ram_bytes_remaining(void);
> uint64_t ram_bytes_total(void);
> void mig_throttle_counter_reset(void);
> --
> 2.37.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
