Rename the enums to match the naming style used by QAPI. This
will allow us to more easily move the enum to the QAPI schema
later.
Based on portions of a patch submitted by Daniel P. Berrangé.
Signed-off-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
First version of this code
On Fri, Dec 11, 2020 at 05:04:57PM -0500, Eduardo Habkost wrote:
> This code contains the first 32 patches from the series:
>
> Subject: [PATCH v3 00/53] Make qdev static property API usable by any QOM
> type
>
> https://lore.kernel.org/qemu-devel/20201112214350.872250-1-e
On Sat, Dec 12, 2020 at 04:55:23PM +0100, Claudio Fontana wrote:
> From: Eduardo Habkost
>
> since tcg_cpu_ops.h is only included in cpu.h,
> and as a standalone header it is not really useful,
> as tcg_cpu_ops.h starts requiring cpu.h defines,
> enums, etc, as well as (late
On Mon, Dec 14, 2020 at 04:00:59PM +0100, Igor Mammedov wrote:
> On Fri, 11 Dec 2020 17:05:22 -0500
> Eduardo Habkost wrote:
>
> > Support Property.set_default and PropertyInfo.description even if
> > PropertyInfo.create is set.
> >
> > Signed-off-by: Eduard
On Mon, Dec 14, 2020 at 03:25:41PM +0100, Igor Mammedov wrote:
> On Fri, 11 Dec 2020 17:05:12 -0500
> Eduardo Habkost wrote:
>
> > Move the property types and property macros implemented in
> > qdev-properties-system.c to a new qdev-properties-system.h
> > header.
>
On Mon, Dec 14, 2020 at 03:42:48PM +0100, Igor Mammedov wrote:
> On Fri, 11 Dec 2020 17:05:14 -0500
> Eduardo Habkost wrote:
>
> > Use the DEFINE_PROP macro (which will set extra fields in the
> > struct) instead of initializing a Property struct manually.
> >
> &g
On Mon, Dec 14, 2020 at 03:55:30PM +0100, Igor Mammedov wrote:
> On Fri, 11 Dec 2020 17:05:20 -0500
> Eduardo Habkost wrote:
>
> > Every single qdev property setter function manually checks
> > dev->realized. We can just check dev->realized inside
>
to `qom` is just one extra step, but not essential.
On Thu, Nov 12, 2020 at 04:42:57PM -0500, Eduardo Habkost wrote:
> Based-on: 2020183823.283752-1-ehabk...@redhat.com
> Git branch: https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-make-generic
>
> This series refactor the q
Add a test case to ensure array properties are behaving as
expected.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v3 of this series.
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
tests/test-qdev-global-pr
The function will be moved to common QOM code, as it is not
specific to TYPE_DEVICE anymore.
Reviewed-by: Stefan Berger
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Rename to object_field_prop_ptr() instead of object_static_prop_ptr()
---
Cc: Stefan Berger
Cc: Stefano Stabellini
We're just doing pointer math with the device pointer, we can
simply use obj instead.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties.c | 5 ++-
These functions will be moved to be part of QOM, so rename them.
Signed-off-by: Eduardo Habkost
---
Changes v2:
* Rename to field_prop_* instead of object_propinfo_*
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-prop-
The basic property types in qdev-properties.c are not going to be
qdev-specific anymore. Rename the variables to prop_info_*.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Redone patch after moving UUID property to qdev-properties-system.c
---
Cc: Paolo Bonzini
Cc: "Daniel P.
This will make it easier to remove the Property.name field in the
future.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in series v2
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
include/hw/qdev-properties.h | 2 +
Move the variable declaration close to the macro that uses it.
Reviewed-by: Marc-André Lureau
Reviewed-by: Stefan Berger
Signed-off-by: Eduardo Habkost
---
Cc: Stefan Berger
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/tpm/
Support Property.set_default and PropertyInfo.description even if
PropertyInfo.create is set.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Patch redone after changes in the previous patches in the
series
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habk
the plan is to eventually get rid of the
Property.name field.
The declarations for the new functions are being added to
qdev-properties-internal.h, but they will be moved to a QOM
header later.
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3:
* Re-added array-based array registration funct
Returning ObjectProperty* will be useful for new property
registration code that will add additional callbacks
to ObjectProperty after registering it.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Redone patch on top of additional changes in series v2
* Commit message reword
---
This will make it easier to remove Property.name in the future.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in series v2
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties.c | 9 +
1 fi
ed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Removed unused variable at xen_block_set_vdev()
* Redone patch after changes in the previous patches in the
series
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: Kevin Wolf
Cc: Max Reitz
Cc: Paolo Bo
We already get the property name as argument to the property
getter and setters, we don't need to use prop->name. This will
make it easier to remove the Property.name field in the future.
Reviewed-by: Stefan Berger
Signed-off-by: Eduardo Habkost
---
This is a new patch added in series
Instead of duplicating the code that sets name, info, offset,
and does type checking, make DEFINE_PROP accept a variable number
of arguments and reuse it in all DEFINE_PROP_* macros.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Redone after UUID property was moved
---
Cc: Paolo Bonz
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
include/hw/qdev-properties.h | 2 +-
hw/core/qdev-
OM code.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Redone after changes in previous patches in the series
* Renamed functions from static_prop_* to field_prop_*
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
--
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties-system.c | 10 +-
1 file
Move the property types and property macros implemented in
qdev-properties-system.c to a new qdev-properties-system.h
header.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Move UUID property type too, as it was moved to
qdev-properties-system.c in the previous patch
---
audio/audi
Use the DEFINE_PROP macro (which will set extra fields in the
struct) instead of initializing a Property struct manually.
Signed-off-by: Eduardo Habkost
---
This is a new patch added in v2 of the series
---
Cc: Mark Cave-Ayland
Cc: Artyom Tarasenko
Cc: qemu-devel@nongnu.org
---
target/sparc
of error_set_from_qdev_prop_error().
Signed-off-by: Eduardo Habkost
---
This is a new patch added in series v2
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties-system.c | 57
hw
Replace `Property *prop` parameter with `char *name`, to reduce
dependency of getter and setter functions on the Property struct
(which will be changed in following patches).
Signed-off-by: Eduardo Habkost
---
This is a new patch added in series v2
---
Cc: Paolo Bonzini
Cc: "Daniel P. Ber
There are no users of the function outside qdev-properties.c.
Make function static and rename it to get_uint16().
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
include/hw/qdev-properties.h | 2 +-
hw/core/qdev-
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Reviewed-by: Cornelia Huck #s390 parts
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: Cornelia Huck
Cc: Thomas Huth
Cc: Richard Hen
All other qdev property error messages use "."
instead of ".". Change set_size32() for consistency,
and to make the code not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
sparc_set_nwindows() is one of the very few property setters that
don't check dev->realized, and there's no reason for it to be
special. Check dev->realized like the other setters.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Mark Cave-Ayland
Cc: Artyom Tarasen
f-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 12a053e732..67ae19df
while we discuss our long term plans for QOM properties.
Eduardo Habkost (32):
cs4231: Get rid of empty property array
cpu: Move cpu_common_props to hw/core/cpu.c
qdev: Move property code to qdev-properties.[ch]
qdev: Check dev->realized at set_size()
sparc: Check dev->re
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Reviewed-by: Cornelia Huck #s390 parts
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
- Fix build error with CONFIG_XEN
I took the liberty of keeping the Reviewed-by line from
Marc-An
Move everything related to Property and PropertyInfo to
qdev-properties.[ch] to make it easier to refactor that code.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
There's no reason to keep the property list separate from the CPU
class code. Move the variable to hw/core/cpu.c and make it
static.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: qemu-devel@nongnu.org
---
include/hw/core/cpu.h
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: "Daniel P. Berrangé"
Cc: Eduardo Habkost
Cc: qemu-devel@nongnu.org
---
hw/core/qdev-properties.c | 10 ++
1 file changed, 6
An empty props array is unnecessary, we can just not call
device_class_set_props().
Reviewed-by: Marc-André Lureau
Signed-off-by: Eduardo Habkost
---
Cc: Gerd Hoffmann
Cc: qemu-devel@nongnu.org
---
hw/audio/cs4231.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/hw/audio/cs4231.c b
Instance properties make introspection hard and are not shown by
"-object ...,help". Convert them to class properties.
Signed-off-by: Eduardo Habkost
---
Changes v2 -> v3:
* Type of "compare_timeout" was changed to uint64
* Indent fix at "compare_thread"
On Fri, Nov 13, 2020 at 03:04:55AM +, Zhang, Chen wrote:
> Looks good for me, but Qemu still have lots of parts use
> object_property_add, do you have plan to change it?
Thanks!
The plan is to minimize usage of object_property_add(), but
that's a huge task. We're doing it gradually when it
On Wed, Nov 11, 2020 at 01:38:11PM -0500, Eduardo Habkost wrote:
> Class properties make QOM introspection simpler and easier, as it
> doesn't require an object to be instantiated. This series
> converts a few existing object_property_add*() calls to register
> class proper
On Fri, Dec 11, 2020 at 09:31:23AM +0100, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
> Reviewed-by: Alex Bennée
> ---
> target/i386/{ => whpx}/whp-dispatch.h | 0
> target/i386/{ => whpx}/whpx-cpus.h| 0
> target/i386/{ => whpx}/whpx-all.c | 0
> target/i386/{ =>
ert.
>
> This reverts commit aafb21a0b9cea5fa0fe52e68111bb6bd13837a02.
>
> Cc: Paolo Bonzini
> Cc: Daniel P. Berrangé
> Cc: Eduardo Habkost
> Signed-off-by: Markus Armbruster
Reviewed-by: Eduardo Habkost
--
Eduardo
On Fri, Dec 11, 2020 at 07:51:54PM +0100, Claudio Fontana wrote:
> On 12/11/20 7:26 PM, Philippe Mathieu-Daudé wrote:
> > On 12/11/20 7:22 PM, Richard Henderson wrote:
> >> On 12/11/20 12:15 PM, Claudio Fontana wrote:
> >>> Should I return this file to the original state (without the extra
> >>>
The following changes since commit 2ecfc0657afa5d29a373271b342f704a1a3c6737:
Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2020-12-10' into
staging (2020-12-10 17:01:05 +)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git
in guest when the guest LIP status same
with the host.
Signed-off-by: Luwei Kang
Message-Id: <20201202101042.11967-1-luwei.k...@intel.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.h | 4
target/i386/cpu.c | 31 ++-
2 files changed, 34 insertions
of the
launch secret, it cannot access the secret.
Signed-off-by: Tobin Feldman-Fitzthum
Signed-off-by: Eduardo Habkost
Reviewed-by: Daniel P. Berrangé
Reviewed-by: Brijesh Singh
Message-Id: <20201027170303.47550-1-to...@linux.ibm.com>
Signed-off-by: Eduardo Habkost
---
qapi/misc-target.json
for NULL.
Signed-off-by: Ani Sinha
Signed-off-by: Eduardo Habkost
Reviewed-by: Daniel P. Berrangé
Message-Id: <20200921093325.25617-1-...@anisinha.ca>
Signed-off-by: Eduardo Habkost
---
qom/object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/qom/object.c
On Wed, Dec 09, 2020 at 09:24:36PM +0100, Greg Kurz wrote:
> On Wed, 9 Dec 2020 13:26:17 -0500
> Eduardo Habkost wrote:
>
> > On Wed, Dec 09, 2020 at 07:11:40PM +0100, Philippe Mathieu-Daudé wrote:
> > [...]
> > > >>>> @@ -200,7 +199,7 @@ st
On Wed, Dec 09, 2020 at 07:11:40PM +0100, Philippe Mathieu-Daudé wrote:
[...]
> @@ -200,7 +199,7 @@ static void spapr_cpu_core_reset(DeviceState *dev)
> int i;
>
> for (i = 0; i < cc->nr_threads; i++) {
> -spapr_reset_vcpu(sc->threads[i]);
> +
On Wed, Dec 09, 2020 at 09:42:25AM +, Daniel P. Berrangé wrote:
> On Tue, Dec 08, 2020 at 04:20:23PM -0500, Eduardo Habkost wrote:
> > Add command-line option that lets the SMBIOS entry point type to
> > be configured.
> >
> > SMBIOS 3.0 support is necessary
On Tue, Sep 08, 2020 at 05:54:37PM +0100, Daniel P. Berrangé wrote:
> This refactoring prepares for exposing the SMBIOS entry point type as a
> machine property on x86.
>
> Signed-off-by: Daniel P. Berrangé
> ---
[...]
> +##
> +# @SmbiosEntryPointType:
> +#
> +# @2_1: SMBIOS version 2.1
> +#
>
On Wed, Dec 09, 2020 at 03:43:54PM +0100, Claudio Fontana wrote:
> On 12/9/20 10:31 AM, Philippe Mathieu-Daudé wrote:
> > On 12/8/20 8:48 PM, Claudio Fontana wrote:
> >> Signed-off-by: Claudio Fontana
> >> ---
> > ...
> >> diff --git a/include/hw/core/tcg-cpu-ops.h b/include/hw/core/tcg-cpu-ops.h
On Wed, Dec 09, 2020 at 10:50:29AM +, Alex Bennée wrote:
>
> Claudio Fontana writes:
>
> > From: Eduardo Habkost
> >
> > Signed-off-by: Eduardo Habkost
> > [claudio: wrapped in CONFIG_TCG]
> > Signed-off-by: Claudio Fontana
by Seabios. This may be changed once
Seabios starts supporting SMBIOS 3.0 entry points.
Signed-off-by: Eduardo Habkost
---
Laszlo, Philippe: do you know how exactly the value of
PcdSmbiosEntryPointProvideMethod is chosen when running OVMF?
---
hw/smbios/smbios.c | 39
gt; >>>> On Mon, 7 Dec 2020 at 21:26, Eduardo Habkost wrote:
> >>>>> My understanding is that there's no reason for ARM KVM to use
> >>>>> another approach, and that CPUClass.do_interrupt is not really
> >>>>> TCG-specific.
>
On Mon, Dec 07, 2020 at 09:12:34PM +, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 21:06, Claudio Fontana wrote:
> > As I understand it, for the purpose of code separation,
> > we could:
> >
> > 1) skip do_interrupt move to the separate tcg_ops structure, wait until
> > KVM/ARM uses another
On Mon, Dec 07, 2020 at 10:06:55PM +0100, Claudio Fontana wrote:
> On 12/7/20 9:56 PM, Peter Maydell wrote:
> > On Mon, 7 Dec 2020 at 18:28, Eduardo Habkost wrote:
> >> All signs seem to indicate that CPUClass.do_interrupt is
> >> TCG-specific, except for those two l
On Mon, Dec 07, 2020 at 06:07:32PM +, Peter Maydell wrote:
> On Mon, 7 Dec 2020 at 17:49, Eduardo Habkost wrote:
> > arm_v7m_class_init() (used by cortex-* CPU models) overrides it.
> > Those CPU models as "TCG CPUs" in the code, but I don't see what
> > makes
On Mon, Dec 07, 2020 at 09:40:42AM +0100, Claudio Fontana wrote:
> cc->do_interrupt is a TCG callback used in accel/tcg only,
> call instead directly the arm_cpu_do_interrupt for the
> injection of exeptions from KVM, so that
>
> do_interrupt can be exported to TCG-only operations in the
s, having
the accel object as part of the QOM tree is useful. So this has
my:
Reviewed-by: Eduardo Habkost
but we need a commit message that doesn't make people think the
`qom-get` command above will always work.
>
> Also, Eduardo and Claudio earlier had ideas to provide cpu-specific
> accel s
On Fri, Dec 04, 2020 at 07:07:09PM +0100, Claudio Fontana wrote:
> On 12/4/20 7:04 PM, Claudio Fontana wrote:
> > On 12/4/20 6:28 PM, Eduardo Habkost wrote:
> >> On Fri, Dec 04, 2020 at 06:10:49PM +0100, Philippe Mathieu-Daudé wrote:
> >>> On 11/30/20 3:35 AM, Clau
On Fri, Dec 04, 2020 at 05:07:21PM +0100, Paolo Bonzini wrote:
> Il ven 4 dic 2020, 14:54 Claudio Fontana ha scritto:
>
> > On 11/30/20 3:35 AM, Claudio Fontana wrote:
> > > Hi all, this is v7 of the i386 cleanup,
> >
> > This is fairly broken still and I am fixing it up,
> >
> > but a question
On Fri, Dec 04, 2020 at 06:10:49PM +0100, Philippe Mathieu-Daudé wrote:
> On 11/30/20 3:35 AM, Claudio Fontana wrote:
> > From: Eduardo Habkost
> >
> > The TCG-specific CPU methods will be moved to a separate struct,
> > to make it easier to move accel-specific code o
On Fri, Dec 04, 2020 at 06:14:07PM +0100, Philippe Mathieu-Daudé wrote:
> On 11/30/20 3:35 AM, Claudio Fontana wrote:
> > From: Eduardo Habkost
> >
> > Signed-off-by: Eduardo Habkost
> > ---
> > accel/tcg/cputlb.c | 6 +++---
> >
On Thu, Dec 03, 2020 at 07:10:37PM +0100, Paolo Bonzini wrote:
> 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 st
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 your change. But keeping it
On Thu, Dec 03, 2020 at 07:46:29AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > It would be much nicer to do the wrapper the other way round, i.e.
> > setting properties before the device is realized would update a
> > configuration struct and realize would then call .create() with that
> > struct.
On Wed, Dec 02, 2020 at 10:05:50AM +0100, Paolo Bonzini wrote:
> On 01/12/20 19:37, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > The default configuration path /etc/qemu can be overriden with configure
> > options, and the generated documentation used to reflect it.
> >
On Wed, Dec 02, 2020 at 06:35:06PM +0100, Kevin Wolf wrote:
> Am 02.12.2020 um 17:05 hat Eduardo Habkost geschrieben:
> > > > Looks nice as end goal. Then, these are a few questions I would
> > > > have about the transition plan:
> > > >
> &
On Wed, Dec 02, 2020 at 04:17:13PM +0100, Kevin Wolf wrote:
> Am 02.12.2020 um 14:54 hat Eduardo Habkost geschrieben:
> > On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> > > On 02/12/20 13:51, Eduardo Habkost wrote:
> > > > > > I'm liking the d
On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> 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
> >
On Wed, Dec 02, 2020 at 10:30:11AM +0100, Paolo Bonzini wrote:
> 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,
> > > pro
On Tue, Dec 01, 2020 at 10:23:57PM +0100, Paolo Bonzini wrote:
> 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':
patch will make the guest LIP feature configurable and
Intel PT feature can be enabled in guest when the guest LIP
status same with the host.
Signed-off-by: Luwei Kang
Message-Id: <20201014080443.23751-2-luwei.k...@intel.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu
Hi,
Sorry for the long delay in reviewing this. Now that 5.2 is
about to be released, we can try to merge this.
Comments below:
On Wed, Oct 14, 2020 at 04:04:42PM +0800, Luwei Kang wrote:
> The current implementation will extend the CPUID level to 0x14 if
> Intel PT is enabled in the guest(in
On Tue, Dec 01, 2020 at 06:16:14PM +0100, Paolo Bonzini wrote:
> On 01/12/20 17:20, Kevin Wolf wrote:
[...]
> > BlockdevOptions is about external interfaces, not about
> > implementation details. Same thing as QOM properties are external
> > interfaces, not implementation details. There may be
On Fri, Nov 27, 2020 at 08:47:00PM +0100, Claudio Fontana wrote:
> On 11/27/20 8:04 PM, Eduardo Habkost wrote:
[...]
> > Maybe we should rename CPUClass.synchronize_from_tb to
> > CPUClass.tcg_synchronize_from_tb? Maybe we should have a
>
> possibly, yes.
>
> > se
Now that I understand what you are doing here, I have specific
questions about the functions you are moving, below:
On Thu, Nov 26, 2020 at 11:32:14PM +0100, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana
[...]
> @@ -1495,7 +1497,8 @@ static inline uint64_t
On Fri, Nov 27, 2020 at 07:16:25PM +0100, Claudio Fontana wrote:
> On 11/27/20 7:09 PM, Eduardo Habkost wrote:
> > On Fri, Nov 27, 2020 at 06:53:23PM +0100, Claudio Fontana wrote:
> >> On 11/27/20 6:41 PM, Eduardo Habkost wrote:
> >>> On Thu, Nov 26, 2020 at 11:32:18P
On Fri, Nov 27, 2020 at 06:16:27PM +, Peter Maydell wrote:
> On Fri, 27 Nov 2020 at 17:18, Eduardo Habkost wrote:
> > Thanks! Is the data returned by kvm_arm_get_host_cpu_features()
> > supposed to eventually affect the value of id_aa64mmfr0? I don't
> > see
On Fri, Nov 27, 2020 at 06:58:22PM +0100, Claudio Fontana wrote:
> On 11/27/20 6:06 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> >> add a new optional interface to CPUClass,
> >> which allows accelera
On Fri, Nov 27, 2020 at 06:53:23PM +0100, Claudio Fontana wrote:
> On 11/27/20 6:41 PM, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana wrote:
> >> i386 is the first user of AccelCPUClass, allowing to split
> >> cpu.c into:
>
On Thu, Nov 26, 2020 at 11:32:18PM +0100, Claudio Fontana wrote:
> i386 is the first user of AccelCPUClass, allowing to split
> cpu.c into:
>
> cpu.ccpuid and common x86 cpu functionality
> host-cpu.c host x86 cpu functions and "host" cpu type
> kvm/cpu.cKVM x86
On Fri, Nov 27, 2020 at 04:53:59PM +, Peter Maydell wrote:
> On Fri, 27 Nov 2020 at 16:47, Eduardo Habkost wrote:
> > Do you know how the implicitly-accelerator-specific code is
> > implemented? PARange is in id_aa64mmfr0, correct? I don't see
> > any accel-specific
On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> add a new optional interface to CPUClass,
> which allows accelerators to extend the CPUClass
> with additional accelerator-specific initializations.
>
> Signed-off-by: Claudio Fontana
> ---
[...]
> +static void
On Fri, Nov 27, 2020 at 04:38:18PM +, Peter Maydell wrote:
> On Fri, 27 Nov 2020 at 16:26, Eduardo Habkost wrote:
> >
> > On Thu, Nov 26, 2020 at 10:29:01PM +, Peter Maydell wrote:
> > > On Thu, 26 Nov 2020 at 22:14, Eduardo Habkost wrote:
> > > > Dire
On Thu, Nov 26, 2020 at 10:29:01PM +, Peter Maydell wrote:
> On Thu, 26 Nov 2020 at 22:14, Eduardo Habkost wrote:
> >
> > On Thu, Nov 26, 2020 at 10:50:17PM +0100, Alexander Graf wrote:
> > > The Apple M1 only supports up to 36 bits of physical address space. That
&g
On Thu, Nov 26, 2020 at 10:50:15PM +0100, Alexander Graf wrote:
> When kicking another vCPU, we get an OS function that explicitly does that
> for us
> on Apple Silicon. That works better than the current signaling logic, let's
> make
> use of it there.
>
> Signed-off-by: Alexander Graf
> ---
On Thu, Nov 26, 2020 at 10:50:17PM +0100, Alexander Graf wrote:
> The Apple M1 only supports up to 36 bits of physical address space. That
> means we can not fit the 64bit MMIO BAR region into our address space.
>
> To fix this, let's not expose a 64bit MMIO BAR region when running on
> Apple
On Thu, Nov 26, 2020 at 10:50:09PM +0100, Alexander Graf wrote:
> Now that Apple Silicon is widely available, people are obviously excited
> to try and run virtualized workloads on them, such as Linux and Windows.
>
> This patch set implements a rudimentary, first version to get the ball
> going
On Thu, Nov 26, 2020 at 10:06:03PM +0100, Claudio Fontana wrote:
> On 11/26/20 3:25 PM, Paolo Bonzini wrote:
> > On 26/11/20 15:13, Claudio Fontana wrote:
> >> One option I see is simply to document the behavior where
> >> accel_available() is declared in accel.h (ie do not use in fast
> >> path),
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
501 - 600 of 11343 matches
Mail list logo
