ne tool.
>
> Therefore, I am asking permission from the current authors of this
> tool to loosen the license. At present, those people are:
>
> - John Snow (me!), 411/609
> - Luiz Capitulino, Author, 97/609
> - Daniel Berrangé, 81/609
> - Eduardo Habkost, 10/609
> - Marc
On Mon, 7 Feb 2022 at 19:05, John Snow wrote:
>
> Eduardo Habkost has left Red Hat and has other daily responsibilities to
> attend to. In order to stop spamming him on every series, remove him as
> "Reviewer" for the python/ library dir and add Beraldo Leal instead.
>
On Thu, Feb 3, 2022 at 11:51 AM Daniel P. Berrangé wrote:
>
> Eduardo has indicated that he no longer has time to be involved in
> a QEMU aintainership role. As one of the more frequent contributors
> of patches and design ideas to seccomp, I'll take over.
>
> Signed-off
ike to retire as the seccomp maintainer. Anyone
who wishes to take over from here is welcome to do so.
Thank you all,
--
Eduardo
On Fri, Jan 28, 2022 at 4:42 PM Daniel P. Berrangé wrote:
>
> Hi Eduardo,
>
> You acked this series, but going through my old git branches I
> just discovered that this never got merged. I guess I was assuming
> you had queued it for a future PULL when you acked it.
>
>
Thanks all, I saw the patch has been merged and is part of rc4. I'm
removing it from the fedora package.
On Fri, Dec 3, 2021 at 9:09 PM Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 12/3/21 2:00 PM, Richard Henderson wrote:
> >> Oh I see, it was indeed replaced by Richard Henderso
On Fri, Dec 3, 2021 at 4:37 PM Richard W.M. Jones wrote:
> On Fri, Dec 03, 2021 at 04:20:23PM -0300, Eduardo Lima wrote:
> > Hi Rich,
> >
> > Can you confirm if the patch you added for qemu in Fedora has still not
> been
> > merged upstream? I could not
On Wed, Dec 1, 2021 at 01:19 Richard Henderson
wrote:
> On 11/30/21 9:47 PM, Eduardo Habkost wrote:
> > * MAINTAINERS: Change my email address (Eduardo Habkost)
> >
> > Eduardo Habkost (1):
> >MAINTAINERS: Change my email address
> >
> > MAINTAINERS
* MAINTAINERS: Change my email address (Eduardo Habkost)
Eduardo Habkost (1):
MAINTAINERS: Change my email address
MAINTAINERS | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--
2.32.0
The ehabk...@redhat.com email address will stop working on
2021-12-01, change it to my personal email address.
Signed-off-by: Eduardo Habkost
Message-Id: <20211129163053.2506734-1-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost
---
MAINTAINERS | 12 ++--
1 file chan
The ehabk...@redhat.com email address will stop working on
2021-12-01, change it to my personal email address.
Signed-off-by: Eduardo Habkost
---
Note: I will probably step down as maintainer of some areas, but
I will do this later because I will need a few weeks to figure
out how much time I
On Tue, Nov 02, 2021 at 07:25:25AM -0400, Michael S. Tsirkin wrote:
> On Tue, Nov 02, 2021 at 09:51:35AM +0100, Philippe Mathieu-Daudé wrote:
> > On 10/26/21 17:11, Eduardo Habkost wrote:
> > > The i440fx and Q35 machine types are both hardcoded to use the
> > > legac
.
> But it seems to me these patches make sense already as a standalone
> cleanup.
>
> Only patch 1 miss a review.
>
> Thanks,
> Damien
>
> v3:
> + standalone series
> + minor tweaks
>
> v2 was part of:
> https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg05683.html
Acked-by: Eduardo Habkost
--
Eduardo
From: Chenyi Qiang
Because core-capability releated features are model-specific and KVM
won't support it, remove the core-capability in CPU model to avoid the
warning message.
Signed-off-by: Chenyi Qiang
Message-Id: <20210827064818.4698-3-chenyi.qi...@intel.com>
Signed-off-by: Edua
I should have flushed the queue a long time ago. Apologies for
taking so long.
A single patch, by now. Probably there are others I missed on
the mailing list, and if necessary I will send another pull
request.
The following changes since commit a92cecba2791cd408d2bca04ce181dc2abaf9695:
Merge
tract hotplug-related functions to qdev-hotplug.c
> hw/core: Restrict hotplug to system emulation
Acked-by: Eduardo Habkost
--
Eduardo
pectively
>
> 001/2:[0001] [FC] 'hw/core/machine: Split out the smp parsing code'
> 002/2:[----] [--] 'tests/unit: Add an unit test for smp parsing'
Acked-by: Eduardo Habkost
--
Eduardo
On Wed, Oct 27, 2021 at 03:43:43AM -0400, Michael S. Tsirkin wrote:
> On Tue, Oct 26, 2021 at 11:10:58AM -0400, Eduardo Habkost wrote:
> > Rename the enums to match the naming style used by QAPI, and to
> > use "32" and "64" instead of "20" and "31
machine type.
This adds a property to allow the choice of SMBIOS entry point
versions For example to opt in to 64-bit SMBIOS entry point:
$QEMU -machine q35,smbios-entry-point-type=64
Based on a patch submitted by Daniel Berrangé.
Signed-off-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
This prepares for exposing the SMBIOS entry point type as a
machine property on x86.
Based on a patch from Daniel P. Berrangé.
Signed-off-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
First version of this code was submitted at:
https://lore.kernel.org/qemu-devel
format
and the actual SMBIOS version reported in the entry point
structure. For example: currently the 32-bit entry point
actually report SMBIOS 2.8 support, not 2.1.
Based on portions of a patch submitted by Daniel P. Berrangé.
Signed-off-by: Eduardo Habkost
---
First version of this code was su
...@redhat.com
https://lore.kernel.org/qemu-devel/20200908165438.1008942-6-berra...@redhat.com
Eduardo Habkost (3):
smbios: Rename SMBIOS_ENTRY_POINT_* enums
hw/smbios: Use qapi for SmbiosEntryPointType
hw/i386: expose a "smbios-entry-point-type" PC machine property
incl
apv would make llabs(LLONG_MIN) not
undefined? We would be calling a function compiled by somebody else
(possibly without -fwrapv).
--
Eduardo
On Wed, Oct 20, 2021 at 10:58:12AM -0400, Michael S. Tsirkin wrote:
> On Wed, Oct 20, 2021 at 10:09:17AM -0400, Eduardo Habkost wrote:
> > On Wed, Oct 20, 2021 at 01:02:24PM +0800, Jason Wang wrote:
> > > On Wed, Oct 20, 2021 at 9:31 AM Jason Wang wrote:
> > > >
>
On Wed, Oct 20, 2021 at 04:58:58PM +0200, BALATON Zoltan wrote:
> On Wed, 20 Oct 2021, Eduardo Habkost wrote:
> > On Mon, Oct 18, 2021 at 12:10:04PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 10/18/21 11:51, BALATON Zoltan wrote:
> > > > On Mon, 18 Oct 2021
On Wed, Oct 20, 2021 at 10:55:59AM -0400, Michael S. Tsirkin wrote:
> On Wed, Oct 20, 2021 at 09:57:37AM -0400, Eduardo Habkost wrote:
> > On Wed, Oct 20, 2021 at 03:41:38AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Oct 19, 2021 at 12:56:11PM -0400, Eduardo Habkost wrote:
&
On Mon, Oct 18, 2021 at 01:37:12PM +0800, Xiaoyao Li wrote:
> On 10/18/2021 11:46 AM, Xiaoyao Li wrote:
> > On 10/16/2021 4:22 AM, Eduardo Habkost wrote:
> > > On Thu, Sep 09, 2021 at 10:41:48PM +0800, Xiaoyao Li wrote:
[...]
> > > > +#define INTEL_PT_DEFAULT_0_E
want to respin
> >> I can fix and take via mips-next.
> >
> > Why not? If it's OK to access other fields why not parent_obj? That
> > avoids the QOM cast PCI_DEVICE(opaque) or PCI_DEVICE(d) after this
> > patch. We know it's a PCIIDEState and h
On Wed, Oct 20, 2021 at 01:02:24PM +0800, Jason Wang wrote:
> On Wed, Oct 20, 2021 at 9:31 AM Jason Wang wrote:
> >
> > On Wed, Oct 20, 2021 at 12:56 AM Eduardo Habkost
> > wrote:
> > >
> > > On Tue, Oct 19, 2021 at 12:13:17PM -0400, Michael S. Tsirkin wr
On Wed, Oct 20, 2021 at 03:41:38AM -0400, Michael S. Tsirkin wrote:
> On Tue, Oct 19, 2021 at 12:56:11PM -0400, Eduardo Habkost wrote:
> > On Tue, Oct 19, 2021 at 12:13:17PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Oct 19, 2021 at 11:29:13AM -0400, Eduardo Habkost wrote:
&
On Tue, Oct 19, 2021 at 12:13:17PM -0400, Michael S. Tsirkin wrote:
> On Tue, Oct 19, 2021 at 11:29:13AM -0400, Eduardo Habkost wrote:
> > On Tue, Oct 19, 2021 at 06:59:09AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Oct 19, 2021 at 11:46:17AM +0100, Stefan Hajnoczi wrote:
&
ause virtio-*-transitional and
virtio-*-non-transitional were brand new QOM types (so there's no
compatibility to be kept with old QEMU versions).
Compat properties referencing "virtio-*-pci" instead of
"virtio-*-pci-base" added after commit f6e501a28ef9 are probably
broken, yes.
--
Eduardo
alloon-pci") ||
> +g_str_equal(props[i].driver, "virtio-serial-pci") ||
> +g_str_equal(props[i].driver, "virtio-9p-pci") ||
> +g_str_equal(props[i].driver, "virtio-net-pci") ||
> +g_str_equal(props[i].driver, "virtio-rng-pci")) {
> +compat_props_add_transitional(arr, &props[i]);
> +}
> }
> }
>
> --
> 2.33.0
>
>
--
Eduardo
> CPUID_7_0_EBX_INTEL_PT, prefix);
Why is use_default_intel_pt necessary? Why can't this function
simply validate whatever is inside env->features[FEAT_14_*]?
> }
> +
> +if ((env->features[FEAT_14_0_ECX] ^ host_feat) & CPUID_14_0_ECX_LIP)
> {
What if CPUID_7_0_EBX_INTEL_PT is not set? What should be the
value of host_feat?
> +warn_report("Cannot configure different Intel PT IP payload
> format than hardware");
> +mark_unavailable_features(cpu, FEAT_7_0_EBX,
> CPUID_7_0_EBX_INTEL_PT, NULL);
> +}
> }
> }
>
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index f5478a169f9a..e6236c371c4f 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1639,6 +1639,7 @@ typedef struct CPUX86State {
> uint32_t cpuid_vendor2;
> uint32_t cpuid_vendor3;
> uint32_t cpuid_version;
> +bool use_default_intel_pt;
> FeatureWordArray features;
> /* Features that were explicitly enabled/disabled */
> FeatureWordArray user_features;
> --
> 2.27.0
>
--
Eduardo
ine CPUID_14_0_EBX_POWER_EVENT (1U << 5)
> +/* Support PSB and PMI Preservation */
> +#define CPUID_14_0_EBX_PSB_PMI_PRESERVATION (1U << 6)
> +
> +/* Tracing can be enabled with IA32_RTIT_CTL.ToPA = 1 */
> +#define CPUID_14_0_ECX_TOPA (1U << 0)
> +/*
> + * ToPA tables can hold any number of output entries, up to the maximum
> allowed
> + * by the MaskOrTableOffset field of IA32_RTIT_OUTPUT_MASK_PTRS
> + */
> +#define CPUID_14_0_ECX_MULTI_ENTRIES(1U << 1)
> +/* Support Single-Range Output scheme */
> +#define CPUID_14_0_ECX_SINGLE_RANGE (1U << 2)
> +/* Support IA32_RTIT_CTL.FabricEn */
> +#define CPUID_14_0_ECX_TRACE_TRANS_SUBSYSTEM(1U << 3)
> /* Packets which contain IP payload have LIP values */
> -#define CPUID_14_0_ECX_LIP (1U << 31)
> +#define CPUID_14_0_ECX_LIP (1U << 31)
>
> /* CLZERO instruction */
> #define CPUID_8000_0008_EBX_CLZERO (1U << 0)
> --
> 2.27.0
>
--
Eduardo
On Thu, Sep 09, 2021 at 10:41:46PM +0800, Xiaoyao Li wrote:
> Some CPUID leaves have meaningful subleaf index. Print the subleaf info
> in feature_word_description for CPUID features.
>
> Signed-off-by: Xiaoyao Li
Reviewed-by: Eduardo Habkost
--
Eduardo
Qiang (2):
> target/i386: Remove split lock detect in Snowridge CPU model
> target/i386: Remove core-capability in Snowridge CPU model
Patch 2/2 queued (patch 1/2 was already merged). Thanks and
apologies for the delay.
--
Eduardo
and
> > > provide compatible .save/.load callbacks. It isn't entirely obvious how
> > > to make this machine-type-dependent, so we came up with a simpler idea
> > > of defining a new device that shares most of the implementation with the
> > > original vhost-user
uires additional information provided in environment variables, we
> +pre-define some generic-fuzz configs in
> ``tests/qtest/fuzz/generic_fuzz_configs.h``. Each config must specify:
[...]
Reviewed-by: Eduardo Habkost
--
Eduardo
arget cannot be referenced.
>
> Signed-off-by: John Snow
Patch 1/2 demonstrates why patch 2/2 is useful.
Reviewed-by: Eduardo Habkost
> ---
> docs/conf.py | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/docs/conf.py b/docs/conf.py
> index ff6e92c6e2e..4d9f5660
.
> +Postcopy migration with shared memory needs explicit support from the
> +other processes that share memory and from QEMU. There are restrictions
> +on the type of memory that userfault can support shared.
Unrelated? Line wrapping change only.
Reviewed-by: Eduardo Habkost # if unrelated line
wrapping changes are dropped
--
Eduardo
On Thu, Sep 16, 2021 at 02:22:48PM -0400, John Snow wrote:
> We're not ready to enforce f-strings everywhere, so just silence this
> new warning.
>
> Signed-off-by: John Snow
Reviewed-by: Eduardo Habkost
--
Eduardo
g that is
currently suppressed. And that will happen only if we are in the
unlikely situation where we have absolutely no information about
the encoding being used by other parts of the system.
Sounds reasonable to me, so:
Reviewed-by: Eduardo Habkost
>
> Signed-off-by: John Snow
&g
of the most negative value is
> undefined.
>
> Signed-off-by: Luis Pires
Reviewed-by: Eduardo Habkost
In case you need to send a new version of the series, I'd suggest
separating this into two patches: creation of the uabs64()
function in host-utils, and then changing the K
On Thu, Aug 26, 2021 at 10:16:26AM +0800, Xiaoyao Li wrote:
> On 8/26/2021 4:48 AM, Eduardo Habkost wrote:
> > On Wed, Aug 25, 2021 at 02:59:37PM +0800, Xiaoyao Li wrote:
> > > Hi Eduardo,
> > >
> > > I have some question regrading Intel PT live migration.
>
On Wed, Aug 25, 2021 at 08:37:17PM +, Luis Fernando Fujita Pires wrote:
> From: Eduardo Habkost
>
> > > Right, that's true of any standard implementation of abs().
> > > I thought about making it return uint64_t, but that could make it
> > > weird fo
On Wed, Aug 25, 2021 at 02:59:37PM +0800, Xiaoyao Li wrote:
> Hi Eduardo,
>
> I have some question regrading Intel PT live migration.
>
> Commit "e37a5c7fa459 (i386: Add Intel Processor Trace feature support)"
> expose Intel PT with a fixed capabilities of CPUID 0x
ing it return uint64_t, but that could make
> it weird for other uses of abs64(), where callers wouldn't
> expect a type change from int64_t to uint64_t. Maybe create a
> separate uabs64() that returns uint64_t? Or is that even
> weirder? :)
Which users of abs64 would expect it to return int64_t?
kvm_pit_update_clock_offset() doesn't seem to.
--
Eduardo
From: Chenyi Qiang
At present, there's no mechanism intelligent enough to virtualize split
lock detection correctly. Remove it in Snowridge CPU model to avoid the
feature exposure.
Signed-off-by: Chenyi Qiang
Message-Id: <20210630012053.10098-1-chenyi.qi...@intel.com>
Signed-off-
rg
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index aebf81d9c98..97e250e8760 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3102,7 +3102,7 @@ static const X86CPUDefinition
The following changes since commit d42685765653ec155fdf60910662f8830bdb2cef:
Open 6.2 development tree (2021-08-25 10:25:12 +0100)
are available in the Git repository at:
https://gitlab.com/ehabkost/qemu.git tags/x86-next-pull-request
for you to fetch changes up to f429dbf8fc526a9cacf531176
rror_fatal);
ptr = memory_region_get_ram_ptr(&pdev->rom);
if (load_image_size(path, ptr, size) < 0) {
error_setg(errp, "failed to load romfile \"%s\"", pdev->romfile);
diff -u -p ./hw/pci-bridge/pci_expander_bridge.c
/tmp/nothing/hw/pci-bridge/pci_expander_bridge.c
--- ./hw/pci-bridge/pci_expander_bridge.c
+++ /tmp/nothing/hw/pci-bridge/pci_expander_bridge.c
@@ -264,7 +264,6 @@ static void pxb_dev_realize_common(PCIDe
goto err_register_bus;
}
-sysbus_realize_and_unref(SYS_BUS_DEVICE(ds), &error_fatal);
if (bds) {
qdev_realize_and_unref(bds, &bus->qbus, &error_fatal);
}
diff -u -p ./softmmu/vl.c /tmp/nothing/softmmu/vl.c
--- ./softmmu/vl.c
+++ /tmp/nothing/softmmu/vl.c
@@ -2189,7 +2189,6 @@ static void qemu_record_config_group(con
assert(!from_json);
keyval_merge(machine_opts_dict, dict, errp);
} else if (g_str_equal(group, "smp-opts")) {
-machine_merge_property("smp", dict, &error_fatal);
} else {
abort();
}
@@ -2309,7 +2308,6 @@ static int do_configure_accelerator(void
object_apply_compat_props(OBJECT(accel));
qemu_opt_foreach(opts, accelerator_set_property,
accel,
- &error_fatal);
ret = accel_init_machine(accel, current_machine);
if (ret < 0) {
--
Eduardo
On Mon, Aug 23, 2021 at 05:31:46PM -0400, Peter Xu wrote:
> On Mon, Aug 23, 2021 at 05:07:03PM -0400, Eduardo Habkost wrote:
> > To give just one example:
> >
> > $ (echo 'info pci';echo quit;) | qemu-system-x86_64 -device virtio-net-pci
> > -device e1000e
On Mon, Aug 23, 2021 at 03:18:51PM -0400, Peter Xu wrote:
> On Mon, Aug 23, 2021 at 02:49:12PM -0400, Eduardo Habkost wrote:
> > On Wed, Aug 18, 2021 at 03:43:18PM -0400, Peter Xu wrote:
> > > QEMU creates -device objects in order as specified by the user's cmdline.
> >
t least ensure devices with the same priority won't be
reordered, just to be safe? (qsort() doesn't guarantee that)
If very few device types have non-default vmsd priority and
devices with the same priority aren't reordered, the risk of
compatibility breakage would be much smaller.
--
Eduardo
t;xhci), "host", OBJECT(s),
> &error_fatal);
If this fails, it's due to programmer error, isn't? Shouldn't we
use &error_abort on that case?
> s->xhci.intr_update = xhci_pci_intr_update;
> s->xhci.intr_raise = xhci_pci_intr_raise;
> if (!qdev_realize(DEVICE(&s->xhci), NULL, errp)) {
> --
> 2.31.1
>
--
Eduardo
On Mon, Aug 23, 2021 at 9:35 AM Markus Armbruster wrote:
>
> Eduardo Habkost writes:
>
> > On Wed, Aug 11, 2021 at 9:44 AM Thomas Huth wrote:
> >>
> >> On 11/08/2021 15.40, Eduardo Habkost wrote:
> >> > On Wed, Aug 11, 2021 at 2:10 AM Thomas Hut
On Fri, Aug 20, 2021 at 01:46:11PM +0800, Yang Zhong wrote:
> The AVX_VNNI feature is not in Cooperlake platform, remove it
> from cpu model.
>
> Signed-off-by: Yang Zhong
Fixes: c1826ea6a052 ("i386/cpu: Expose AVX_VNNI instruction to guest")
Queued, thanks!
--
Eduardo
class code" despite there being a big
> fat warning comment saying why it can't go in a compiled-once
> source file !
Ouch. Sorry about that. :(
>
> Is there a reason to prefer this patch over just reverting
> 1b36e4f5a5de585 ?
I agree with reverting the commit.
--
Eduardo
ave to admit
> I am not well acquainted with it.
QEMU uses getaddrinfo() at inet_parse_connect_saddr() to translate the
string/string pair to a socket address.
Python equivalent:
>> socket.getaddrinfo('localhost', 'ssh')
[(, , 6, '', ('::1', 22,
0, 0)), (, , 17, '',
('::1', 22, 0, 0)), (, ,
132, '', ('::1', 22, 0, 0)), (, , 132, '', ('::1', 22, 0,
0)), (, , 6, '',
('127.0.0.1', 22)), (, ,
17, '', ('127.0.0.1', 22)), (, , 132, '', ('127.0.0.1', 22)),
(, , 132, '',
('127.0.0.1', 22))]
Translating this to the correct arguments to socket.socket() and
socket.socket.connect() seems overly complicated, though.
--
Eduardo
iewed-by: Andrew Jones
Reviewed-by: Cornelia Huck
Message-Id: <20210816024522.143124-2-wangyana...@huawei.com>
Signed-off-by: Eduardo Habkost
---
hw/core/machine.c | 14 ++
qapi/machine.json | 6 +++---
qemu-options.hx | 12 +++-
3 files changed, 24 insertions(+), 8 de
The following changes since commit bd44d64a3879bb6b0ca19bff3be16e0093502fac:
Merge remote-tracking branch
'remotes/thuth-gitlab/tags/pull-request-2021-08-11' into staging (2021-08-15
16:46:23 +0100)
are available in the Git repository at:
https://gitlab.com/ehabkost/qemu.git tags/machine-n
This is a bug fix to be included in case we are going to have a
6.1.0-rc4. I don't think this bug alone should delay the release
of QEMU 6.1.0.
The following changes since commit 703e8cd6189cf699c8d5c094bc68b5f3afa6ad71:
Update version for v6.1.0-rc3 release (2021-08-10 19:08:09 +0100)
are av
lt;20210812175353.4128471-1-berra...@redhat.com>
Signed-off-by: Eduardo Habkost
---
hw/core/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 943974d411c..ab4fca6546a 100644
--- a/hw/core/machine.c
+++ b/hw/core/machi
@@ static void machine_set_smp(Object *obj, Visitor *v,
> const char *name,
> }
>
> mc->smp_parse(ms, config, errp);
> -if (errp) {
> +if (*errp) {
> goto out_free;
> }
>
> --
> 2.31.1
>
--
Eduardo
e missed this before 6.1 soft freeze. I'm queueing
this for 6.2. Thanks!
--
Eduardo
On Wed, Aug 11, 2021 at 9:44 AM Thomas Huth wrote:
>
> On 11/08/2021 15.40, Eduardo Habkost wrote:
> > On Wed, Aug 11, 2021 at 2:10 AM Thomas Huth wrote:
> >>
> >> On 10/08/2021 20.56, Eduardo Habkost wrote:
> >>> On Sat, Aug 07, 2021 at 04:22:42PM +020
On Wed, Aug 11, 2021 at 2:10 AM Thomas Huth wrote:
>
> On 10/08/2021 20.56, Eduardo Habkost wrote:
> > On Sat, Aug 07, 2021 at 04:22:42PM +0200, Markus Armbruster wrote:
> >> Is this intended to be a stable interface? Interfaces intended just for
> >> debugging u
make sure this
patch is in good shape, maybe you could reconsider my suggestion
from a while ago for a single-CPUID-leaf interface, as discussed
at:
https://lore.kernel.org/qemu-devel/20210421201759.utsmhuopdmlhg...@habkost.net/
A single-CPUID-leaf qmp_query_x86_cpuid() function that is
generic and not KVM-specific can probably be implemented in ~5
lines of code.
I'm not against the interface proposed here, but you are surely
going to get more friction and more complexity to deal with.
--
Eduardo
On Sat, Aug 07, 2021 at 04:22:42PM +0200, Markus Armbruster wrote:
> Is this intended to be a stable interface? Interfaces intended just for
> debugging usually aren't.
I don't think we need to make it a stable interface, but I won't
mind if we declare it stable.
>
>
> + error_setg(errp, "Not implemented for non-kvm accel");
> + else
> + error_setg(errp, "VCPU was not initialized yet");
> + return NULL;
> +}
> +
> +for (i = 0; i < cpuid_data_cached->nent; ++i) {
> +kvm_entry = &cpuid_data_cached->entries[i];
> +entry = g_malloc0(sizeof(*entry));
> +entry->in_eax = kvm_entry->function;
> +if (kvm_entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX) {
> +entry->in_ecx = kvm_entry->index;
> +entry->has_in_ecx = true;
> +}
> +entry->eax = kvm_entry->eax;
> +entry->ebx = kvm_entry->ebx;
> +entry->ecx = kvm_entry->ecx;
> +entry->edx = kvm_entry->edx;
> +QAPI_LIST_APPEND(tail, entry);
> +}
> +
> +return head;
> +}
> +
> int kvm_arch_init_vcpu(CPUState *cs)
> {
> struct {
> @@ -1923,6 +1970,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
> if (r) {
> goto fail;
> }
> +if (!cpuid_data_cached) {
> +cpuid_data_cached = g_malloc0(sizeof(cpuid_data));
> +memcpy(cpuid_data_cached, &cpuid_data, sizeof(cpuid_data));
> +}
>
> if (has_xsave) {
> env->xsave_buf_len = sizeof(struct kvm_xsave);
> diff --git a/tests/qtest/qmp-cmd-test.c b/tests/qtest/qmp-cmd-test.c
> index c98b78d033..bd883f7f52 100644
> --- a/tests/qtest/qmp-cmd-test.c
> +++ b/tests/qtest/qmp-cmd-test.c
> @@ -46,6 +46,7 @@ static int query_error_class(const char *cmd)
> { "query-balloon", ERROR_CLASS_DEVICE_NOT_ACTIVE },
> { "query-hotpluggable-cpus", ERROR_CLASS_GENERIC_ERROR },
> { "query-vm-generation-id", ERROR_CLASS_GENERIC_ERROR },
> +{ "query-x86-cpuid", ERROR_CLASS_GENERIC_ERROR },
> { NULL, -1 }
> };
> int i;
> --
> 2.17.1
>
--
Eduardo
gration.h:141:1: type name mismatch: TYPE_MIGRATION vs MIGRATION_OBJ
target/ppc/cpu.h:1253:1: mismatching instance type for PPC_VIRTUAL_HYPERVISOR
(PPCVirtualHypervisor)
target/ppc/cpu_init.c:9090:1: instance type declared here (None)
--
Eduardo
On Tue, Aug 10, 2021 at 02:01:40PM +0200, Juan Quintela wrote:
> Eduardo Habkost wrote:
> > Some typedefs and macros are defined after the type check macros.
> > This makes it difficult to automatically replace their
> > definitions with OBJECT_DECLARE_TYPE.
> >
The new macro will be similar to DECLARE_INSTANCE_CHECKER,
but for interface types (that use INTEFACE_CHECK instead of
OBJECT_CHECK).
Signed-off-by: Eduardo Habkost
---
Changes series v1 -> v2: none
Change series v2 -> v3:
* Rebased on top of
[PATCH for-6.2 00/12] qom: Get rid of all
Replace manual INTERFACE_CHECK macros with
DECLARE_INTERFACE_CHECKER, which is less error prone.
Generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=InterfaceCheckMacro $(g grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
include/hw/acpi/
TYPE_MY_DEVICE)
> - #define MY_DEVICE(void *obj)
> + #define MY_DEVICE(void *obj) \
> OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE)
Oops, nice catch!
However, the code above is already going to be deleted by:
https://lore.kernel.org/qemu-devel/20210729175554.686474-9-ehabk...@redhat.com
--
Eduardo
.kernel.org/qemu-devel/20200916223258.599367-1-ehabk...@redhat.com
v2:
https://lore.kernel.org/qemu-devel/20200917024947.707586-1-ehabk...@redhat.com
Eduardo Habkost (2):
qom: DECLARE_INTERFACE_CHECKER macro
[autoamted] Use DECLARE_INTERFACE_CHECKER macro
include/hw/acpi/acpi_dev_interface.h | 5 ++---
On Sat, Aug 07, 2021 at 10:15:52AM +0200, Philippe Mathieu-Daudé wrote:
> On 8/6/21 11:11 PM, Eduardo Habkost wrote:
> > This series gets rid of all manual usage of OBJECT_CHECK,
> > OBJECT_CLASS_CHECK, and OBJECT_GET_CLASS.
> >
> > All type check macros defined
type checker macros
manually.
Generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: "Marc-André Lureau"
Cc: Paolo Bonzini
Cc: Patrick Venture
Cc: Thomas Huth
Replace typedef + DECLARE_INSTANCE_CHECKER with
equivalent OBJECT_DECLARE_SIMPLE_TYPE macro.
Generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=AddObjectDeclareSimpleType $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: Thomas Huth
Use DECLARE_CLASS_CHECKERS instead of defining the
NPCM7XX_OTP_CLASS and NPCM7XX_OTP_GET_CLASS macros manually.
These changes had to be done manually because the typedef and the
existing macro definitions were in different files.
Signed-off-by: Eduardo Habkost
---
Cc: Havard Skinnemoen
Cc
This automatically convert
DECLARE_INSTANCE_CHECKER/DECLARE_CLASS_CHECKER pairs to
DECLARE_OBJ_CHECKERS.
Generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=AddDeclareObjCheckers $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: H
Replace typedefs + DECLARE_OBJ_CHECKERS with equivalent
OBJECT_DECLARE_TYPE macro.
Generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: John Snow
Cc: Kevin Wol
I'm not documenting every single change in the codeconverter
script because most of that code will be deleted once we finish
the QOM code conversion. This patch updates the script to the
latest version that was used to perform changes in the QOM code.
Signed-off-by: Eduardo Ha
automated removal of typedef lines
will be easier and safer.
Generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: "Marc-André Lureau"
Cc: Paolo Bo
d-off-by: Eduardo Habkost
---
Cc: Havard Skinnemoen
Cc: Tyrone Ting
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
hw/misc/npcm7xx_clk.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/misc/npcm7xx_clk.c b/hw/misc/npcm7xx_clk.c
index da6b14c545d..5247ac
renaming TYPE_ACCEL to TYPE_ACCEL_BASE.
Note that the actual QOM type name is still "accel", because QOM
type names are user-visible and I don't want to make any
user-visible change here.
Signed-off-by: Eduardo Habkost
---
Notes about name alternatives:
I have considered using the name
]')
which will:
- split "typdef struct { ... } TypedefName" declarations
- move the typedefs and #defines above the type check macros
- add missing #include "qom/object.h" lines if necessary
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: &q
\
--pattern=AddNamesToTypedefs $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost
---
Cc: "Marc-André Lureau"
Cc: Paolo Bonzini
Cc: Thomas Huth
Cc: Havard Skinnemoen
Cc: Tyrone Ting
Cc: Vijai Kumar K
Cc: Bastian Koppelmann
Cc: qemu-devel@nongnu.org
Cc: q
There are multiple functions where OBJECT_GET_CLASS or
OBJECT_CLASS_CHECK are being used directly for
DeviceClass/TYPE_DEVICE, instead of the DEVICE_GET_CLASS or
DEVICE_CLASS wrappers. There's no reason to not use the
wrappers, so use them.
Signed-off-by: Eduardo Habkost
---
Cc: "
.431680-1-ehabk...@redhat.com>
https://lore.kernel.org/qemu-devel/20210806023119.431680-1-ehabk...@redhat.com
Based-on: <20210805193431.307761-1-ehabk...@redhat.com>
Based-on: <20210805214739.390613-1-ehabk...@redhat.com>
Based-on: <20210806023119.431680-1-ehabk...@redhat.co
1481978645)
Does anybody more experienced with Win32 have a suggestion on how
to deal with this? Do we really need to include winsock2.h /
windows.h / winuser.h from qemu/osdep.h?
--
Eduardo
We have a SCLPEventsBus struct type defined, but no QOM type
checkers are declared for the type.
Use OBJECT_DECLARE_SIMPLE_TYPE to declare the struct type and
have a SCLP_EVENT_BUS typecast wrapper defined.
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* v1 was previously submitted
On Thu, Aug 05, 2021 at 03:34:29PM -0400, Eduardo Habkost wrote:
> We have a SCLPEventsBus struct type defined, but no QOM type
> checkers are declared for the type.
>
> Use OBJECT_DECLARE_SIMPLE_TYPE to declare the struct type and
> have a SCLP_EVENT_BUS typecast wrapper defined.
signal from the
Generic Watchdog. Rename the enum value to SBSA_GWDT_WS0 to be
more explicit and avoid the name conflict.
Signed-off-by: Eduardo Habkost
---
Cc: Radoslaw Biernacki
Cc: Peter Maydell
Cc: Leif Lindholm
Cc: Shashi Mallela
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
hw
acros duplicate what is already defined by the
OBJECT_DECLARE_TYPE declaration at bcm2836.h. Remove the
redundant declarations.
Signed-off-by: Eduardo Habkost
---
Cc: Philippe Mathieu-Daudé
Cc: Luc Michel
Cc: Peter Maydell
---
hw/arm/bcm2836.c | 9 ++---
1 file changed, 2 insertions(+), 7 del
We have a SCLPEventsBus struct type defined, but no QOM type
checkers are declared for the type.
Use OBJECT_DECLARE_SIMPLE_TYPE to declare the struct type and
have a SCLP_EVENT_BUS typecast wrapper defined.
Signed-off-by: Eduardo Habkost
---
Cc: Richard Henderson
Cc: David Hildenbrand
Cc
OBJECT_CHECK(PciHostState, ..., TYPE_PCI_HOST_BRIDGE) is exactly
what the PCI_HOST_BRIDGE macro does. We can just use the macro
instead of using OBJECT_CHECK manually.
Signed-off-by: Eduardo Habkost
---
Cc: "Michael S. Tsirkin"
Cc: Igor Mammedov
Cc: Paolo Bonzini
Cc: Richard Hen
We have a SCLPEventsBus struct defined, but the struct is not
used at the TypeInfo definition. This works today but will break
silently if anybody adds a new field to SCLPEventsBus.
Set instance_size properly to avoid problems in the future.
Signed-off-by: Eduardo Habkost
---
Cc: Cornelia Huck
Use the SCLP_EVENT_BUS macro instead of manually calling
OBJECT_CHECK.
Signed-off-by: Eduardo Habkost
---
Cc: Cornelia Huck
Cc: Thomas Huth
Cc: Halil Pasic
Cc: Christian Borntraeger
Cc: Richard Henderson
Cc: David Hildenbrand
Cc: qemu-s3...@nongnu.org
Cc: qemu-devel@nongnu.org
---
hw
1 - 100 of 11868 matches
Mail list logo
