Re: Artificially target-dependend compiles
Paolo Bonzini writes: > On 11/5/21 14:45, Markus Armbruster wrote: >> Moving these definitions to machine-target.json moves the generated C >> from qapi/qapi-*-machine.[ch] to qapi/qapi-*-machine-target.[ch], where >> CONFIG_ACPI_VMGENID is okay. It also makes qmp_query_vm_generation_id() >> target-dependent: it needs qapi/qapi-commands-machine-target.h. > > If I understand correctly, the problem that > qapi-commands-machine-target.h is target-dependent, because it uses > "#ifdef CONFIG_ACPI_VMGENID" around the prototype? Around the prototype and struct GuidInfo. > On one hand, the "#ifdef" is unnecessary: the prototype does not > depend on anything target-specific. Removing it will avoid the > target-dependence. On the other hand, the "#ifdef" has a defensive > purpose, in that an unnecessary definition (such as the one currently > in the stub) will fail due to the implicit definition of > qmp_query_vm_generation_id(). Also, it immediately flags uses of qmp_query_vm_generation_id() and struct GuidInfo. Without it, the linker still catches most, but not all uses. >> Have you seen similar artificial target-dependence elsewhere? > > I can't think of a specific example, but it does ring some bells. I just ran into an instance that may be clearer. The "rocker" device is target-independent (hw/net/meson.build adds it to softmmu_ss), but linked only for selected targets (hw/net/Kconfig has depends on PCI && MSI_NONBROKEN). This makes our build machinery put CONFIG_ROCKER in $TARGET-softmmu-config-devices.h, and poison it in config-poison.h. Feels uncalled for.
Re: [PATCH] target/ppc, hw/ppc: Change maintainers
Thank you and Greg and Red Hat for all the years of service supporting qemu-ppc in the community. IBM will shoulder this responsibility now. In term of the MAINTAINERS file: S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. The PPC entries have a 'Maintained' status. You say "IBM will shoulder this responsibility", does that mean the entries will be 'Supported' as in "someone paid to look after them"? Yes. It's appropriate to change the PPC entries of this patch to "Supported" now. Good point, I've adjusted that. "Supported" would be setting the expectations too high. It is an extra activity among what we are already dealing with. Please leave it to "Maintained". Thanks, C.
Re: [PATCH] target/ppc, hw/ppc: Change maintainers
On Sat, Nov 06, 2021 at 09:28:54AM +0100, Cédric Le Goater wrote: > > > > > Thank you and Greg and Red Hat for all the years of service supporting > > > > > qemu-ppc in the community. IBM will shoulder this responsibility now. > > > > > > > > In term of the MAINTAINERS file: > > > > > > > > S: Status, one of the following: > > > > Supported: Someone is actually paid to look after this. > > > > Maintained: Someone actually looks after it. > > > > > > > > The PPC entries have a 'Maintained' status. You say "IBM will shoulder > > > > this responsibility", does that mean the entries will be 'Supported' > > > > as in "someone paid to look after them"? > > > > > > Yes. It's appropriate to change the PPC entries of this patch to > > > "Supported" > > > now. > > > > Good point, I've adjusted that. > > "Supported" would be setting the expectations too high. It is an extra > activity among what we are already dealing with. Please leave it to > "Maintained". Fair enough, reverted. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
[PATCH] tests/avocado: Remove p7zip binary availability check
The single use of the 7z binary has been removed in commit a30e114f3 ("tests/acceptance: remove Armbian 19.11.3 test for orangepi-pc"), we don't need to check for this binary availability anymore. Signed-off-by: Philippe Mathieu-Daudé --- Based-on: <20211105155354.154864-1-willi...@redhat.com> --- tests/avocado/boot_linux_console.py | 7 --- 1 file changed, 7 deletions(-) diff --git a/tests/avocado/boot_linux_console.py b/tests/avocado/boot_linux_console.py index 4ed01ed7893..9c618d4809f 100644 --- a/tests/avocado/boot_linux_console.py +++ b/tests/avocado/boot_linux_console.py @@ -22,13 +22,6 @@ from avocado_qemu import wait_for_console_pattern from avocado.utils import process from avocado.utils import archive -from avocado.utils.path import find_command, CmdNotFoundError - -P7ZIP_AVAILABLE = True -try: -find_command('7z') -except CmdNotFoundError: -P7ZIP_AVAILABLE = False """ Round up to next power of 2 -- 2.31.1
Re: [PATCH] target/ppc, hw/ppc: Change maintainers
On 11/5/21 21:05, Daniel Henrique Barboza wrote: > On 11/5/21 16:16, Philippe Mathieu-Daudé wrote: >> Hi Daniel, >> >> On 11/5/21 10:48, Daniel Henrique Barboza wrote: >>> On 11/5/21 00:46, David Gibson wrote: As our day jobs and interests have moved onto other things, Greg and I have been struggling to keep on top of maintainership of target/ppc and associated pieces like the pseries and powernv machine types, with their platform specific devices. We've therefore discussed and plan to transfer maintainership to Cédric Le Goater (primary) and Daniel Henrique Barboza (backup). Cédric and Daniel have been actively contributing to the area for some time, and they're supported in this by their current employer, IBM, who has an obvious interest in the platform. >>> >>> Thank you and Greg and Red Hat for all the years of service supporting >>> qemu-ppc in the community. IBM will shoulder this responsibility now. >> >> In term of the MAINTAINERS file: >> >> S: Status, one of the following: >> Supported: Someone is actually paid to look after this. >> Maintained: Someone actually looks after it. >> >> The PPC entries have a 'Maintained' status. You say "IBM will shoulder >> this responsibility", does that mean the entries will be 'Supported' >> as in "someone paid to look after them"? > > Yes. It's appropriate to change the PPC entries of this patch to > "Supported" > now. This is a great news :) >> I wonder because both Cédric and you have some commits with an IBM >> email, but both are registering a non-IBM email as contact. I don't >> mind the email technical detail, but I am curious about the status >> and expectations. > > I had problems using IBM corporate email with mailing lists in the past, > and started using this gmail account instead. I believe Cedric has a > similar sob story. > > FWIW the contrib/gitdm/group-map-ibm file has both our emails there to > indicate that we're IBM contributors. OK this is how I understood it first then. Thanks for the clarification. Regards, Phil.
Re: [PATCH] target/ppc, hw/ppc: Change maintainers
On 11/6/21 00:00, Cédric Le Goater wrote: >> In term of the MAINTAINERS file: >> >> S: Status, one of the following: >> Supported: Someone is actually paid to look after this. >> Maintained: Someone actually looks after it. >> >> The PPC entries have a 'Maintained' status. You say "IBM will shoulder >> this responsibility", does that mean the entries will be 'Supported' >> as in "someone paid to look after them"? >> I wonder because both Cédric and you have some commits with an IBM >> email, but both are registering a non-IBM email as contact. > > Lotus Notes was not designed for patch communication. You don't want > me to send patches with it I assure you :) > >> I don't >> mind the email technical detail, but I am curious about the status >> and expectations. > > We have other IBM commitments. IBM is willing to share some/most of > our time for QEMU-PPC maintenance. > > What we are going do will depend on inputs really. We have pseries > and KVM in focus because there is still business using the software > stack. TCG is extremely useful for pseries and powernv. We clearly > want to keep that running and improve it. Some parts have been barely > touched (and probably used) in the last 15 years. I think we should > drop some support to modernize the useful parts and ease maintenance. Here let me recommend the ant work approach I'm doing for MIPS. Instead of dropping ISA extensions, I'm splitting them in various compile units, that way 1/ we can chose to build without them and 2/ sub-maintainers can maintain them separately. Having a finer grained MAINTAINERS entries allow to filter-out/in and reduce reviewers pressure.
Re: Qemu and ARM secure state.
So, I am trying to understand: Contrary to what I said, In my case the SMC instruction is not really a "no-op" as it sets R0 to -1 (0x) to indicate an unknown PSCI service (by the Qemu internal PSCI handler). With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3 section 5.2" commit, once a processor/platform configure things to have PSCI requests handled by Qemu code (with "psci-conduit" attribute set to QEMU_PSCI_CONDUIT_SMC for example), then any exception raised by an "SMC" instruction will be only handled by the Qemu internal code and will no call the monitor related code in the guest/OS application. This seems to be why my SMC monitor handler is not called anymore in my case. As my i.MX6UL is a mono-processor platform I don't really need to set the "psci-conduit" attribute (which really makes sense when you have a cluster of 2 or more cores I guess). As a matter of fact if I remove the "psci-conduit" attribute setting from the i.MX6UL processor file, my application is working again on main/latest. But this still raises the question to know if the current behavior for processors with "psci-conduit" set to SMC or HVC is correct. For example an i.MX7 based platform (with up to 4 cortex A7 cores) would not be able to trigger OS SMC handler as the exception would be entirely processed by the Qemu internal code (with CR generally set to -1 in R0 to indicate unknown PSCI request). Is there something I am missing? Regards JC Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit : Le 04/11/2021 à 12:11, Peter Maydell a écrit : On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS wrote: I have a little application that is designed to work on the i.MX6UL processor. I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu. This application used to work "flawlessly" on Qemu 5.0.50 and is working on Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu). But when I try to run the exact same command line on a Qemu version I compile myself from main/latest of github (Qemu 6.1.50), my application fails to start. So a little background: My application expects to start in "secure" state and supervisor mode (which is the default state of i.MX6UL when booting barebone [without u-boot]). >From this state the application tries to get to "non secure" / hypervisor mode which imply going to the "secure" / monitor state before being able to drop to "non secure" / hypervisor. To do so is runs a "smc 0" operand (from "secure" / supervisor). This "smc" instruction is processed "as expected" by Qemu 5.0.50 and Qemu 6.0.0 (getting to "secure" / monitor mode) but on Qemu 6.1.50 (latest from github) it is as if the smc operand was a no-op. It doesn't trigger any exception and the processor just get to the next instruction after the "smc" instruction. So I am a bit puzzled. Is there something that changed in Qemu (since Qemu 6.0.0) when it comes to the "secure" world/state? Is there some additional command line parameters to use (I search in the documentation but without luck) to get secure world behavior ? Is it necessary to "adapt" the emulated platform (i.MX6UL/mcimx6ul-evk) in some way (it looks like the "virt" machine with "secure=on" does work for arm platform)? Could you try doing a bisect to find the QEMU commit that caused your guest to stop working ? OK, I did the bisect and the commit that break the i.MX6UL behavior for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4 (arm: tcg: Adhere to SMCCC 1.3 section 5.2). Before it the SMC instruction would trigger a monitor exception. After it the SMC instruction is acting like a no-op. Thanks JC thanks -- PMM
Emulation of solo key
Hello Team, I really need your suggestions on how I should proceed to build a Solo key emulator ? Since I am new to QEMU , I would like to know how I should do planing before getting into technical of QEMU Please find all information about solo key below: Docs: https://docs.solokeys.io/solo/building/ Firmware: https://github.com/solokeys/solo/ Hardware: https://github.com/solokeys/solo-hw -- Best Regards, Niraj
[PATCH] hw/timer/etraxfs_timer: Add vmstate for ETRAX timers
Add the vmstate for the ETRAX timers. This is in theory a migration compatibility break for the 'AXIS devboard 88' CRIS machine. Signed-off-by: Philippe Mathieu-Daudé --- hw/timer/etraxfs_timer.c | 34 +- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/hw/timer/etraxfs_timer.c b/hw/timer/etraxfs_timer.c index 4ba662190de..139e5b86a44 100644 --- a/hw/timer/etraxfs_timer.c +++ b/hw/timer/etraxfs_timer.c @@ -26,6 +26,7 @@ #include "hw/sysbus.h" #include "sysemu/reset.h" #include "sysemu/runstate.h" +#include "migration/vmstate.h" #include "qemu/module.h" #include "qemu/timer.h" #include "hw/irq.h" @@ -64,7 +65,7 @@ struct ETRAXTimerState { ptimer_state *ptimer_t1; ptimer_state *ptimer_wd; -int wd_hits; +uint32_t wd_hits; /* Control registers. */ uint32_t rw_tmr0_div; @@ -83,6 +84,36 @@ struct ETRAXTimerState { uint32_t r_masked_intr; }; +static const VMStateDescription vmstate_etraxfs = { +.name = "etraxfs", +.version_id = 0, +.minimum_version_id = 0, +.fields = (VMStateField[]) { +VMSTATE_PTIMER(ptimer_t0, ETRAXTimerState), +VMSTATE_PTIMER(ptimer_t1, ETRAXTimerState), +VMSTATE_PTIMER(ptimer_wd, ETRAXTimerState), + +VMSTATE_UINT32(wd_hits, ETRAXTimerState), + +VMSTATE_UINT32(rw_tmr0_div, ETRAXTimerState), +VMSTATE_UINT32(r_tmr0_data, ETRAXTimerState), +VMSTATE_UINT32(rw_tmr0_ctrl, ETRAXTimerState), + +VMSTATE_UINT32(rw_tmr1_div, ETRAXTimerState), +VMSTATE_UINT32(r_tmr1_data, ETRAXTimerState), +VMSTATE_UINT32(rw_tmr1_ctrl, ETRAXTimerState), + +VMSTATE_UINT32(rw_wd_ctrl, ETRAXTimerState), + +VMSTATE_UINT32(rw_intr_mask, ETRAXTimerState), +VMSTATE_UINT32(rw_ack_intr, ETRAXTimerState), +VMSTATE_UINT32(r_intr, ETRAXTimerState), +VMSTATE_UINT32(r_masked_intr, ETRAXTimerState), + +VMSTATE_END_OF_LIST() +} +}; + static uint64_t timer_read(void *opaque, hwaddr addr, unsigned int size) { @@ -357,6 +388,7 @@ static void etraxfs_timer_class_init(ObjectClass *klass, void *data) ResettableClass *rc = RESETTABLE_CLASS(klass); dc->realize = etraxfs_timer_realize; +dc->vmsd = &vmstate_etraxfs; rc->phases.enter = etraxfs_timer_reset_enter; rc->phases.hold = etraxfs_timer_reset_hold; } -- 2.31.1
[PATCH v2] tcg: Remove TCI experimental status
The following commits (released in v6.0.0) made raised the quality of the TCI backend to the other TCG architectures, thus is is not considerated experimental anymore: - c6fbea47664..2f74f45e32b - dc09f047edd..9e9acb7b348 - b6139eb0578..2fc6f16ca5e - dbcbda2cd84..5e8892db93f Signed-off-by: Philippe Mathieu-Daudé --- v2: - rebase - precise sysemu/user (Richard) Supersedes: <20210920062306.2723797-1-f4...@amsat.org> --- docs/about/build-platforms.rst | 10 ++ meson.build| 4 ++-- meson_options.txt | 2 +- scripts/meson-buildoptions.sh | 3 +-- 4 files changed, 10 insertions(+), 9 deletions(-) diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst index bcb15497213..c29a4b8fe64 100644 --- a/docs/about/build-platforms.rst +++ b/docs/about/build-platforms.rst @@ -54,10 +54,12 @@ Those hosts are officially supported, with various accelerators: * - x86 - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen -Other host architectures are not supported. It is possible to build QEMU on an -unsupported host architecture using the configure ``--enable-tcg-interpreter`` -option to enable the experimental TCI support, but note that this is very slow -and is not recommended. +Other host architectures are not supported. It is possible to build QEMU system +emulation on an unsupported host architecture using the configure +``--enable-tcg-interpreter`` option to enable the TCI support, but note that +this is very slow and is not recommended for normal use. QEMU user emulation +requires host-specific support for signal handling, therefore TCI won't help +on unsupported host architectures. Non-supported architectures may be removed in the future following the :ref:`deprecation process`. diff --git a/meson.build b/meson.build index 47df10afc21..16de7103d69 100644 --- a/meson.build +++ b/meson.build @@ -331,7 +331,7 @@ if not get_option('tcg').disabled() if cpu not in supported_cpus if get_option('tcg_interpreter') - warning('Unsupported CPU @0@, will use TCG with TCI (experimental and slow)'.format(cpu)) + warning('Unsupported CPU @0@, will use TCG with TCI (slow)'.format(cpu)) else error('Unsupported CPU @0@, try --enable-tcg-interpreter'.format(cpu)) endif @@ -3286,7 +3286,7 @@ summary_info += {'TCG support': config_all.has_key('CONFIG_TCG')} if config_all.has_key('CONFIG_TCG') if get_option('tcg_interpreter') -summary_info += {'TCG backend': 'TCI (TCG with bytecode interpreter, experimental and slow)'} +summary_info += {'TCG backend': 'TCI (TCG with bytecode interpreter, slow)'} else summary_info += {'TCG backend': 'native (@0@)'.format(cpu)} endif diff --git a/meson_options.txt b/meson_options.txt index e740dce2a51..411952bc91a 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -59,7 +59,7 @@ option('xen_pci_passthrough', type: 'feature', value: 'auto', option('tcg', type: 'feature', value: 'auto', description: 'TCG support') option('tcg_interpreter', type: 'boolean', value: false, - description: 'TCG with bytecode interpreter (experimental and slow)') + description: 'TCG with bytecode interpreter (slow)') option('cfi', type: 'boolean', value: 'false', description: 'Control-Flow Integrity (CFI)') option('cfi_debug', type: 'boolean', value: 'false', diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh index 55b8a785600..45e1f2e20da 100644 --- a/scripts/meson-buildoptions.sh +++ b/scripts/meson-buildoptions.sh @@ -13,8 +13,7 @@ meson_options_help() { printf "%s\n" ' jemalloc/system/tcmalloc)' printf "%s\n" ' --enable-slirp[=CHOICE] Whether and how to find the slirp library' printf "%s\n" ' (choices: auto/disabled/enabled/internal/system)' - printf "%s\n" ' --enable-tcg-interpreter TCG with bytecode interpreter (experimental and' - printf "%s\n" ' slow)' + printf "%s\n" ' --enable-tcg-interpreter TCG with bytecode interpreter (slow)' printf "%s\n" ' --enable-trace-backends=CHOICE' printf "%s\n" ' Set available tracing backends [log] (choices:' printf "%s\n" ' dtrace/ftrace/log/nop/simple/syslog/ust)' -- 2.31.1
Lei: a new tool for filtering patch series
Hi, lore.kernel.org has been archiving qemu-devel for some time. You can use b4 (https://pypi.org/project/b4/) to easily apply patch series. Now there is a new tool called lei that could be of interest to the QEMU community. lei let's you query the mailing list for patch series that match queries like specific filenames or functions touched by a patch. It keeps track of patch series that you've already downloaded so you can see just the new stuff. Instead of adding "R:" entries to the MAINTAINERS file in qemu.git you can now do that locally using lei. I haven't tried it yet but it seems like a useful tool! https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started Stefan
Re: [PATCH] docs: fix qemu incorrect tag
huang...@chinatelecom.cn wrote: > From: Hyman Huang(黄勇) > > The last modification of the patchset may be 2 month before > merging dirtyrate implementation, it used the wrong tag, so > fix with 6.2. > > Signed-off-by: Hyman Huang(黄勇) Reviewed-by: Juan Quintela queued.
Re: [PATCH v7 0/2] memory: Have 'info mtree' remove duplicated Address Space information
Ping? On 9/5/21 01:10, Philippe Mathieu-Daudé wrote: > Series fully reviewed. > > Follow Peter Maydell suggestions: > - Split mtree_info() as mtree_info_flatview() + mtree_info_as() > - Remove duplicated Address Space information > > Since v6: > - Added missing vertical whitespace (rth) > - Added rth's R-b > > Since v5: > - Fixed messed up during v3->v4 (peterx) > . Restore format > . Remove unused 'int counter' > > Since v4: > - Merged patches 1 & 2 (David) > - Remove unnecessary return void (David) > - Added David R-b > > Since v3: > - Fix typos > - Split mtree_info_flatview() + mtree_info_as() first > - Rebased last patch keeping Peter's R-b tag > > Since v2: > - Removed unused AddressSpaceInfo::counter > > Since v1: > - List AS similarly to 'info mtree -f' (peterx) > > checkpatch warning (81 chars): > > WARNING: line over 80 characters > #86: FILE: softmmu/memory.c:3359: > + address_space_compare_name); > > Philippe Mathieu-Daudé (2): > memory: Split mtree_info() as mtree_info_flatview() + mtree_info_as() > memory: Have 'info mtree' remove duplicated Address Space information > > softmmu/memory.c | 150 ++- > 1 file changed, 108 insertions(+), 42 deletions(-) >
[PATCH v2] linux-user: Mark cpu_loop() with noreturn attribute
cpu_loop() never exits, so mark it with QEMU_NORETURN. Reviewed-by: Richard Henderson Reviewed-By: Warner Losh Reviewed-by: Bin Meng Signed-off-by: Philippe Mathieu-Daudé --- v2: - rebased - restricted to linux-user Supersedes: <20210905000429.1097336-1-f4...@amsat.org> --- linux-user/user-internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/linux-user/user-internals.h b/linux-user/user-internals.h index 661612a088b..c7ad00268af 100644 --- a/linux-user/user-internals.h +++ b/linux-user/user-internals.h @@ -65,7 +65,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg5, abi_long arg6, abi_long arg7, abi_long arg8); extern __thread CPUState *thread_cpu; -void cpu_loop(CPUArchState *env); +void QEMU_NORETURN cpu_loop(CPUArchState *env); const char *target_strerror(int err); int get_osversion(void); void init_qemu_uname_release(void); -- 2.31.1
Re: [PULL 07/20] migration/dirtyrate: implement dirty-ring dirtyrate calculation
Philippe Mathieu-Daudé wrote: > Hi Juan, > > On 11/1/21 23:08, Juan Quintela wrote: >> From: Hyman Huang(黄勇) >> >> use dirty ring feature to implement dirtyrate calculation. >> >> introduce mode option in qmp calc_dirty_rate to specify what >> method should be used when calculating dirtyrate, either >> page-sampling or dirty-ring should be passed. >> >> introduce "dirty_ring:-r" option in hmp calc_dirty_rate to >> indicate dirty ring method should be used for calculation. >> >> Signed-off-by: Hyman Huang(黄勇) > > Just noticing in the git history some commits from your > pull request have the author name (from + S-o-b) mojibaked. Didn't knew the term. I noticed that after the fact. Still have to debug *why* my setup decided to break some of the patches and not the others. Obviosly, I have no clue about how to write/read/whatever anything that is not latin1, so if something breaks, I got in a difficult place O:-) Thanks, Juan. >> <7db445109bd18125ce8ec86816d14f6ab5de6a7d.1624040308.git.huang...@chinatelecom.cn> >> Reviewed-by: Peter Xu >> Reviewed-by: Juan Quintela >> Signed-off-by: Juan Quintela >> --- >> qapi/migration.json| 16 +++- >> migration/dirtyrate.c | 208 +++-- >> hmp-commands.hx| 7 +- >> migration/trace-events | 2 + >> 4 files changed, 218 insertions(+), 15 deletions(-)
Re: [PATCH v4 1/2] vhost: Rename last_index to vq_index_end
Eugenio Pérez wrote: > The doc of this field pointed out that last_index is the last vq index. > This is misleading, since it's actually one past the end of the vqs. > > Renaming and modifying comment. > > Signed-off-by: Eugenio Pérez Reviewed-by: Juan Quintela
Re: Qemu and ARM secure state.
So it seems that what is needed is a way to choose on the command line if we want to enable the Qemu built-in PSCI implementation (because we are booting linux for example) or if we really want a bare metal processor (because we are booting a trustedOS like optee). The "virt" platform allows to dynamically choose one or the other. Other platforms seems to need the same feature. JC Le 06/11/2021 à 11:04, Jean-Christophe DUBOIS a écrit : So, I am trying to understand: Contrary to what I said, In my case the SMC instruction is not really a "no-op" as it sets R0 to -1 (0x) to indicate an unknown PSCI service (by the Qemu internal PSCI handler). With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3 section 5.2" commit, once a processor/platform configure things to have PSCI requests handled by Qemu code (with "psci-conduit" attribute set to QEMU_PSCI_CONDUIT_SMC for example), then any exception raised by an "SMC" instruction will be only handled by the Qemu internal code and will no call the monitor related code in the guest/OS application. This seems to be why my SMC monitor handler is not called anymore in my case. As my i.MX6UL is a mono-processor platform I don't really need to set the "psci-conduit" attribute (which really makes sense when you have a cluster of 2 or more cores I guess). As a matter of fact if I remove the "psci-conduit" attribute setting from the i.MX6UL processor file, my application is working again on main/latest. But this still raises the question to know if the current behavior for processors with "psci-conduit" set to SMC or HVC is correct. For example an i.MX7 based platform (with up to 4 cortex A7 cores) would not be able to trigger OS SMC handler as the exception would be entirely processed by the Qemu internal code (with CR generally set to -1 in R0 to indicate unknown PSCI request). Is there something I am missing? Regards JC Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit : Le 04/11/2021 à 12:11, Peter Maydell a écrit : On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS wrote: I have a little application that is designed to work on the i.MX6UL processor. I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu. This application used to work "flawlessly" on Qemu 5.0.50 and is working on Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu). But when I try to run the exact same command line on a Qemu version I compile myself from main/latest of github (Qemu 6.1.50), my application fails to start. So a little background: My application expects to start in "secure" state and supervisor mode (which is the default state of i.MX6UL when booting barebone [without u-boot]). >From this state the application tries to get to "non secure" / hypervisor mode which imply going to the "secure" / monitor state before being able to drop to "non secure" / hypervisor. To do so is runs a "smc 0" operand (from "secure" / supervisor). This "smc" instruction is processed "as expected" by Qemu 5.0.50 and Qemu 6.0.0 (getting to "secure" / monitor mode) but on Qemu 6.1.50 (latest from github) it is as if the smc operand was a no-op. It doesn't trigger any exception and the processor just get to the next instruction after the "smc" instruction. So I am a bit puzzled. Is there something that changed in Qemu (since Qemu 6.0.0) when it comes to the "secure" world/state? Is there some additional command line parameters to use (I search in the documentation but without luck) to get secure world behavior ? Is it necessary to "adapt" the emulated platform (i.MX6UL/mcimx6ul-evk) in some way (it looks like the "virt" machine with "secure=on" does work for arm platform)? Could you try doing a bisect to find the QEMU commit that caused your guest to stop working ? OK, I did the bisect and the commit that break the i.MX6UL behavior for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4 (arm: tcg: Adhere to SMCCC 1.3 section 5.2). Before it the SMC instruction would trigger a monitor exception. After it the SMC instruction is acting like a no-op. Thanks JC thanks -- PMM
[PATCH v4 0/1] hw/hyperv/vmbus: Is it maintained?
This is the 4th time I send this patch. Is the VMBus infrastructure used / maintained? Should we deprecate & remove? $ ./scripts/get_maintainer.pl -f hw/hyperv/vmbus.c -f include/hw/hyperv/vmbus.h get_maintainer.pl: No maintainers found Philippe Mathieu-Daudé (1): hw/hyperv/vmbus: Remove unused vmbus_load/save_req() include/hw/hyperv/vmbus.h | 3 -- hw/hyperv/vmbus.c | 59 --- 2 files changed, 62 deletions(-) -- 2.31.1
[PATCH v4 1/1] hw/hyperv/vmbus: Remove unused vmbus_load/save_req()
vmbus_save_req() and vmbus_load_req() are not used. Remove them to avoid maintaining dead code. This partially reverts commit 4dd8a7064b8a6527f99a62be11 ("vmbus: add infrastructure to save/load vmbus requests"). Signed-off-by: Philippe Mathieu-Daudé --- include/hw/hyperv/vmbus.h | 3 -- hw/hyperv/vmbus.c | 59 --- 2 files changed, 62 deletions(-) diff --git a/include/hw/hyperv/vmbus.h b/include/hw/hyperv/vmbus.h index f98bea3888d..8ea660dd8e6 100644 --- a/include/hw/hyperv/vmbus.h +++ b/include/hw/hyperv/vmbus.h @@ -223,7 +223,4 @@ int vmbus_map_sgl(VMBusChanReq *req, DMADirection dir, struct iovec *iov, void vmbus_unmap_sgl(VMBusChanReq *req, DMADirection dir, struct iovec *iov, unsigned iov_cnt, size_t accessed); -void vmbus_save_req(QEMUFile *f, VMBusChanReq *req); -void *vmbus_load_req(QEMUFile *f, VMBusDevice *dev, uint32_t size); - #endif diff --git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.c index dbce3b35fba..78c19caf5f7 100644 --- a/hw/hyperv/vmbus.c +++ b/hw/hyperv/vmbus.c @@ -1311,65 +1311,6 @@ static const VMStateDescription vmstate_vmbus_chan_req = { } }; -void vmbus_save_req(QEMUFile *f, VMBusChanReq *req) -{ -VMBusChanReqSave req_save; - -req_save.chan_idx = req->chan->subchan_idx; -req_save.pkt_type = req->pkt_type; -req_save.msglen = req->msglen; -req_save.msg = req->msg; -req_save.transaction_id = req->transaction_id; -req_save.need_comp = req->need_comp; -req_save.num = req->sgl.nsg; -req_save.sgl = g_memdup(req->sgl.sg, -req_save.num * sizeof(ScatterGatherEntry)); - -vmstate_save_state(f, &vmstate_vmbus_chan_req, &req_save, NULL); - -g_free(req_save.sgl); -} - -void *vmbus_load_req(QEMUFile *f, VMBusDevice *dev, uint32_t size) -{ -VMBusChanReqSave req_save; -VMBusChanReq *req = NULL; -VMBusChannel *chan = NULL; -uint32_t i; - -vmstate_load_state(f, &vmstate_vmbus_chan_req, &req_save, 0); - -if (req_save.chan_idx >= dev->num_channels) { -error_report("%s: %u(chan_idx) > %u(num_channels)", __func__, - req_save.chan_idx, dev->num_channels); -goto out; -} -chan = &dev->channels[req_save.chan_idx]; - -if (vmbus_channel_reserve(chan, 0, req_save.msglen)) { -goto out; -} - -req = vmbus_alloc_req(chan, size, req_save.pkt_type, req_save.msglen, - req_save.transaction_id, req_save.need_comp); -if (req_save.msglen) { -memcpy(req->msg, req_save.msg, req_save.msglen); -} - -for (i = 0; i < req_save.num; i++) { -qemu_sglist_add(&req->sgl, req_save.sgl[i].base, req_save.sgl[i].len); -} - -out: -if (req_save.msglen) { -g_free(req_save.msg); -} -if (req_save.num) { -g_free(req_save.sgl); -} -return req; -} - static void channel_event_cb(EventNotifier *e) { VMBusChannel *chan = container_of(e, VMBusChannel, notifier); -- 2.31.1
Re: [PATCH] tests/vm/freebsd: Increase code coverage
On 6/15/21 19:40, Wainer dos Santos Moschetta wrote: > Hi, > > On 6/15/21 2:19 PM, Daniel P. Berrangé wrote: >> On Tue, Jun 15, 2021 at 06:02:02PM +0100, Daniel P. Berrangé wrote: >>> On Mon, May 31, 2021 at 05:53:25PM -0300, Wainer dos Santos Moschetta >>> wrote: Hi, On 5/31/21 7:03 AM, Philippe Mathieu-Daudé wrote: > Install more dependencies to increase code coverage. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/vm/freebsd | 5 + > 1 file changed, 5 insertions(+) With or without this patch I got an error when `make vm-build-freebsd`. It fails to install packages. For example, with this patch I got: < Output omitted> ### Installing packages ... Failed to prepare guest environment Traceback (most recent call last): File "/home/wmoschet/src/qemu/tests/vm/basevm.py", line 634, in main return vm.build_image(args.image) File "/home/wmoschet/src/qemu/tests/vm/freebsd", line 206, in build_image self.ssh_root_check("pkg install -y %s\n" % " ".join(self.pkgs)) File "/home/wmoschet/src/qemu/tests/vm/basevm.py", line 255, in ssh_root_check self._ssh_do(self._config["root_user"], cmd, True) File "/home/wmoschet/src/qemu/tests/vm/basevm.py", line 242, in _ssh_do raise Exception("SSH command failed: %s" % cmd) Exception: SSH command failed: pkg install -y git pkgconf bzip2 python37 ninja bash gmake gsed gettext cyrus-sasl gnutls nettle jpeg-turbo png sdl2 gtk3 libxkbcommon pixman libepoxy mesa-libs zstd usbredir Is it a known issue? >>> Hard to actually tell what the error really is. This message is >>> only giving the command that was invoked, but seems to have thrown >>> away stdout/stderr which would have the messages telling us what >>> went wrong. This lack of error reporting in basevm.py so badly >>> needs to be fixed, otherwise we're working blind when debugging >>> failures. >> Hmm, when I try the same command, it *does* print all the output >> so you can see what's going on, but it doesn't actually fail for >> me either (without this patch). > > Thomas sent me a message in private while ago that the error could be > related with the amount of ssh keys in my agent-ssh. I didn' t check > that hypothesis yet; will debug a littler further and let you all posted. > > ah, if this problem cannot be reproduced on other machinesI see no > reason to hold this patch. OK thank you!
Chardev: delete the QemuOpts reserved in vm_config_groups
We have found that qemu cannot plug in the previously unplugged device. start qemu with the following command: ./qemu-system-x86_64 -enable-kvm -m 8192 -smp 16 \ -object memory-backend-file,id=mem,size=8192M,mem-path=/dev/hugepages,share=on \ -numa node,memdev=mem -mem-prealloc \ ... -chardev socket,id=drive-virtio-disk1,path=/var/run/spdk/vhost_blk_socket-30dcf467-486a-45cf-b754-093bf5cf24d1,reconnect=10 \ -device vhost-user-blk-pci,chardev=drive-virtio-disk1,num-queues=1,bus=pci.0,addr=0x5,id=virtio-disk1 \ ... (qemu) info chardev serial0: filename=pty:/dev/pts/0 drive-virtio-disk1: filename=unix: charmonitor: filename=unix:/usr/local/var/lib/libvirt/qemu/domain-55-e59039db-d576-40db-a/monitor.sock,server (qemu) device_del virtio-disk1 (qemu) chardev-remove drive-virtio-disk1 (qemu) info chardev serial0: filename=pty:/dev/pts/0 charmonitor: filename=unix:/usr/local/var/lib/libvirt/qemu/domain-55-e59039db-d576-40db-a/monitor.sock,server (qemu) chardev-add socket,id=drive-virtio-disk1,path=/var/run/spdk/vhost_blk_socket-30dcf467-486a-45cf-b754-093bf5cf24d1,reconnect=10 device failed: Duplicate ID 'drive-virtio-disk1' for chardev Error: Parsing chardev args failed The root cause of this issue is that the QemuOpts is still reserved in vm_config_groups list, so qemu_opts_create will fail with the error above. So the QemuOpts should be removed when invoking qmp_chardev_remove. Signed-off-by: Zhoujian Yu
[PATCH-for-6.2 v2] hw/mem/pc-dimm: Restrict NUMA-specific code to NUMA machines
When trying to use the pc-dimm device on a non-NUMA machine, we get: $ qemu-system-arm -M none -cpu max -S \ -object memory-backend-file,id=mem1,size=1M,mem-path=/tmp/1m \ -device pc-dimm,id=dimm1,memdev=mem1 Segmentation fault (core dumped) (gdb) bt #0 pc_dimm_realize (dev=0x56da3e90, errp=0x7fffcd10) at hw/mem/pc-dimm.c:184 #1 0x55fe1f8f in device_set_realized (obj=0x56da3e90, value=true, errp=0x7fffce18) at hw/core/qdev.c:531 #2 0x55feb4a9 in property_set_bool (obj=0x56da3e90, v=0x56e54420, name=0x563c3c41 "realized", opaque=0x56a704f0, errp=0x7fffce18) at qom/object.c:2257 To avoid that crash, restrict the pc-dimm NUMA check to machines supporting NUMA, and do not allow the use of 'node' property on non-NUMA machines. Suggested-by: Igor Mammedov Signed-off-by: Philippe Mathieu-Daudé --- v2: Follow Igor suggestion Supersedes: <20210524171352.3796151-1-f4...@amsat.org> --- hw/mem/pc-dimm.c | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c index a3a2560301c..48b913aba67 100644 --- a/hw/mem/pc-dimm.c +++ b/hw/mem/pc-dimm.c @@ -181,7 +181,21 @@ static void pc_dimm_realize(DeviceState *dev, Error **errp) PCDIMMDevice *dimm = PC_DIMM(dev); PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm); MachineState *ms = MACHINE(qdev_get_machine()); -int nb_numa_nodes = ms->numa_state->num_nodes; + +if (ms->numa_state) { +int nb_numa_nodes = ms->numa_state->num_nodes; + +if (((nb_numa_nodes > 0) && (dimm->node >= nb_numa_nodes)) || +(!nb_numa_nodes && dimm->node)) { +error_setg(errp, "'DIMM property " PC_DIMM_NODE_PROP " has value %" + PRIu32 "' which exceeds the number of numa nodes: %d", + dimm->node, nb_numa_nodes ? nb_numa_nodes : 1); +return; +} +} else if (dimm->node > 0) { +error_setg(errp, "machine doesn't support NUMA"); +return; +} if (!dimm->hostmem) { error_setg(errp, "'" PC_DIMM_MEMDEV_PROP "' property is not set"); @@ -191,13 +205,6 @@ static void pc_dimm_realize(DeviceState *dev, Error **errp) object_get_canonical_path_component(OBJECT(dimm->hostmem))); return; } -if (((nb_numa_nodes > 0) && (dimm->node >= nb_numa_nodes)) || -(!nb_numa_nodes && dimm->node)) { -error_setg(errp, "'DIMM property " PC_DIMM_NODE_PROP " has value %" - PRIu32 "' which exceeds the number of numa nodes: %d", - dimm->node, nb_numa_nodes ? nb_numa_nodes : 1); -return; -} if (ddc->realize) { ddc->realize(dimm, errp); -- 2.31.1
Re: [PATCH] meson: Fix 'interpretor' typo
ping... https://lore.kernel.org/qemu-devel/20210521103423.2780345-1-phi...@redhat.com/ On Sat, Jun 5, 2021 at 9:03 PM Laurent Vivier wrote: > > Le 21/05/2021 à 12:34, Philippe Mathieu-Daudé a écrit : > > Fix a typo from commit fa2f7b0b9b7 ("meson: Warn when TCI is > > selected but TCG backend is available"). > > > > Reported-by: Peter Maydell > > Signed-off-by: Philippe Mathieu-Daudé > > --- > > meson.build | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/meson.build b/meson.build > > index 1559e8d873a..230a0e4b558 100644 > > --- a/meson.build > > +++ b/meson.build > > @@ -247,7 +247,7 @@ > >error('Unsupported CPU @0@, try > > --enable-tcg-interpreter'.format(cpu)) > > endif > >elif get_option('tcg_interpreter') > > -warning('Use of the TCG interpretor is not recommended on this host') > > +warning('Use of the TCG interpreter is not recommended on this host') > > warning('architecture. There is a native TCG execution backend > > available') > > warning('which provides substantially better performance and > > reliability.') > > warning('It is strongly recommended to remove the > > --enable-tcg-interpreter') > > > > Reviewed-by: Laurent Vivier >
Re: [PATCH 00/11] exec: Restrict various system emulation specific headers (to sysemu)
6 months passed, heavy rebased required, dropping for now. On 5/25/21 16:13, Philippe Mathieu-Daudé wrote: > Ping for review? :) > > On 5/17/21 1:11 PM, Philippe Mathieu-Daudé wrote: >> Hi, >> >> This series restricts various system emulation specific headers >> by moving them under sysemu/ and adding #error if included from >> user emulation. >> We could avoid the sysemu/ rename if too much churn, but enforcing >> error of headers that must not be included in user emulation allows >> further cleanups (to be sent later). >> >> I had to split the ioport.c file to cpu-io (generic to any target >> having access to I/O bus, but I haven't checked the TCG implementation >> details for user emulation) VS ioport (system specific, access to >> hardware). >> >> Many files are changed, but this is mostly one-line mechanical >> updates of old path to new path using sed. >> >> Regards, >> >> Phil. >> >> Philippe Mathieu-Daudé (11): >> NOTFORMERGE target/arm: Restrict KVM files to softmmu >> exec: Restrict hwaddr.h to sysemu/ >> exec: Restrict cputlb.h to sysemu/ >> exec: Restrict memory.h to sysemu/ >> exec: Restrict memory-internal.h to sysemu/ >> exec: Restrict address-spaces.h to sysemu/ >> exec: Extract CPU I/O instructions to "cpu-io.h" >> exec: Restrict ioport.h to sysemu/ >> exec: Restrict ram_addr.h to sysemu/ >> exec: Restrict ramblock.h to sysemu/ >> exec: Restrict confidential-guest-support.h to sysemu/ > >> 275 files changed, 491 insertions(+), 409 deletions(-) >> create mode 100644 include/exec/cpu-io.h >> rename include/exec/{ => sysemu}/address-spaces.h (80%) >> rename include/exec/{ => sysemu}/cputlb.h (86%) >> rename include/exec/{ => sysemu}/hwaddr.h (81%) >> rename include/exec/{ => sysemu}/memory-internal.h (94%) >> rename include/exec/{ => sysemu}/memory.h (99%) >> rename include/{exec => sysemu}/confidential-guest-support.h (95%) >> rename include/{exec => sysemu}/ioport.h (86%) >> rename include/{exec => sysemu}/ram_addr.h (99%) >> rename include/{exec => sysemu}/ramblock.h (92%) >> create mode 100644 softmmu/cpu-io.c >> >
Re: [PATCH v2 0/4] hw/isa: Remove unuseful qemu_allocate_irqs() call
Cc'ing Zoltan On 5/11/21 06:06, Philippe Mathieu-Daudé wrote: > I started to fix the LeakSanitizer error in piix4_realize(), > then looked for similar pattern and found 2 other places. > The older is i82378 (historically the first one) which then > spread. > > Since v1: > - rebased > - removed vt82c686 patches > > Philippe Mathieu-Daudé (4): > hw/isa/i82378: Name output IRQ as 'intr' > hw/isa/i82378: Simplify removing unuseful qemu_allocate_irqs() call > hw/isa/i82378: Rename output IRQ variable > hw/isa/piix4: Fix leak removing unuseful qemu_allocate_irqs() call > > hw/isa/i82378.c | 13 +++-- > hw/isa/piix4.c | 10 +- > hw/ppc/prep.c | 4 ++-- > 3 files changed, 6 insertions(+), 21 deletions(-) >
Re: [PATCH] meson: Fix 'interpretor' typo
Le 06/11/2021 à 15:53, Philippe Mathieu-Daudé a écrit : ping... https://lore.kernel.org/qemu-devel/20210521103423.2780345-1-phi...@redhat.com/ On Sat, Jun 5, 2021 at 9:03 PM Laurent Vivier wrote: Le 21/05/2021 à 12:34, Philippe Mathieu-Daudé a écrit : Fix a typo from commit fa2f7b0b9b7 ("meson: Warn when TCI is selected but TCG backend is available"). Reported-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build index 1559e8d873a..230a0e4b558 100644 --- a/meson.build +++ b/meson.build @@ -247,7 +247,7 @@ error('Unsupported CPU @0@, try --enable-tcg-interpreter'.format(cpu)) endif elif get_option('tcg_interpreter') -warning('Use of the TCG interpretor is not recommended on this host') +warning('Use of the TCG interpreter is not recommended on this host') warning('architecture. There is a native TCG execution backend available') warning('which provides substantially better performance and reliability.') warning('It is strongly recommended to remove the --enable-tcg-interpreter') Reviewed-by: Laurent Vivier Applied to my trivial-patches branch. Thanks, Laurent
Re: [PATCH] target/ppc, hw/ppc: Change maintainers
What we are going do will depend on inputs really. We have pseries and KVM in focus because there is still business using the software stack. TCG is extremely useful for pseries and powernv. We clearly want to keep that running and improve it. Some parts have been barely touched (and probably used) in the last 15 years. I think we should drop some support to modernize the useful parts and ease maintenance. Here let me recommend the ant work approach I'm doing for MIPS. Instead of dropping ISA extensions, I'm splitting them in various compile units, that way 1/ we can chose to build without them and 2/ sub-maintainers can maintain them separately. Having a finer grained MAINTAINERS entries allow to filter-out/in and reduce reviewers pressure. OK. Yes, the goal is to ease maintenance, not to remove platforms or CPUs. QEMU is the perfect project for legacy systems. I am very willing to go in that direction and take the risk to break a few things. We have been through such an episode when HV mode was added for the PowerNV machine and we managed to fix all regressions, down to OpenBIOS. Ben and his ppc32 knowledge helped a lot of course. Untangling some parts won't be easy. Exception modeling for instance. The instruction implementation shouldn't be too hard and it's being modernized by Luis and Matheus. I guess we should improve our testsuite to catch early any issues. An acceptance test for each machine is a minimum. Thanks, C.
Re: Qemu and ARM secure state.
One small question/remark: According to the the "Arm Power State Coordinate Interface" (DEN0022D.b) document (chapter 5) PSCI calls can only be issued by "normal world" (EL1 or EL2). Therefore, should we be adding a test for the current secure state in the arm_is_psci_call() function? This would prevent calling the built-in Qemu PSCI function if SMC is issued from secure state. Regards. JC Le 06/11/2021 à 14:04, Jean-Christophe DUBOIS a écrit : So it seems that what is needed is a way to choose on the command line if we want to enable the Qemu built-in PSCI implementation (because we are booting linux for example) or if we really want a bare metal processor (because we are booting a trustedOS like optee). The "virt" platform allows to dynamically choose one or the other. Other platforms seems to need the same feature. JC Le 06/11/2021 à 11:04, Jean-Christophe DUBOIS a écrit : So, I am trying to understand: Contrary to what I said, In my case the SMC instruction is not really a "no-op" as it sets R0 to -1 (0x) to indicate an unknown PSCI service (by the Qemu internal PSCI handler). With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3 section 5.2" commit, once a processor/platform configure things to have PSCI requests handled by Qemu code (with "psci-conduit" attribute set to QEMU_PSCI_CONDUIT_SMC for example), then any exception raised by an "SMC" instruction will be only handled by the Qemu internal code and will no call the monitor related code in the guest/OS application. This seems to be why my SMC monitor handler is not called anymore in my case. As my i.MX6UL is a mono-processor platform I don't really need to set the "psci-conduit" attribute (which really makes sense when you have a cluster of 2 or more cores I guess). As a matter of fact if I remove the "psci-conduit" attribute setting from the i.MX6UL processor file, my application is working again on main/latest. But this still raises the question to know if the current behavior for processors with "psci-conduit" set to SMC or HVC is correct. For example an i.MX7 based platform (with up to 4 cortex A7 cores) would not be able to trigger OS SMC handler as the exception would be entirely processed by the Qemu internal code (with CR generally set to -1 in R0 to indicate unknown PSCI request). Is there something I am missing? Regards JC Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit : Le 04/11/2021 à 12:11, Peter Maydell a écrit : On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS wrote: I have a little application that is designed to work on the i.MX6UL processor. I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu. This application used to work "flawlessly" on Qemu 5.0.50 and is working on Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu). But when I try to run the exact same command line on a Qemu version I compile myself from main/latest of github (Qemu 6.1.50), my application fails to start. So a little background: My application expects to start in "secure" state and supervisor mode (which is the default state of i.MX6UL when booting barebone [without u-boot]). >From this state the application tries to get to "non secure" / hypervisor mode which imply going to the "secure" / monitor state before being able to drop to "non secure" / hypervisor. To do so is runs a "smc 0" operand (from "secure" / supervisor). This "smc" instruction is processed "as expected" by Qemu 5.0.50 and Qemu 6.0.0 (getting to "secure" / monitor mode) but on Qemu 6.1.50 (latest from github) it is as if the smc operand was a no-op. It doesn't trigger any exception and the processor just get to the next instruction after the "smc" instruction. So I am a bit puzzled. Is there something that changed in Qemu (since Qemu 6.0.0) when it comes to the "secure" world/state? Is there some additional command line parameters to use (I search in the documentation but without luck) to get secure world behavior ? Is it necessary to "adapt" the emulated platform (i.MX6UL/mcimx6ul-evk) in some way (it looks like the "virt" machine with "secure=on" does work for arm platform)? Could you try doing a bisect to find the QEMU commit that caused your guest to stop working ? OK, I did the bisect and the commit that break the i.MX6UL behavior for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4 (arm: tcg: Adhere to SMCCC 1.3 section 5.2). Before it the SMC instruction would trigger a monitor exception. After it the SMC instruction is acting like a no-op. Thanks JC thanks -- PMM
Re: [PATCH v2 0/4] hw/isa: Remove unuseful qemu_allocate_irqs() call
On Sat, 6 Nov 2021, Philippe Mathieu-Daudé wrote: Cc'ing Zoltan What do I have to do with this? This was a while ago so I don't remember and it seems to not touch any of the devices I have some experience with so not sure what do you expect from me for this series. Regards, BALATON Zoltan On 5/11/21 06:06, Philippe Mathieu-Daudé wrote: I started to fix the LeakSanitizer error in piix4_realize(), then looked for similar pattern and found 2 other places. The older is i82378 (historically the first one) which then spread. Since v1: - rebased - removed vt82c686 patches Philippe Mathieu-Daudé (4): hw/isa/i82378: Name output IRQ as 'intr' hw/isa/i82378: Simplify removing unuseful qemu_allocate_irqs() call hw/isa/i82378: Rename output IRQ variable hw/isa/piix4: Fix leak removing unuseful qemu_allocate_irqs() call hw/isa/i82378.c | 13 +++-- hw/isa/piix4.c | 10 +- hw/ppc/prep.c | 4 ++-- 3 files changed, 6 insertions(+), 21 deletions(-)
Re: [PATCH v4 0/1] hw/hyperv/vmbus: Is it maintained?
On 06.11.2021 14:41, Philippe Mathieu-Daudé wrote: This is the 4th time I send this patch. Is the VMBus infrastructure used / maintained? Should we deprecate & remove? $ ./scripts/get_maintainer.pl -f hw/hyperv/vmbus.c -f include/hw/hyperv/vmbus.h get_maintainer.pl: No maintainers found There's an email thread at [1] explaining the reasons for having VMBus infrastructure last time such question was asked. In short: mere presence of a working VMBus is needed for some high-speed Windows debugging, also people are working on VMBus host device drivers. Your patch makes sense to me, so for it: Reviewed-by: Maciej S. Szmigiero Thanks, Maciej [1]: https://lore.kernel.org/qemu-devel/20201009193919.gf7...@habkost.net/T/#u
[PATCH 2/2] hw: m68: virt: Add compat machines for 6.2
Add the missing machine type for m68k/virt Signed-off-by: Laurent Vivier --- hw/m68k/virt.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c index 0d9e3f83c169..978c26e025a7 100644 --- a/hw/m68k/virt.c +++ b/hw/m68k/virt.c @@ -304,10 +304,17 @@ type_init(virt_machine_register_types) } \ type_init(machvirt_machine_##major##_##minor##_init); +static void virt_machine_6_2_options(MachineClass *mc) +{ +} +DEFINE_VIRT_MACHINE(6, 2, true) + static void virt_machine_6_1_options(MachineClass *mc) { +virt_machine_6_2_options(mc); +compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len); } -DEFINE_VIRT_MACHINE(6, 1, true) +DEFINE_VIRT_MACHINE(6, 1, false) static void virt_machine_6_0_options(MachineClass *mc) { -- 2.31.1
[PATCH 1/2] hw: m68: virt: Add compat machines for 6.1
Add the missing machine type for m68k/virt Cc: qemu-sta...@nongnu.org Signed-off-by: Laurent Vivier --- hw/m68k/virt.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c index 4e8bce5aa6f7..0d9e3f83c169 100644 --- a/hw/m68k/virt.c +++ b/hw/m68k/virt.c @@ -304,7 +304,14 @@ type_init(virt_machine_register_types) } \ type_init(machvirt_machine_##major##_##minor##_init); +static void virt_machine_6_1_options(MachineClass *mc) +{ +} +DEFINE_VIRT_MACHINE(6, 1, true) + static void virt_machine_6_0_options(MachineClass *mc) { +virt_machine_6_1_options(mc); +compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len); } -DEFINE_VIRT_MACHINE(6, 0, true) +DEFINE_VIRT_MACHINE(6, 0, false) -- 2.31.1
[PATCH 0/2] hw: m68k: add missing virt machine types
Add the machine type for 6.2, and also for 6.1 that I have missed on the previous release. Laurent Vivier (2): hw: m68: virt: Add compat machines for 6.1 hw: m68: virt: Add compat machines for 6.2 hw/m68k/virt.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 2.31.1
Re: [PULL 4/6] ui/gtk-egl: guest fb texture needs to be regenerated when reinitializing egl
Le 05/11/2021 à 12:30, Gerd Hoffmann a écrit : From: Dongwon Kim If guest fb is backed by dmabuf (blob-resource), the texture bound to the old context needs to be recreated in case the egl is re-initialized (e.g. new window for vc is created in case of detaching/reattaching of the tab) v2: call egl_dmabuf_release_texutre instead of putting 0 to dmabuf->texture (Vivek Kasireddy) Cc: Gerd Hoffmann Signed-off-by: Dongwon Kim Message-Id: <20211104065153.28897-3-dongwon@intel.com> Signed-off-by: Gerd Hoffmann --- ui/gtk-egl.c | 4 1 file changed, 4 insertions(+) diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c index 21649950983f..f2026e4b5c9b 100644 --- a/ui/gtk-egl.c +++ b/ui/gtk-egl.c @@ -155,6 +155,10 @@ void gd_egl_refresh(DisplayChangeListener *dcl) surface_gl_destroy_texture(vc->gfx.gls, vc->gfx.ds); surface_gl_create_texture(vc->gfx.gls, vc->gfx.ds); } +if (vc->gfx.guest_fb.dmabuf) { +egl_dmabuf_release_texture(vc->gfx.guest_fb.dmabuf); +gd_egl_scanout_dmabuf(dcl, vc->gfx.guest_fb.dmabuf); +} } graphic_hw_update(dcl->con); This patch breaks something: $ .../configure' '--target-list=m68k-softmmu' '--enable-virglrenderer' $ make ... FAILED: libcommon.fa.p/ui_gtk-egl.c.o cc -m64 -mcx16 -Ilibcommon.fa.p -I../../../Projects/qemu-next/capstone/include/capstone -I../../../Projects/qemu-next/dtc/libfdt -I../../../Projects/qemu-next/slirp -I../../../Projects/qemu-next/slirp/src -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/virgl -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/at-spi-2.0 -I/usr/include/vte-2.91 -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/laurent/Projects/qemu-next/linux-headers -isystem linux-headers -iquote . -iquote /home/laurent/Projects/qemu-next -iquote /home/laurent/Projects/qemu-next/include -iquote /home/laurent/Projects/qemu-next/disas/libvixl -iquote /home/laurent/Projects/qemu-next/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR -D_REENTRANT -MD -MQ libcommon.fa.p/ui_gtk-egl.c.o -MF libcommon.fa.p/ui_gtk-egl.c.o.d -o libcommon.fa.p/ui_gtk-egl.c.o -c ../../../Projects/qemu-next/ui/gtk-egl.c ../../../Projects/qemu-next/ui/gtk-egl.c: In function 'gd_egl_refresh': ../../../Projects/qemu-next/ui/gtk-egl.c:159:13: error: implicit declaration of function 'egl_dmabuf_release_texture' [-Werror=implicit-function-declaration] 159 | egl_dmabuf_release_texture(vc->gfx.guest_fb.dmabuf); | ^~ ../../../Projects/qemu-next/ui/gtk-egl.c:159:13: error: nested extern declaration of 'egl_dmabuf_release_texture' [-Werror=nested-externs] I think we need something like: diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c index f2026e4b5c9b..45cb67712df0 100644 --- a/ui/gtk-egl.c +++ b/ui/gtk-egl.c @@ -155,10 +155,12 @@ void gd_egl_refresh(DisplayChangeListener *dcl) surface_gl_destroy_texture(vc->gfx.gls, vc->gfx.ds); surface_gl_create_texture(vc->gfx.gls, vc->gfx.ds); } +#ifdef CONFIG_GBM if (vc->gfx.guest_fb.dmabuf) { egl_dmabuf_release_texture(vc->gfx.guest_fb.dmabuf); gd_egl_scanout_dmabuf(dcl, vc->gfx.guest_fb.dmabuf); } +#endif } graphic_hw_update(dcl->con); Thanks, Laurent
[PULL 1/2] migration: Check that postcopy fd's are not NULL
If postcopy has finished, it frees the array. But vhost-user unregister it at cleanup time. fixes: c4f7538 Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert --- migration/postcopy-ram.c | 4 1 file changed, 4 insertions(+) diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c index e721f69d0f..d18b5d05b2 100644 --- a/migration/postcopy-ram.c +++ b/migration/postcopy-ram.c @@ -1457,6 +1457,10 @@ void postcopy_unregister_shared_ufd(struct PostCopyFD *pcfd) MigrationIncomingState *mis = migration_incoming_get_current(); GArray *pcrfds = mis->postcopy_remote_fds; +if (!pcrfds) { +/* migration has already finished and freed the array */ +return; +} for (i = 0; i < pcrfds->len; i++) { struct PostCopyFD *cur = &g_array_index(pcrfds, struct PostCopyFD, i); if (cur->fd == pcfd->fd) { -- 2.33.1
[PULL 2/2] docs: fix qemu incorrect tag
From: Hyman Huang(黄勇) The patchset merged in 71864eadd9a ("migration/dirtyrate: introduce struct and adjust DirtyRateStat") was targeting QEMU 6.1 but got merged later, so correct the tag for 6.2. Signed-off-by: Hyman Huang(黄勇) Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Juan Quintela Signed-off-by: Juan Quintela --- qapi/migration.json | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/qapi/migration.json b/qapi/migration.json index 87146ceea2..f0aefdab64 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -1740,7 +1740,7 @@ # # @dirty-rate: dirty rate. # -# Since: 6.1 +# Since: 6.2 # ## { 'struct': 'DirtyRateVcpu', @@ -1774,7 +1774,7 @@ # # @dirty-bitmap: calculate dirtyrate by dirty bitmap. # -# Since: 6.1 +# Since: 6.2 # ## { 'enum': 'DirtyRateMeasureMode', @@ -1796,13 +1796,13 @@ # @calc-time: time in units of second for sample dirty pages # # @sample-pages: page count per GB for sample dirty pages -#the default value is 512 (since 6.1) +#the default value is 512 (since 6.2) # # @mode: mode containing method of calculate dirtyrate includes -#'page-sampling' and 'dirty-ring' (Since 6.1) +#'page-sampling' and 'dirty-ring' (Since 6.2) # # @vcpu-dirty-rate: dirtyrate for each vcpu if dirty-ring -# mode specified (Since 6.1) +# mode specified (Since 6.2) # # Since: 5.2 # -- 2.33.1
[PULL 0/2] Migration 20211106 patches
The following changes since commit c39deb218178d1fb814dd2138ceff4b541a03d85: Merge remote-tracking branch 'remotes/kraxel/tags/egl-20211105-pull-request' into staging (2021-11-05 11:42:06 -0400) are available in the Git repository at: https://github.com/juanquintela/qemu.git tags/migration-20211106-pull-request for you to fetch changes up to f78d4ed701454f10079461b981ba2a61a95762ab: docs: fix qemu incorrect tag (2021-11-06 12:35:38 +0100) Migration Pull request - fix vhost-user crash when using postcopy (me) - fix incorrect tag for docs (hyman) Please apply, Juan. Hyman Huang(黄勇) (1): docs: fix qemu incorrect tag Juan Quintela (1): migration: Check that postcopy fd's are not NULL qapi/migration.json | 10 +- migration/postcopy-ram.c | 4 2 files changed, 9 insertions(+), 5 deletions(-) -- 2.33.1
Re: [PATCH v2] linux-user: Mark cpu_loop() with noreturn attribute
On Sat, Nov 6, 2021, 5:39 AM Philippe Mathieu-Daudé wrote: > cpu_loop() never exits, so mark it with QEMU_NORETURN. > > Reviewed-by: Richard Henderson > Reviewed-By: Warner Losh > Reviewed-by: Bin Meng > Signed-off-by: Philippe Mathieu-Daudé > --- > v2: > - rebased > - restricted to linux-user > > Supersedes: <20210905000429.1097336-1-f4...@amsat.org> > Reviewed-by: Warner Losh bsd-user likely needs similar treatment, no? --- > linux-user/user-internals.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/linux-user/user-internals.h b/linux-user/user-internals.h > index 661612a088b..c7ad00268af 100644 > --- a/linux-user/user-internals.h > +++ b/linux-user/user-internals.h > @@ -65,7 +65,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long > arg1, > abi_long arg5, abi_long arg6, abi_long arg7, > abi_long arg8); > extern __thread CPUState *thread_cpu; > -void cpu_loop(CPUArchState *env); > +void QEMU_NORETURN cpu_loop(CPUArchState *env); > const char *target_strerror(int err); > int get_osversion(void); > void init_qemu_uname_release(void); > -- > 2.31.1 > >
Re: [PULL 0/2] Migration 20211106 patches
On 11/6/21 7:29 PM, Juan Quintela wrote: The following changes since commit c39deb218178d1fb814dd2138ceff4b541a03d85: Merge remote-tracking branch 'remotes/kraxel/tags/egl-20211105-pull-request' into staging (2021-11-05 11:42:06 -0400) are available in the Git repository at: https://github.com/juanquintela/qemu.git tags/migration-20211106-pull-request for you to fetch changes up to f78d4ed701454f10079461b981ba2a61a95762ab: docs: fix qemu incorrect tag (2021-11-06 12:35:38 +0100) Migration Pull request - fix vhost-user crash when using postcopy (me) - fix incorrect tag for docs (hyman) Please apply, Juan. Hyman Huang(黄勇) (1): docs: fix qemu incorrect tag Juan Quintela (1): migration: Check that postcopy fd's are not NULL qapi/migration.json | 10 +- migration/postcopy-ram.c | 4 2 files changed, 9 insertions(+), 5 deletions(-) Applied, thanks. r~
[PATCH] audio: Add sndio backend
audio: Add sndio backend Add a sndio backend. sndio is the native API used by OpenBSD, although it has been ported to other *BSD's and Linux (packages for Ubuntu, Debian, Void, Arch, etc.). The C code is from Alexandre Ratchov and the rest of the bits are from me. --- audio/audio.c | 1 + audio/audio_template.h | 2 + audio/meson.build | 1 + audio/sndioaudio.c | 555 + meson.build| 7 + meson_options.txt | 4 +- qapi/audio.json| 25 +- qemu-options.hx| 8 + tests/vm/freebsd | 3 + 9 files changed, 604 insertions(+), 2 deletions(-) create mode 100644 audio/sndioaudio.c diff --git a/audio/audio.c b/audio/audio.c index 54a153c0ef..bad1ceb69e 100644 --- a/audio/audio.c +++ b/audio/audio.c @@ -2005,6 +2005,7 @@ void audio_create_pdos(Audiodev *dev) CASE(OSS, oss, Oss); CASE(PA, pa, Pa); CASE(SDL, sdl, Sdl); +CASE(SNDIO, sndio, ); CASE(SPICE, spice, ); CASE(WAV, wav, ); diff --git a/audio/audio_template.h b/audio/audio_template.h index c6714946aa..ecc5a0bc6d 100644 --- a/audio/audio_template.h +++ b/audio/audio_template.h @@ -337,6 +337,8 @@ AudiodevPerDirectionOptions *glue(audio_get_pdo_, TYPE)(Audiodev *dev) return qapi_AudiodevPaPerDirectionOptions_base(dev->u.pa.TYPE); case AUDIODEV_DRIVER_SDL: return qapi_AudiodevSdlPerDirectionOptions_base(dev->u.sdl.TYPE); +case AUDIODEV_DRIVER_SNDIO: +return dev->u.sndio.TYPE; case AUDIODEV_DRIVER_SPICE: return dev->u.spice.TYPE; case AUDIODEV_DRIVER_WAV: diff --git a/audio/meson.build b/audio/meson.build index 462533bb8c..e24c86e7e6 100644 --- a/audio/meson.build +++ b/audio/meson.build @@ -17,6 +17,7 @@ foreach m : [ ['pa', pulse, files('paaudio.c')], ['sdl', sdl, files('sdlaudio.c')], ['jack', jack, files('jackaudio.c')], + ['sndio', sndio, files('sndioaudio.c')], ['spice', spice, files('spiceaudio.c')] ] if m[1].found() diff --git a/audio/sndioaudio.c b/audio/sndioaudio.c new file mode 100644 index 00..204af07781 --- /dev/null +++ b/audio/sndioaudio.c @@ -0,0 +1,555 @@ +/* + * Copyright (c) 2019 Alexandre Ratchov + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* + * TODO : + * + * Use a single device and open it in full-duplex rather than + * opening it twice (once for playback once for recording). + * + * This is the only way to ensure that playback doesn't drift with respect + * to recording, which is what guest systems expect. + */ + +#include +#include +#include "qemu/osdep.h" +#include "qemu-common.h" +#include "qemu/main-loop.h" +#include "audio.h" +#include "trace.h" + +#define AUDIO_CAP "sndio" +#include "audio_int.h" + +/* default latency in ms if no option is set */ +#define SNDIO_LATENCY_US 5 + +typedef struct SndioVoice { +union { +HWVoiceOut out; +HWVoiceIn in; +} hw; +struct sio_par par; +struct sio_hdl *hdl; +struct pollfd *pfds; +struct pollindex { +struct SndioVoice *self; +int index; +} *pindexes; +unsigned char *buf; +size_t buf_size; +size_t sndio_pos; +size_t qemu_pos; +unsigned int mode; +unsigned int nfds; +} SndioVoice; + +typedef struct SndioConf { +const char *devname; +unsigned int latency; +} SndioConf; + +/* needed for forward reference */ +static void sndio_poll_in(void *arg); +static void sndio_poll_out(void *arg); + +/* + * stop polling descriptors + */ +static void sndio_poll_clear(SndioVoice *self) +{ +struct pollfd *pfd; +int i; + +for (i = 0; i < self->nfds; i++) { +pfd = &self->pfds[i]; +qemu_set_fd_handler (pfd->fd, NULL, NULL, NULL); +} + +self->nfds = 0; +} + +/* + * write data to the device until it blocks or + * all of our buffered data is written + */ +static void sndio_write(SndioVoice *self) +{ +size_t todo, n; + +todo = self->qemu_pos - self->sndio_pos; + +/* + * transfer data to device, until it blocks + */ +while (todo > 0) { +n = sio_write(self->hdl, self->buf + self->sndio_pos, todo); +if (n == 0) { +break; +} +self->sndio_pos += n; +todo -= n; +} + +if (self->s