vms->highmem = false;
> +}
Direct checks for *_enabled() are a pain to clean up later when
we add support to new accelerators. Can't this be implemented as
(e.g.) a AccelClass::max_physical_address_bits field?
> +
> /*
> * In accelerated mode, the memory map is computed earlier in kvm_type()
> * to create a VM with the right number of IPA bits.
> --
> 2.24.3 (Apple Git-128)
>
--
Eduardo
> create mode 100644 target/arm/hvf/meson.build
> delete mode 100644 target/i386/hvf/hvf-cpus.c
> delete mode 100644 target/i386/hvf/hvf-cpus.h
>
> --
> 2.24.3 (Apple Git-128)
>
--
Eduardo
inary" is not something you need after
> > startup (or if querying the monitor).
> >
> > Paolo
> >
> >
>
> A script that repeatedly uses the QMP interface to query for
> the status could generate fragmentation this way I think.
Is this a problem? Today, execution of a "query-kvm" command
calls g_malloc() 37 times.
--
Eduardo
never been in CentOS 8, I'm working on it, slowly.
>
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > Cc: Eduardo Habkost
> > Cc: Stefano Stabellini
> > Cc: Anthony Perard
> > Cc: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> >
On Thu, Nov 26, 2020 at 04:34:17PM +0100, Claudio Fontana wrote:
> On 11/26/20 4:14 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 03:55:37PM +0100, Claudio Fontana wrote:
> >> On 11/26/20 3:49 PM, Eduardo Habkost wrote:
> >>> On Thu, Nov 26, 2020 at 03:33:17P
On Thu, Nov 26, 2020 at 03:55:37PM +0100, Claudio Fontana wrote:
> On 11/26/20 3:49 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 03:33:17PM +0100, Claudio Fontana wrote:
> >> On 11/26/20 2:44 PM, Eduardo Habkost wrote:
> >>> On Thu, Nov 26, 2020 at 11:57:28A
On Thu, Nov 26, 2020 at 03:33:17PM +0100, Claudio Fontana wrote:
> On 11/26/20 2:44 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:57:28AM +0100, Claudio Fontana wrote:
> >> On 11/24/20 10:31 PM, Eduardo Habkost wrote:
> >>> On Tue, Nov 24, 2020 at 09:13:1
On Thu, Nov 26, 2020 at 11:57:28AM +0100, Claudio Fontana wrote:
> On 11/24/20 10:31 PM, Eduardo Habkost wrote:
> > On Tue, Nov 24, 2020 at 09:13:13PM +0100, Paolo Bonzini wrote:
> >> On 24/11/20 17:22, Claudio Fontana wrote:
> >>> +stati
On Thu, Nov 26, 2020 at 10:14:31AM +0100, Claudio Fontana wrote:
> Hi Eduardo,
>
> On 11/25/20 9:56 PM, Eduardo Habkost wrote:
> > This function will be used to replace the xen_available() and
> > kvm_available() functions from arch_init.c.
> >
> > Signed-off-by
;(git grep -l arch_init.h | sort) \
<((git grep -l -w 'arch_type'; g grep -l QEMU_ARCH;) | sort -u))
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: "Michael S. Tsirkin"
Cc: Marcel Apfelbaum
Cc: "Hervé Poussineau"
The function can be replaced with accel_available("xen").
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: qemu-devel@nongnu.org
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: xen-de...@lists.xenproject.org
Cc: Richard Henderson
Cc: Claudio Fontana
The only caller can use accel_available("kvm") instead.
Signed-off-by: Eduardo Habkost
---
Cc: Markus Armbruster
Cc: qemu-devel@nongnu.org
Cc: Paolo Bonzini
Cc: k...@vger.kernel.org
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Claudio Fontana
Cc: Roman Bolshakov
---
incl
The only declarations in arch_init.h are related to the arch_type
variable (which is a useful feature that allows us to simplify
command line option handling). Rename the header to reflect its
purpose.
Signed-off-by: Eduardo Habkost
---
Cc: Markus Armbruster
Cc: Kevin Wolf
Cc: Max Reitz
Cc
This function will be used to replace the xen_available() and
kvm_available() functions from arch_init.c.
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Claudio Fontana
Cc: Roman Bolshakov
---
include/sysemu/accel.h | 1 +
accel/accel.c | 5 +
2
...@redhat.com
Eduardo Habkost (6):
arch_init: Move QEMU_ARCH definitions to cpu.h
accel: accel_available() function
kvm: Remove kvm_available() function
xen: Delete xen_available() function
Remove unnecessary usage of arch_init.h
Rename arch_init.h to arch_type.h
include/sysemu/accel.h
Instead of a collection of #ifdefs on arch_init.c, define
QEMU_ARCH inside each cpu.h file.
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: Peter Maydell
Cc: Michael Rolnik
Cc: Sarah Harris
Cc: "Edgar E. Iglesias"
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: Michael
On Wed, Nov 25, 2020 at 07:40:48AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Tue, Nov 24, 2020 at 04:20:37PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Tue, Nov 24, 2020 at 09:49:30AM +0100
On Wed, Nov 25, 2020 at 12:48:22PM +0100, Claudio Fontana wrote:
> On 11/25/20 10:32 AM, Claudio Fontana wrote:
> > On 11/24/20 9:34 PM, Eduardo Habkost wrote:
> >> On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
> >>> On 11/24/20 8:27 PM, Eduardo Hab
-x86.
accel.c can't use cpu.h, correct? We can add a:
CPUClass *arch_base_cpu_type(void)
{
return object_class_by_name(CPU_RESOLVING_TYPE);
}
function to arch_init.c, to allow target-independent code call
target-specific code.
--
Eduardo
On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
> On 11/24/20 8:27 PM, Eduardo Habkost wrote:
> > On Tue, Nov 24, 2020 at 07:52:15PM +0100, Claudio Fontana wrote:
> > [...]
> >>>> +}
> >>>
> >>> Additionally, if you
2 additional lines of code:
- the cpus_register_accel() call
- the x86_cpu_accel_init() call
What makes those 2 lines of code so special, to make them deserve
a completely new mechanism to trigger them, instead of using
trivial function calls inside a accel_init() function?
--
Eduardo
On Tue, Nov 24, 2020 at 07:29:50PM +0100, Claudio Fontana wrote:
> On 11/24/20 6:08 PM, Eduardo Habkost wrote:
> > On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
> >> apply this to the registration of the cpus accel interfaces,
> >>
> >>
el_init(AccelState*)
function and a
void (*init)(AccelState*)
method in AccelClass.
Then the whole code block above would be as trivial as:
accel_init(current_accel());
> +}
[...]
>
--
Eduardo
ize_pre_loadvm = whpx_cpu_synchronize_pre_loadvm,
> +ops->create_vcpu_thread = whpx_start_vcpu_thread;
> +ops->kick_vcpu_thread = whpx_kick_vcpu_thread;
> +
> +ops->synchronize_post_reset = whpx_cpu_synchronize_post_reset;
> +ops->synchronize_post_init = whpx_cpu_synchronize_post_init;
> +ops->synchronize_state = whpx_cpu_synchronize_state;
> +ops->synchronize_pre_loadvm = whpx_cpu_synchronize_pre_loadvm;
> +};
> +static const TypeInfo whpx_cpus_type_info = {
> +.name = CPUS_ACCEL_TYPE_NAME("whpx"),
> +
> +.parent = TYPE_CPUS_ACCEL_OPS,
> +.class_init = whpx_cpus_class_init,
> +.abstract = true,
> };
> +static void whpx_cpus_register_types(void)
> +{
> +type_register_static(_cpus_type_info);
> +}
> +type_init(whpx_cpus_register_types);
> diff --git a/target/i386/whpx/whpx-cpus.h b/target/i386/whpx/whpx-cpus.h
> index bdb367d1d0..2dee6d61ea 100644
> --- a/target/i386/whpx/whpx-cpus.h
> +++ b/target/i386/whpx/whpx-cpus.h
> @@ -12,8 +12,6 @@
>
> #include "sysemu/cpus.h"
>
> -extern const CpusAccel whpx_cpus;
> -
> int whpx_init_vcpu(CPUState *cpu);
> int whpx_vcpu_exec(CPUState *cpu);
> void whpx_destroy_vcpu(CPUState *cpu);
> --
> 2.26.2
>
--
Eduardo
bled()) {
> +cpus_register_accel(_cpus);
> +}
> +}
> +
> +accel_cpu_init(qtest_accel_cpu_init);
I don't understand why this (and the similar changes on other
accelerators) is an improvement.
You are replacing a trivial AccelClass-specific init method with
a module_init() function that has a hidden dependency on runtime
state.
--
Eduardo
; index e7d4effdd0..00166c36e9 100644
> --- a/target/i386/tcg/cpu.c
> +++ b/target/i386/tcg/cpu.c
> @@ -170,12 +170,3 @@ static void tcg_cpu_accel_register_types(void)
> type_register_static(_cpu_accel_type_info);
> }
> type_init(tcg_cpu_accel_register_types);
> -
> -static void tcg_cpu_accel_init(void)
> -{
> -if (tcg_enabled()) {
> -x86_cpu_accel_init(X86_CPU_ACCEL_TYPE_NAME("tcg"));
> -}
> -}
> -
> -accel_cpu_init(tcg_cpu_accel_init);
> --
> 2.26.2
>
--
Eduardo
On Tue, Nov 24, 2020 at 04:20:37PM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Tue, Nov 24, 2020 at 09:49:30AM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Mon, Nov 23, 2020 at 08:51:27AM +0100
Klaus Herman
Reported-by: Geoffrey McRae
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Philippe Mathieu-Daudé
Cc: "Philippe Mathieu-Daudé"
Message-Id: <20201120130409.956956-1-...@redhat.com>
Signed-off-by: Eduardo Habkost
---
hw/core/qdev-properties-system.c | 25 ++
The following changes since commit d536d9578ec3ac5029a70b8126cb84bb6f2124a4:
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into
staging (2020-11-24 10:59:12 +)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git
> > Paolo
>
> Which tree is going to merge this patch?
Sorry, I was expecting Michael to merge it, as it's PCI-specific
but it looks like people were waiting for me to merge it.
I'll merge it and submit a pull request ASAP.
--
Eduardo
int(0), qnum_from_double(0.0))
was undefined.
However, if we really care about test coverage of
qnum_is_equal(), we probably should be extending check-qnum.c,
not check-qlit.c.
--
Eduardo
On Tue, Nov 24, 2020 at 10:51:34AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > Add an array of values to qlit_equal_qobject_test(), so we can
> > extend the test case to compare multiple literals, not just the
> > ones at the existing `qlit`
On Tue, Nov 24, 2020 at 10:58:27AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > Move code that sets the property default value to a separate
> > function, to reduce duplication and make refactoring easier.
> >
> > Signed-off-by: Eduardo Habkost
&
On Tue, Nov 24, 2020 at 09:49:30AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Mon, Nov 23, 2020 at 08:51:27AM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Fri, Nov 20, 2020 at
If .set_default_value is not set, call
object_property_set_default(). This will let us delete most of
the .set_default_value functions later.
Signed-off-by: Eduardo Habkost
---
This is a new patch in v3 of this series.
In v2 of the series, equivalent functionality was implemented by
"qom
The function will be used outside qom/object.c, to simplify the
field property code that sets the property default value.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
include/qom/object.h | 11 +++
qom/object.c | 2 +-
2 files changed, 12 insertions(+), 1
On some cases, the documentation for UUID properties is lying:
properties defined using DEFINE_PROP_UUID_NODEFAULT are not set
to "auto" by default. It's better to omit this instead of
providing incorrect information.
Signed-off-by: Eduardo Habkost
---
This is a new patch ad
Move code that sets the property default value to a separate
function, to reduce duplication and make refactoring easier.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of this series.
Hopefully, this will make the series easier to review.
The field_prop_set_default_value
The field_prop_set_default_value_*int() functions can be
completely replaced by object_propert_set_default(),
we don't need them anymore.
Signed-off-by: Eduardo Habkost
---
This is a new patch in v3 of this series.
In v2 of the series, equivalent changes were part of "qom: Use
qlit to repr
UUID properties were weird because the value of .defval was
completely ignored. Fix this by setting the default value to
QLIT_QSTR("auto") on the default case, and actually using .defval
inside .set_default_value.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of t
Provide a separate QNumValue type that can be used for QNum value
literals without the referencing counting and memory allocation
features provided by QObject.
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3:
* Fixed copy-pasta at qnum_from_value() documentation
* Removed qnum_get_va
Extract the QNum value comparison logic to a function that takes
QNumValue* as argument.
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3:
* Rename function parameters to val_x/val_y
* Insert blank line after variable declarations at
qnum_is_equal()
---
include/qapi/qmp/qnum.h |
set_default_value_bool() can be completely replaced by
object_property_set_default(), we don't need that function
anymore.
Signed-off-by: Eduardo Habkost
---
This is a new patch in v3 of this series.
In v2 of the series, equivalent changes were part of "qom: Use
qlit to represent pro
al type of
.defval is validated before it is used.
Also note that set_default_uuid_auto() is a bit weird: it ignores
.defval completely. This patch keeps the existing behavior, and
set_default_uuid_auto() weirdness will be addressed later.
Signed-off-by: Eduardo Habkost
---
This is a new
Add a few examples of each qlit type, to make sure each one
compare as equal to itself, but not equal to the other values.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of this series.
---
tests/check-qlit.c | 16
1 file changed, 16 insertions(+)
diff
qobject_to() drops const-ness by accident, but our function
arguments (x, y) are const. Make num_x/num_y const too.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of the series.
---
qobject/qnum.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The function can be completely replaced by
object_property_set_default(), we don't need it anymore.
Signed-off-by: Eduardo Habkost
---
This is a new patch in v3 of this series.
In v2 of the series, equivalent changes were part of "qom: Use
qlit to represent property defaults".
---
hw
Rename the existing QLIT_QNUM macro to indicate it only supports
signed int values. We're going to add support to other types of
QNums later.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of this series.
In v2, the existing QLIT_QNUM() macro was being kept, now
Add an array of values to qlit_equal_qobject_test(), so we can
extend the test case to compare multiple literals, not just the
ones at the existing `qlit` and `qlit_foo` variables.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of this series.
---
tests/check-qlit.c | 26
Add two new macros to support other types of QNums:
QLIT_QNUM_UINT, and QLIT_QNUM_DOUBLE, and include them
in the qlit_equal_qobject_test() test case.
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3:
* QLIT_QNUM macro doesn't exist anymore
* Addition of the QNumValue field to QLitObj
qnum_get_double() won't change the object, the argument can be
const.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
include/qapi/qmp/qnum.h | 2 +-
qobject/qnum.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/qapi/qmp/qnum.h b
Currently, qlit_equal_qobject() crashes if getting a QNum that
can't be represented as int64. Fix this by using
qnum_value_is_equal().
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of the series.
---
qobject/qlit.c | 3 ++-
tests/check-qlit.c | 19
Replace the existing int64_t field in QLitObject with QNumValue,
so we can get support for other QNum types for free.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of the series. It includes
portions of a previous patch from v2:
"qlit: Support all types of
review easier
* Small changes in UUID property code (See
"qom: Don't ignore defval on UUID property" and
"qom: Fix documentation of UUID property type")
Changes v1 -> v2:
* Rebase to latest version of field properties series
* Fix unit test failure
* Coding sty
On Mon, Nov 23, 2020 at 08:51:27AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Fri, Nov 20, 2020 at 06:29:16AM +0100, Markus Armbruster wrote:
> [...]
> >> When the structure of a data type is to be kept away from its users, I
> >> pr
On Fri, Nov 20, 2020 at 10:08:46AM +0100, Claudio Fontana wrote:
> On 11/19/20 8:23 PM, Eduardo Habkost wrote:
> > On Thu, Nov 19, 2020 at 09:53:09AM +0100, Claudio Fontana wrote:
> >> Hi,
> >>
> >> On 11/18/20 7:28 PM, Eduardo Habkost wrote:
> >>> O
atm).
>
> static void tcg_accel_cpu_init(void)
> {
> if (tcg_enabled()) {
> TCGState *s = TCG_STATE(current_accel());
>
> if (s->mttcg_enabled) {
> cpus_register_accel(_cpus_mttcg);
> } else if (icount_enabled()) {
> cpus_register_accel(_cpus_icount);
> } else {
> cpus_register_accel(_cpus_rr);
> }
> }
> }
Probably what we are missing here is a non-softmmu-specific
AccelClass.init() method?
--
Eduardo
On Fri, Nov 20, 2020 at 07:47:11PM +0100, Claudio Fontana wrote:
> On 11/20/20 6:44 PM, Eduardo Habkost wrote:
> > On Fri, Nov 20, 2020 at 03:49:09PM +0100, Claudio Fontana wrote:
> >> split cpu.c into:
> >>
> >> cpu.ccpuid and common x86 cpu func
On Fri, Nov 20, 2020 at 06:29:16AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Thu, Nov 19, 2020 at 11:24:52AM +0100, Markus Armbruster wrote:
> >> Marc-André Lureau writes:
> >>
> >> > On Tue, Nov 17, 2020 at 6:42 PM Eduardo Hab
On Fri, Nov 20, 2020 at 07:52:31AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Thu, Nov 19, 2020 at 11:27:40AM +0100, Markus Armbruster wrote:
> > [...]
> >> > +bool qnum_is_equal(const QObject *x, const QObject *y)
> >> > +{
&
On Fri, Nov 20, 2020 at 06:41:35PM +0100, Claudio Fontana wrote:
> On 11/20/20 6:19 PM, Eduardo Habkost wrote:
> > On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
> >> On 11/18/20 11:07 PM, Eduardo Habkost wrote:
> >>> On Wed, Nov 18, 2020 at 08:13:1
6_cpu_accel_init(X86_CPU_ACCEL_TYPE_NAME(chosen_accel_name));
call somewhere in the initialization path.
A good place for the x86_cpu_accel_init() call would be
do_configure_accelerator(), but the function is arch-specific.
That's why I suggested a cpu_accel_arch_init() function at
https://lore.kernel.org/qemu-devel/20201118220750.gp1509...@habkost.net
--
Eduardo
EL)
Yes, and this way we get rid of the only difference between
OBJECT_DECLARE_TYPE and OBJECT_DECLARE_INTERFACE: the instance
type cast macro is a bit different (it uses INTERFACE_CHECK).
--
Eduardo
On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
> On 11/18/20 11:07 PM, Eduardo Habkost wrote:
> > On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
> >> On 18/11/20 18:30, Eduardo Habkost wrote:
> >>>> Adding a layer of indirect
On Thu, Nov 19, 2020 at 01:21:58PM -0500, Eduardo Habkost wrote:
> On Thu, Nov 19, 2020 at 11:24:52AM +0100, Markus Armbruster wrote:
[...]
> > >> > > +return qnum_from_value((QNumValue) QNUM_VAL_INT(value));
> >
> > No space between between (type) and its o
On Thu, Nov 19, 2020 at 09:53:09AM +0100, Claudio Fontana wrote:
> Hi,
>
> On 11/18/20 7:28 PM, Eduardo Habkost wrote:
> > On Wed, Nov 18, 2020 at 11:29:36AM +0100, Claudio Fontana wrote:
> >> split cpu.c into:
> >>
> >> cpu.ccpuid and co
On Thu, Nov 19, 2020 at 07:25:15PM +0100, Paolo Bonzini wrote:
> On 19/11/20 18:55, Eduardo Habkost wrote:
> > On Thu, Nov 19, 2020 at 06:23:30PM +0100, Paolo Bonzini wrote:
> > > On 19/11/20 18:13, Eduardo Habkost wrote:
> > > > > What's left?
> >
On Thu, Nov 19, 2020 at 11:39:14AM +0100, Markus Armbruster wrote:
> Marc-André Lureau writes:
>
> > On Tue, Nov 17, 2020 at 2:48 AM Eduardo Habkost wrote:
> >
> >> Use QNumValue to represent QNums, so we can also support uint64_t
> >> and double QNum values.
On Thu, Nov 19, 2020 at 11:24:52AM +0100, Markus Armbruster wrote:
> Marc-André Lureau writes:
>
> > On Tue, Nov 17, 2020 at 6:42 PM Eduardo Habkost wrote:
> >
> >> On Tue, Nov 17, 2020 at 12:37:56PM +0400, Marc-André Lureau wrote:
> >> > On Tue,
lank line between declarations and statements, please.
I can do it. But why do you prefer it that way?
>
> > +return qnum_value_is_equal(_x->value, _y->value);
> > +}
> > +
> > /**
> > * qnum_destroy_obj(): Free all memory allocated by a QNum object
> > *
--
Eduardo
CCing Peter, Sphinx documentation machinery maintainer.
On Thu, Nov 19, 2020 at 10:37:22AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > Render existing doc comments at docs/devel/qobject.html.
> >
> > Signed
On Thu, Nov 19, 2020 at 11:41:05AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > Useful function where we need to check for the qlit type before
> > converting it to an actual QObject.
> >
> > Signed-off-by: Eduardo Habkost
> > ---
> >
On Thu, Nov 19, 2020 at 06:23:30PM +0100, Paolo Bonzini wrote:
> On 19/11/20 18:13, Eduardo Habkost wrote:
> > > What's left?
> > Enums. Enums properties are a mess to implement, and I plan to
> > tackle them later.
> >
> > On all other cases, the ext
On Thu, Nov 19, 2020 at 01:39:50PM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > Based-on: 20201104160021.2342108-1-ehabk...@redhat.com
> > Git branch:
> > https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-qlit-defaults
> >
> > This ext
dering that the KVM changes might take a
while to be merged.
Would you be able to submit this independently from the rest of
the series? You can add my:
Reviewed-by: Eduardo Habkost
My only (minor) suggestion is to rename
X86MachineClass.hyperv_features to
X86MachineClass.default_hyperv_features.
>
On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
> On 18/11/20 18:30, Eduardo Habkost wrote:
> > > Adding a layer of indirect calls is not very different from monkey
> > > patching
> > > though.
> >
> > I'm a little bothered by monkey pat
vf_cpu_common_class_init(X86CPUClass *xcc)
> +{
> +host_cpu_class_init(xcc);
Why are you calling host_cpu_class_init() for all CPU types?
> +}
[...]
> +static void kvm_cpu_common_class_init(X86CPUClass *xcc)
> +{
> +host_cpu_class_init(xcc);
> +}
Same question as above.
--
Eduardo
On Wed, Nov 18, 2020 at 05:22:46PM +0100, Paolo Bonzini wrote:
> Il mer 18 nov 2020, 17:11 Eduardo Habkost ha scritto:
>
> > On Wed, Nov 18, 2020 at 04:43:19PM +0100, Paolo Bonzini wrote:
> > > Il mer 18 nov 2020, 16:26 Eduardo Habkost ha
> > scritto:
> > &g
On Wed, Nov 18, 2020 at 09:56:28AM -0600, Eric Blake wrote:
> On 11/18/20 9:45 AM, Eduardo Habkost wrote:
> > On Wed, Nov 18, 2020 at 02:53:26PM +0100, Markus Armbruster wrote:
> > [...]
> >> Another way to skin this cat:
> >>
> >>
On Wed, Nov 18, 2020 at 04:43:19PM +0100, Paolo Bonzini wrote:
> Il mer 18 nov 2020, 16:26 Eduardo Habkost ha scritto:
>
> >
> > > The alternative is to store the (type, function) tuple directly, with the
> > > type as a string. Then you can just use type_ini
n be extended with a union to report extra props for the
> > accelerator, discriminated on the 'active' field eg
> >
> > { 'available': [ 'kvm', 'tcg', 'xen' ],
> >'active': 'kvm',
> >'data': {
> >"allow-nested": true,
> >}
> > }
>
> Correct.
--
Eduardo
On Wed, Nov 18, 2020 at 03:51:44PM +0100, Paolo Bonzini wrote:
> On 18/11/20 15:36, Eduardo Habkost wrote:
> > On Wed, Nov 18, 2020 at 03:05:42PM +0100, Paolo Bonzini wrote:
> > > On 18/11/20 14:48, Claudio Fontana wrote:
> > > > On 11/18/20 1:48 PM, Eduardo Habkos
On Wed, Nov 18, 2020 at 03:05:42PM +0100, Paolo Bonzini wrote:
> On 18/11/20 14:48, Claudio Fontana wrote:
> > On 11/18/20 1:48 PM, Eduardo Habkost wrote:
> > > On Wed, Nov 18, 2020 at 11:29:35AM +0100, Claudio Fontana wrote:
> > > > apply this to the registratio
ster_accel(current_machine->accelerator->cpu_accel_ops);
--
Eduardo
re are not many CPU cache
configuration options in qemu-system-x86_64 today, except for
"l3-cache" and "host-cache-info" -cpu options.
>
> Thank you very much, really help me a lot.
No problem!
>
> Sincerely,
> Jack
>
> Eduardo Habkost 於 2020年11月17日 週
On Tue, Nov 17, 2020 at 05:30:04PM +0100, Markus Armbruster wrote:
> John Snow writes:
>
> > OrderedDict is a subtype of dict, so we can check for a more general form.
> >
> > Signed-off-by: John Snow
> > Reviewed-by: Eduardo Habkost
> > Reviewed-by: Cl
On Tue, Nov 17, 2020 at 08:53:19PM +0400, Marc-André Lureau wrote:
> On Tue, Nov 17, 2020 at 7:49 PM Eduardo Habkost wrote:
>
> > On Tue, Nov 17, 2020 at 12:42:47PM +0400, Marc-André Lureau wrote:
> > > On Tue, Nov 17, 2020 at 2:42 AM Eduardo Habkost
> > wrote:
>
On Tue, Nov 17, 2020 at 12:42:47PM +0400, Marc-André Lureau wrote:
> On Tue, Nov 17, 2020 at 2:42 AM Eduardo Habkost wrote:
>
> > Extract the QNum value comparison logic to a function that takes
> > QNumValue* as argument.
> >
> > Signed-off-by: Eduardo Habkost
:4.2-3ubuntu6.8)*
This one isn't expect to have "hmat", as the feature was
introduced in v5.0.0.
> - use apt install qemu
> - E5-2670 * 2, Ubuntu 20.04.1 LTS, kernel: 5.4.0-53-generic, Dell
> PowerEdge-R720
>
> I can't reproduce it here. I've tested both qe
On Tue, Nov 17, 2020 at 12:37:56PM +0400, Marc-André Lureau wrote:
> On Tue, Nov 17, 2020 at 2:43 AM Eduardo Habkost wrote:
>
> > Provide a separate QNumValue type that can be used for QNum value
> > literals without the referencing counting and memory allocation
> > feat
Useful function where we need to check for the qlit type before
converting it to an actual QObject.
Signed-off-by: Eduardo Habkost
---
include/qapi/qmp/qlit.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/qapi/qmp/qlit.h b/include/qapi/qmp/qlit.h
index f9e356d31e..acddb80831
Use QNumValue to represent QNums, so we can also support uint64_t
and double QNum values. Add new QLIT_QNUM_(INT|UINT|DOUBLE)
macros for each case.
The QLIT_QNUM() macro is being kept for compatibility with
existing code, but becomes just a wrapper for QLIT_QNUM_INT().
Signed-off-by: Eduardo
Using QLitObject lets us get rid of most of the
.set_default_value functions, and just use
object_property_set_default() directly.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Instead of initializing defval to QLIT_QNULL
by default, just check for QTYPE_NONE, to find out if .def
rid of most type-specific .set_default_value
functions for QOM property types.
Changes v1 -> v2:
* Rebase to latest version of field properties series
* Fix unit test failure
* Coding style changes
Eduardo Habkost (8):
qobject: Include API docs in docs/devel/qobject.html
qnum: M
The function will be used outside qom/object.c, to simplify the
field property code that sets the property default value.
Signed-off-by: Eduardo Habkost
---
include/qom/object.h | 11 +++
qom/object.c | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git
Render existing doc comments at docs/devel/qobject.html.
Signed-off-by: Eduardo Habkost
---
docs/devel/index.rst | 1 +
docs/devel/qobject.rst | 11 +
include/qapi/qmp/qnum.h| 4 +++-
include/qapi/qmp/qobject.h | 48 +-
qobject/qnum.c
qnum_get_double() won't change the object, the argument can be
const.
Signed-off-by: Eduardo Habkost
---
include/qapi/qmp/qnum.h | 2 +-
qobject/qnum.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/qapi/qmp/qnum.h b/include/qapi/qmp/qnum.h
index
Provide a separate QNumValue type that can be used for QNum value
literals without the referencing counting and memory allocation
features provided by QObject.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Fix "make check" failure, by updating check-qnum unit test to
Extract the QNum value comparison logic to a function that takes
QNumValue* as argument.
Signed-off-by: Eduardo Habkost
---
include/qapi/qmp/qnum.h | 1 +
qobject/qnum.c | 29 +++--
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/include/qapi
e want to duplicate the list of accelerators in the QAPI
schema, or should we wait for a generic solution that works for
any QOM type?
> [...] Even better would be
> returning an array of KvmInfo with information on all supported
> accelerators at once, rather than making the user call this command once
> per name.
Maybe. It would save us the work of answering the question
above, but is this (querying information for all accelerators at
once) going to be a common use case?
--
Eduardo
601 - 700 of 11839 matches
Mail list logo
