Il lun 25 set 2023, 18:45 Alex Bennée ha scritto:
> Paolo Bonzini writes:
> > On 9/25/23 16:48, Alex Bennée wrote:
> >> echo "HOST_GDB_SUPPORTS_ARCH=y" >> "$config_target_mak"
> >> fi
> >> +
On 9/25/23 16:48, Alex Bennée wrote:
If we update configure we should make sure we regenerate all the
compiler details. We should also ensure those details are upto date
before building the TCG tests.
Signed-off-by: Alex Bennée
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff
On 9/25/23 16:48, Alex Bennée wrote:
Since 0b1a649047 (tests/docker: use direct RUNC call to build
containers) we ended up with the potential for the remaining docker.py
script calls to deviate from the direct RUNC calls. Fix this by
dropping the use of ENGINE in the makefile and rely entirely
On 4/25/22 10:21, Martin Kletzander wrote:
I wanted to deal with https://bugzilla.redhat.com/2043498 and I got a
suggesstion that removing deprecated features could actually make it
easier to propagate the error. In the end (last patch) it turns out the
error is still just reported with
On Thu, Jun 22, 2023 at 5:26 PM Peter Xu wrote:
> PS: we may want to postpone this to be later than migration_object_init(),
> when/if there's a real patch.
Yes, that's true.
> > > The only incompatibility is for people who are using "," in an URI,
> > > which is rare and only an issue for the
On 6/22/23 10:52, Juan Quintela wrote:
User friendliness.
The problem is that if you use more than two channels with multifd, on
the incoming side, you need to do:
You're sacrificing user-friendliness for the 99.99% that don't use
multifd, for an error (i.e. it's not even fixing the issue)
On 6/21/23 09:08, Thomas Huth wrote:
if (strcmp(incoming, "defer") != 0) {
+ warn_report("-incoming %s is deprecated, use -incoming
defer and "
+ " set the uri with migrate-incoming.",
incoming);
qmp_migrate_incoming(incoming, _err);
On 6/12/23 22:51, Juan Quintela wrote:
Shall we just leave it there? Or is deprecating it helps us in any form?
See the patches two weeks ago when people complained that lisen(.., num)
was too low. And there are other parameters that work the same way
(that I convenientely had forgotten). So
On 4/4/23 16:24, Peter Maydell 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
On 4/4/23 11:17, Peter Maydell wrote:
I don't want to add a QMP interface for writing it unless
there's somebody who actually has a use case for it.
We could place the accelerator at a well-known QOM path such as
/machine/accel, and then qom-set can already be used to implement such
an
On 2/17/23 11:47, Daniel P. Berrangé wrote:
On Fri, Feb 17, 2023 at 11:36:41AM +0100, Markus Armbruster wrote:
I feel the discussion petered out without a conclusion.
I don't think letting the status quo win by inertia is a good outcome
here.
Which 32-bit hosts are still useful, and why?
le anymore.
The CPU properties were obtained from the query-hotpluggable-cpus output
in tests/qemumonitorjsondata. CPU, thread_id, and qom_path are renamed
respectively to cpu-index, qom-path and thread-id, while nip and halted
are removed.
Signed-off-by: Paolo Bonzini
---
...json-cpuinfo-x86-basic
All tests now use query-cpus-fast. Since the QEMU driver will lose
support for query-cpus soon, go ahead and remove support for testing
it.
Signed-off-by: Paolo Bonzini
---
tests/qemumonitorjsontest.c | 117 +---
1 file changed, 15 insertions(+), 102 deletions
All supported versions of QEMU have the command.
Signed-off-by: Paolo Bonzini
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h | 2 +-
tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 -
tests/qemucapabilitiesdata/caps_3.1.0
All supported versions of QEMU include the query-cpus-fast QMP command.
In preparation for dropping support for the old "query-cpus" commands,
remove the "-fast" suffix from both x86-full-fast and s390-fast.
Signed-off-by: Paolo Bonzini
---
...-fast-cpus.json => qemum
The query-cpus-fast command was introduced in 2.12, therefore
query-cpus is never used on supported versions of QEMU. Remove
the logic to parse its output, as well as the parameters to
choose between the two commands.
Signed-off-by: Paolo Bonzini
---
src/qemu/qemu_domain.c | 22
results of QEMU monitor commands have to be converted as well.
Thanks,
Paolo
v1->v2: do not query capability, regenerate test output [Peter]
hopefully patch 3/7 is not mangled [Pavel]
Paolo Bonzini (7):
tests: remove duplicate cpuinfo test
tests: drop "-fast" from query-cp
All supported versions of QEMU include the query-cpus-fast QMP command.
In preparation for dropping support for the old "query-cpus" commands,
remove the query-cpus version of the x86-full test.
Signed-off-by: Paolo Bonzini
---
...qemumonitorjson-cpuinfo-x86-full-cpus.
le anymore.
The CPU properties were obtained from the query-hotpluggable-cpus output
in tests/qemumonitorjsondata. CPU, thread_id, and qom_path are renamed
respectively to cpu-index, qom-path and thread-id, while nip and halted
are removed.
Signed-off-by: Paolo Bonzini
---
...umonitorjson-cpuinfo-p
On 8/8/22 16:44, Pavel Hrdina wrote:
diff --git
a/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-cpus.json
b/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-cpus.json
index 31a3905e43..0ee53ae471 100644
---
All tests now use query-cpus-fast. Since the QEMU driver will lose
support for query-cpus soon, go ahead and remove support for testing
it.
Signed-off-by: Paolo Bonzini
---
tests/qemumonitorjsontest.c | 117 +---
1 file changed, 15 insertions(+), 102 deletions
The query-cpus-fast command was introduced in 2.12, therefore
query-cpus is never used on supported versions of QEMU. Remove
the logic to parse its output, as well as the parameters to
choose between the two commands.
Signed-off-by: Paolo Bonzini
---
src/qemu/qemu_domain.c | 22
All supported versions of QEMU have the command.
Signed-off-by: Paolo Bonzini
---
src/qemu/qemu_capabilities.c | 4 ++--
src/qemu/qemu_capabilities.h | 2 +-
tests/qemuhotplugtest.c | 2 --
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src
le anymore.
The CPU properties were obtained from the query-hotpluggable-cpus output
in tests/qemumonitorjsondata. CPU, thread_id, and qom_path are renamed
respectively to cpu-index, qom-path and thread-id, while nip and halted
are removed.
Signed-off-by: Paolo Bonzini
---
...umonitorjson-cpuinfo-p
le anymore.
The CPU properties were obtained from the query-hotpluggable-cpus output
in tests/qemumonitorjsondata. CPU, thread_id, and qom_path are renamed
respectively to cpu-index, qom-path and thread-id, while nip and halted
are removed.
Signed-off-by: Paolo Bonzini
---
...json-cpuinfo-x86-basic
All supported versions of QEMU include the query-cpus-fast QMP command.
In preparation for dropping support for the old "query-cpus" commands,
remove the "-fast" suffix from both x86-full-fast and s390-fast.
Signed-off-by: Paolo Bonzini
---
...-fast-cpus.json => qemum
All supported versions of QEMU include the query-cpus-fast QMP command.
In preparation for dropping support for the old "query-cpus" commands,
remove the query-cpus version of the x86-full test.
Signed-off-by: Paolo Bonzini
---
...qemumonitorjson-cpuinfo-x86-full-cpus.
results of QEMU monitor commands have to be converted as well.
Thanks,
Paolo
Paolo Bonzini (7):
tests: remove duplicate cpuinfo test
tests: drop "-fast" from query-cpus-fast tests
tests: convert ppc64 tests to query-cpus-fast
tests: convert x86_64 tests to query-cpus-fast
tests: re
On 7/22/22 17:43, Martin Kletzander wrote:
As mentioned before, all these failures do not have to exit the
function, but rather fallback to the old way. You can even create
two new functions for the new and old implementations and then call
them from here to make the fallback easier to spot
On 5/17/22 10:34, Thomas Huth wrote:
This remains, and that's fine. One step at time.
Not sure how we want to proceed with that in the long run, though ...
IIRC clearly, Paolo once said that it doesn't really belong into
"-display" anyway and should be handled with the separate "-vnc"
On 4/25/22 10:21, Martin Kletzander wrote:
One thing I am not sure about is whether to keep the aliases of ac97 and
es1370 in the qdev_alias_table.
Signed-off-by: Martin Kletzander
I agree that -soundhw is a bad option, but I think we should preserve
something similarly easy to use. For
On 4/25/22 10:21, Martin Kletzander wrote:
@@ -4188,12 +4188,15 @@ void vnc_display_open(const char *id, Error **errp)
vd->ledstate = 0;
audiodev = qemu_opt_get(opts, "audiodev");
-if (audiodev) {
-vd->audio_state = audio_state_by_name(audiodev);
-if
On 3/25/22 16:35, Michal Prívozník wrote:
I'm fixing all the small issues I've raised in review and pushing these.
Reviewed-by: Michal Privoznik
No, please don't! The property is not yet part of QEMU, this should
have been tagged RFC.
Sorry about the confusion.
Paolo
libparted_dep is not used if -Dstorage_disk=disabled. Do
not bother looking for it if the disk storage backend was not
requested.
Signed-off-by: Paolo Bonzini
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index eb13c7efa4
devmapper_dep and libparted_dep are not used if -Dstorage_disk=disabled. Do
not bother looking for these libraries if the disk storage backend was not
requested.
Signed-off-by: Paolo Bonzini
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b
rbd_dep is not used if -Dstorage_rbd=disabled. Do not bother looking for
the libraries that compose it if the rbd storage backend was not requested.
Signed-off-by: Paolo Bonzini
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
QEMU 7.0.0 adds a new property tsc-clear-on-reset to x86 CPU, corresponding
to Libvirt's element. Plumb it in the validation,
command line handling and tests.
Signed-off-by: Paolo Bonzini
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h
monitor_control.enable_softResetClearTSC as well.
Signed-off-by: Paolo Bonzini
---
docs/formatdomain.rst | 4
src/conf/domain_conf.c| 22 ++
src/conf/domain_conf.h| 10 ++
src/conf/schemas/domaincommon.rng | 9 +
4 files changed, 45
Some versions of Windows hang on reboot if their TSC value is greater
than 2^54. The workaround is to reset the TSC to a small value, and
is implemented by QEMU and ESXi. This series adds a domain attribute
for this, and implements it in QEMU.
Paolo
Paolo Bonzini (2):
domain: add
Make sure that all tests are run after the helpers and mocks are
(re)built. This enables for example using "meson test" as the
command line passed to "git bisect run".
Signed-off-by: Paolo Bonzini
---
tests/meson.build | 9 +
1 file changed, 5 insertions(+), 4 dele
On 3/2/22 18:42, Daniel P. Berrangé wrote:
Overall I'm just not seeing enough benefit to justify the
disruption we'll cause by making this change to existing
system emulator binaries.
I agree.
Paolo
On 2/21/22 10:36, Michal Prívozník wrote:
Indeed. Libvirt's participating on its own since 2016, IIRC. Since we're
still in org acceptance phase we have some time to decide this,
actually. We can do the final decision after participating orgs are
announced. My gut feeling says that it's going to
On 2/18/22 12:39, Michal Prívozník wrote:
On 2/17/22 18:52, Paolo Bonzini wrote:
I would like to co-mentor one or more projects about adding more
statistics to Mark Kanda's newly-born introspectable statistics
subsystem in QEMU
(https://patchew.org/QEMU/20220215150433.2310711-1-mark.ka
On 1/28/22 16:47, Stefan Hajnoczi wrote:
Dear QEMU, KVM, and rust-vmm communities,
QEMU will apply for Google Summer of Code 2022
(https://summerofcode.withgoogle.com/) and has been accepted into
Outreachy May-August 2022 (https://www.outreachy.org/). You can now
submit internship project ideas
On 11/20/21 23:34, Richard Henderson wrote:
On 11/20/21 8:46 AM, Yifei Jiang wrote:
const VMStateDescription vmstate_riscv_cpu = {
.name = "cpu",
.version_id = 3,
.minimum_version_id = 3,
+ .post_load = cpu_post_load,
.fields = (VMStateField[]) {
On 24/09/21 11:04, Kevin Wolf wrote:
We want to switch both from QemuOpts to the keyval parser in the future,
which results in some incompatibilities, mainly around list handling.
Mark the non-JSON version of both as unstable syntax so that management
tools switch to JSON and we can later make
On 22/07/21 10:19, Peter Krempa wrote:
This patch breaks detection of certain machine options features in
libvirt which were being detected from 'query-command-line-options'.
I presume the change simply removed this from the output of
query-command-line-options due to the historical cruft how
On 07/07/21 20:23, Eduardo Habkost wrote:
On Wed, Jul 7, 2021 at 1:18 PM Jim Mattson wrote:
On Wed, Jul 7, 2021 at 10:08 AM Eduardo Habkost wrote:
On Wed, Jul 7, 2021 at 12:42 PM Jim Mattson wrote:
On Wed, Jul 7, 2021 at 8:09 AM Eduardo Habkost wrote:
CCing libvir-list, Jiri
On 15/03/21 12:38, Dr. David Alan Gilbert wrote:
* Kevin Wolf (kw...@redhat.com) wrote:
Am 15.03.2021 um 10:39 hat Markus Armbruster geschrieben:
Paolo Bonzini writes:
On 13/03/21 14:28, Markus Armbruster wrote:
Kevin Wolf writes:
This switches the HMP command object_add from a QemuOpts
On 13/03/21 14:28, Markus Armbruster wrote:
Kevin Wolf writes:
This switches the HMP command object_add from a QemuOpts-based parser to
user_creatable_add_from_str() which uses a keyval parser and enforces
the QAPI schema.
Apart from being a cleanup, this makes non-scalar properties and help
On 13/03/21 09:41, Markus Armbruster wrote:
Observation, not objection:
1. QMP core parses JSON text into QObject, passes to generated
marshaller.
2. Marshaller converts QObject to ObjectOptions with the QObject input
visitor, passes to qmp_object_add().
3. qmp_object_add() wraps
On 13/03/21 08:40, Markus Armbruster wrote:
+if (!user_creatable_add_from_str(optarg, _err)) {
+if (local_err) {
+error_report_err(local_err);
+exit(2);
+} else {
+/*
On 12/03/21 10:17, Andrew Jones wrote:
On Fri, Mar 12, 2021 at 10:01:43AM +0100, Paolo Bonzini wrote:
On 12/03/21 09:48, Andrew Jones wrote:
I think we definitely need the additional data section here: For KVM on
POWER, it would be good to know whether it's KVM-HV or KVM-PR, for KVM on
MIPS
On 12/03/21 09:48, Andrew Jones wrote:
I think we definitely need the additional data section here: For KVM on
POWER, it would be good to know whether it's KVM-HV or KVM-PR, for KVM on
MIPS it would be good to know whether it's KVM_VM_MIPS_VZ or KVM_VM_MIPS_TE,
for KVM on x86 whether it's the
On 12/03/21 09:14, Markus Armbruster wrote:
Paolo Bonzini writes:
On 11/03/21 15:08, Markus Armbruster wrote:
I would rather keep the OptsVisitor here. Do the same check for JSON
syntax that you have in qobject_input_visitor_new_str, and whenever
you need to walk all -object arguments, use
On 11/03/21 19:33, Daniel P. Berrangé wrote:
On Thu, Mar 11, 2021 at 07:18:54PM +0100, Paolo Bonzini wrote:
On 11/03/21 12:54, Dr. David Alan Gilbert wrote:
* Daniel P. Berrangé (berra...@redhat.com) wrote:
The generic 'migrate_set_parameters' command handle all types of param.
Only the QMP
On 11/03/21 12:54, Dr. David Alan Gilbert wrote:
* Daniel P. Berrangé (berra...@redhat.com) wrote:
The generic 'migrate_set_parameters' command handle all types of param.
Only the QMP commands were documented in the deprecations page, but the
rationale for deprecating applies equally to HMP,
On 11/03/21 15:08, Markus Armbruster wrote:
I would rather keep the OptsVisitor here. Do the same check for JSON
syntax that you have in qobject_input_visitor_new_str, and whenever
you need to walk all -object arguments, use something like this:
typedef struct ObjectArgument {
On 11/03/21 11:38, Markus Armbruster wrote:
Here's a differently terrible hack. We have
keyval_parse() visitor
optarg > QObject > QAPI type
Idea: hack the QObject. If we're working for -object, and QObject maps
key "qom-type" to value
On 11/03/21 09:45, Kevin Wolf wrote:
I think it's only patch 29 and 30 that we would have to drop, actually.
Unfortunately, that still removes one of the most immediately useful
features, which is non-scalar properties for -object in the system
emulator. But of course, a lot better than not
On 11/03/21 08:47, Peter Krempa wrote:
And for an interleaved list:
-object
memory-backend-ram,id=ram-node2,size=24578621440,host-nodes=1-2,host-nodes=5,host-nodes=7,policy=bind
Uhm, I doubt this works? I would have expected "host-nodes=1-2,,5,,7"
instead.
Paolo
On 10/03/21 18:30, Kevin Wolf wrote:
Am 10.03.2021 um 15:31 hat Paolo Bonzini geschrieben:
On 10/03/21 15:22, Peter Krempa wrote:
I've stumbled upon a regression with this patchset applied:
error: internal error: process exited while connecting to monitor:
qemu-system-x86_64: -object
memory
On 10/03/21 15:22, Peter Krempa wrote:
I've stumbled upon a regression with this patchset applied:
error: internal error: process exited while connecting to monitor:
qemu-system-x86_64: -object
memory-backend-ram,id=pc.ram,size=1048576000,host-nodes=0,policy=bind: Invalid
parameter type for
On 01/03/21 12:54, Kevin Wolf wrote:
Please add a check in object_property_add_child that the id is well formed
(using the id_wellformed function). This is pre-existing, but it becomes a
regression for -object later in the series.
Are the conditions for internally called
On 24/02/21 14:52, Kevin Wolf wrote:
+v = qobject_output_visitor_new();
+visit_type_ObjectOptions(v, NULL, , _abort);
+visit_complete(v, );
+visit_free(v);
+
+props = qobject_to(QDict, qobj);
+qdict_del(props, "qom-type");
+qdict_del(props, "id");
+
+v =
On 24/02/21 14:11, Daniel P. Berrangé wrote:
This was replaced by the '-device usb-DEV' option.
Signed-off-by: Daniel P. Berrangé
This is probably used in many tutorial as "-usbdevice tablet" (for
example https://wiki.gentoo.org/wiki/QEMU/Options).
Paolo
---
docs/system/deprecated.rst
On 24/02/21 14:11, Daniel P. Berrangé wrote:
The following features have been deprecated for well over the 2
release cycle we promise
``-usbdevice`` (since 2.10.0)
``-drive file=3Djson:{...{'driver':'file'}}`` (since 3.0)
``-vnc acl`` (since 4.0.0)
``-mon
On 23/02/21 10:06, Markus Armbruster wrote:
Markus, did you rebuild the qtests after disabling single-quoted
strings? "make check-qtest-x86_64" would have rebuilt them, but I'm
confused by the results.
I ran "make check" and looked at the failures:
Still confused?
Yes. What's the patch
On 22/02/21 18:54, Daniel P. Berrangé wrote:
These are sent to QEMU as double-quoted strings (the single-quoted JSON is
parsed to get interpolation and printed back; commit 563890c7c7, "libqtest:
escape strings in QMP commands, fix leak", 2014-07-01). However, doing the
interpolation requires a
On 22/02/21 16:24, Daniel P. Berrangé wrote:
This problem isn't unique to QEMU. Any app using JSON from the
shell will have the tedium of quote escaping. JSON is incredibly
widespread and no other apps felt it neccessary to introduce single
quoting support, because the benefit doesn't outweigh
On 22/02/21 15:57, Markus Armbruster wrote:
* The block layer's pseudo-protocol "json:" (which can get embedded in
image headers)
If it gets embedded in image headers, I don't think we'll be able to
deprecate it ever. We'd need to keep a converter for old images, at
which point it's
On 03/02/21 09:40, Han Han wrote:
Hi Paolo,
I find there is no warning for the nolazy_refcounts option(qemu
v5.2.0-1530-g74208cd252):
$ qemu-img create /tmp/b.qcow2 -f qcow2 10M -o nolazy_refcounts
Formatting '/tmp/b.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off
compression_type=zlib
On 26/01/21 04:55, Han Han wrote:
Since the commit ccd3b3b811 of QEMU, the short-form boolean options in
qemu cmdline like "server", "nowait", "disable-ticketing" are
deprecated
There are a few more:
1) -vnc password, -vnc tls, -vnc sasl:
if (graphics->data.vnc.auth.passwd ||
On 11/01/21 10:38, Daniel P. Berrangé wrote:
The "-machine" options for accelerators are legacy, the "-accel" options
is a better mechanism. The following are the details:
https://lore.kernel.org/qemu-devel/3aa73987-40e8-3619-0723-9f17f7385...@redhat.com/
This patch switch the option "-machine
On 11/01/21 10:27, Jiri Denemark wrote:
We use a fallback for capabilities probing (in qemuProcessQMPLaunch) so
in case the old -machine type,accel=... way is going to be deprecated,
Most likely not. We've gotten better at making the "old ways" just
syntactic sugar for the "new ways" without
On 11/01/21 09:35, Ján Tomko wrote:
This unfortunately cannot be done unconditionally. You need to probe
for the availability of -accel, using something like
What are we probing for?
Existence of "-accel". "-accel" allows configuration of
accelerator-specific, machine-independent
On 09/01/21 19:58, huang...@chinatelecom.cn wrote:
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 6f970a3..9a64473 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6711,40 +6711,6 @@ qemuBuildMachineCommandLine(virCommandPtr cmd,
On 10/12/20 16:58, Thomas Huth wrote:
Remove some simple CLI parameters that have been deprecated since
at least two releass already.
Philippe Mathieu-Daudé (1):
accel/tcg: Remove deprecated '-tb-size' option
Thomas Huth (3):
docs/system: Move the list of removed features to a separate
On 03/12/20 18:52, Eduardo Habkost wrote:
On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
On 03/12/20 16:15, Kevin Wolf wrote:
I don't think this is an intermediate state like Eduardo wants to have.
Creating the object, then setting properties, then realize [1] will fail
after
On 03/12/20 18:43, Kevin Wolf wrote:
I think I'd want to do step 2 and 3 combined, because converting
user-creatable objects to oc->configure means manually writing the
configure function that will be generated from QAPI in step 3. Writing
code just to throw it away isn't my favourite pastime.
On 03/12/20 16:15, Kevin Wolf wrote:
I don't think this is an intermediate state like Eduardo wants to have.
Creating the object, then setting properties, then realize [1] will fail
after your change. But keeping it working was the whole point of the
exercise.
With the sample code, you must
On 02/12/20 18:35, Kevin Wolf wrote:
Could we have an intermediate state that doesn't require any
duplication and thus have no separate code paths that could
diverge?
The one requirement we have for an intermediate state is that it
supports both interfaces: The well-know create/set
On 02/12/20 13:51, Eduardo Habkost wrote:
I'm liking the direction this is taking. However, I would still
like to have a clearer and feasible plan that would work for
-device, -machine, and -cpu.
-cpu is not a problem since it's generally created with a static
configuration (now done with
On 02/12/20 11:27, Kevin Wolf wrote:
Declaring read-only QOM properties is trivial.
Trivial sounds like it's something the computer should be doing.
Possibly, but not necessarily. There's always a cost to automatic code
generation. If things are _too_ trivial and easy to get right, the
On 02/12/20 11:38, Kevin Wolf wrote:
Am 02.12.2020 um 10:30 hat Paolo Bonzini geschrieben:
On 01/12/20 23:08, Eduardo Habkost wrote:
Properties are only a useful concept if they have a use. If
-object/object_add/object-add can do the same job without properties,
properties are not needed
On 01/12/20 23:08, Eduardo Habkost wrote:
Properties are only a useful concept if they have a use. If
-object/object_add/object-add can do the same job without properties,
properties are not needed anymore.
Do you mean "not needed for -object anymore"? Properties are
still used by internal C
On 01/12/20 20:35, Kevin Wolf wrote:
Am 01.12.2020 um 18:16 hat Paolo Bonzini geschrieben:
I don't think this is actually a new things. We already have types and
commands declared with things like 'if': 'defined(TARGET_S390X)'.
As far as I understand, QAPI generated files are already built per
On 01/12/20 17:20, Kevin Wolf wrote:
Am 30.11.2020 um 20:35 hat Paolo Bonzini geschrieben:
For devices it's just the practical issue that there are too many to have
something like this series. For machine types the main issue is that the
version-specific machine types would have to be defined
On 30/11/20 19:10, Kevin Wolf wrote:
Am 30.11.2020 um 17:57 hat Paolo Bonzini geschrieben:
The main problem is that it wouldn't extend well, if at all, to
machines and devices. So those would still not be integrated into the
QAPI schema.
What do you think is the biggest difference
On 30/11/20 16:46, Kevin Wolf wrote:
Am 30.11.2020 um 15:58 hat Paolo Bonzini geschrieben:
With this series it's basically pointless to have QOM properties at
all.
Not entirely, because there are still some writable properties that can
be changed later on.
Are there really any
On 30/11/20 16:30, Daniel P. Berrangé wrote:
{ 'struct': 'QCryptoSecretCommon',
'base': 'Object',
'state': { 'rawdata': '*uint8_t',
'rawlen': 'size_t' },
'data': { '*format': 'QCryptoSecretFormat',
'*keyid': 'str',
'*iv': 'str' } }
{ 'struct':
On 30/11/20 13:25, Kevin Wolf wrote:
+##
+# @IothreadProperties:
+#
+# Properties for iothread objects.
+#
+# @poll-max-ns: the maximum number of nanoseconds to busy wait for events.
+# 0 means polling is disabled (default: 32768 on POSIX hosts,
+# 0 otherwise)
+#
+#
On 30/11/20 13:25, Kevin Wolf wrote:
This series adds a QAPI type for the properties of all user creatable
QOM types and finally makes QMP object-add use the new ObjectOptions
union so that QAPI introspection can be used for user creatable objects.
After this series, there is least one obvious
n build directory
and the logs are not accessible. So switch from "ninja dist"
to "meson dist --no-tests" after a separate build step that
is shared by the normal and the DIST=skip cases.
Signed-off-by: Paolo Bonzini
---
v1->v2: only do it for new-enough distros
e logs are not accessible. So switch from "ninja dist"
to "meson dist --no-tests" after a separate build step that
is shared by the normal and the DIST=skip cases.
Signed-off-by: Paolo Bonzini
---
For an example see
https://gitlab.com/bonzini/libvirt/-/pipelines/221
On 17/11/20 20:34, Stefan Weil wrote:
Fix also a similar typo in a code comment.
Signed-off-by: Stefan Weil
---
docs/can.txt | 8
docs/interop/vhost-user.rst | 2 +-
docs/replay.txt | 2 +-
docs/specs/ppc-spapr-numa.rst | 2 +-
'
docs/system/deprecated.rst | 6 ++
chardev/char.c | 32
2 files changed, 30 insertions(+), 8 deletions(-)
Even though I disagree with QAPIfying -chardev, this one is obviously a
good thing.
Acked-by: Paolo Bonzini
Paolo
On 21/10/20 12:17, Daniel P. Berrangé wrote:
>> But would it be correct? In order to have the advertised behavior of
>> "enable FIPS compliance just with procfs, no need to do anything in
>> QEMU" you need to disable VNC password authentication; so while
>> fips_set_state is an abomination,
On 21/10/20 10:38, Daniel P. Berrangé wrote:
> On Tue, Oct 20, 2020 at 07:22:03PM +0200, Paolo Bonzini wrote:
>> On 20/10/20 18:22, Daniel P. Berrangé wrote:
>>> @@ -153,6 +153,9 @@ int os_parse_cmd_args(int index, const char *optarg)
>>> break;
&g
On 20/10/20 18:22, Daniel P. Berrangé wrote:
> @@ -153,6 +153,9 @@ int os_parse_cmd_args(int index, const char *optarg)
> break;
> #if defined(CONFIG_LINUX)
> case QEMU_OPTION_enablefips:
> +warn_report("-enable-fips is deprecated, please build QEMU with "
> +
1 - 100 of 769 matches
Mail list logo
