On Mon, 29 Jan 2024 17:44:56 +0100
Philippe Mathieu-Daudé wrote:
> Mechanical patch produced running the command documented
> in scripts/coccinelle/cpu_env.cocci_template header.
commenting here since, I'm not expert on coccinelle scripts.
On negative side we are permanently loosing type
On Tue, 21 Nov 2023 22:10:28 +
Volodymyr Babchuk wrote:
> From: Oleksandr Tyshchenko
>
> The bridge is needed for virtio-pci support, as QEMU can emulate the
> whole bridge with any virtio-pci devices connected to it.
>
> This patch provides a flexible way to configure PCIe brige
On Wed, 18 Oct 2023 09:32:47 +0100
David Woodhouse wrote:
> On Wed, 2023-10-18 at 09:32 +0200, Igor Mammedov wrote:
> > On Mon, 16 Oct 2023 16:19:08 +0100
> > David Woodhouse wrote:
> >
> > > From: David Woodhouse
> > >
> >
> &g
On Mon, 16 Oct 2023 16:19:08 +0100
David Woodhouse wrote:
> From: David Woodhouse
>
is this index a user (guest) visible?
> There's no need to force the user to assign a vdev. We can automatically
> assign one, starting at xvda and searching until we find the first disk
> name that's unused.
On Tue, 17 Jan 2023 09:50:23 -0500
Chuck Zmudzinski wrote:
> On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> > On Mon, 16 Jan 2023 13:00:53 -0500
> > Chuck Zmudzinski wrote:
> >
> > > On 1/16/23 10:33, Igor Mammedov wrote:
> > > > On Fri, 13 Jan 20
On Tue, 17 Jan 2023 09:43:52 -0500
Chuck Zmudzinski wrote:
> On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> > On Mon, 16 Jan 2023 13:00:53 -0500
> > Chuck Zmudzinski wrote:
> >
> > > On 1/16/23 10:33, Igor Mammedov wrote:
> > > > On Fri, 13 Jan 20
On Fri, 20 Jan 2023 05:55:11 -0800
"Srivatsa S. Bhat" wrote:
> Hi Igor and Thomas,
>
> Thank you for your review!
>
> On 1/19/23 1:12 PM, Thomas Gleixner wrote:
> > On Mon, Jan 16 2023 at 15:55, Igor Mammedov wrote:
> >> "Srivatsa S. Bhat&qu
On Mon, 16 Jan 2023 13:00:53 -0500
Chuck Zmudzinski wrote:
> On 1/16/23 10:33, Igor Mammedov wrote:
> > On Fri, 13 Jan 2023 16:31:26 -0500
> > Chuck Zmudzinski wrote:
> >
> >> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> >> > On Thu, 12 Jan 2023 23:
On Mon, 16 Jan 2023 13:00:53 -0500
Chuck Zmudzinski wrote:
> On 1/16/23 10:33, Igor Mammedov wrote:
> > On Fri, 13 Jan 2023 16:31:26 -0500
> > Chuck Zmudzinski wrote:
> >
> >> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> >> > On Thu, 12 Jan 2023 23:
On Fri, 13 Jan 2023 16:31:26 -0500
Chuck Zmudzinski wrote:
> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> > On Thu, 12 Jan 2023 23:14:26 -0500
> > Chuck Zmudzinski wrote:
> >
> >> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> >> > On Thu, Jan 12,
On Sun, 15 Jan 2023 22:01:34 -0800
"Srivatsa S. Bhat" wrote:
> From: "Srivatsa S. Bhat (VMware)"
>
> Under hypervisors that support mwait passthrough, a vCPU in mwait
> CPU-idle state remains in guest context (instead of yielding to the
> hypervisor via VMEXIT), which helps speed up wakeups
On Thu, 12 Jan 2023 23:14:26 -0500
Chuck Zmudzinski wrote:
> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:
> >> I think the change Michael suggests is very minimalistic: Move the if
> >> condition around
On Thu, 28 Jul 2022 15:17:49 +0800
Huang Rui wrote:
> Hi Igor,
>
> Appreciate you for the reply!
>
> On Wed, Jul 27, 2022 at 04:19:30PM +0800, Igor Mammedov wrote:
> > On Tue, 26 Jul 2022 15:27:07 +0800
> > Huang Rui wrote:
> >
> > > Hi Anthon
On Tue, 26 Jul 2022 15:27:07 +0800
Huang Rui wrote:
> Hi Anthony and other Qemu/Xen guys,
>
> We are trying to enable venus on Xen virtualization platform. And we would
> like to use the backend memory with memory-backend-memfd,id=mem1,size=4G
> options on QEMU, however, the QEMU will tell us
FILES...
>
> Signed-off-by: Markus Armbruster
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Cédric Le Goater
> Reviewed-by: Alex Bennée
> Acked-by: Dr. David Alan Gilbert
for */i386/*
Reviewed-by: Igor Mammedov
nit:
possible miss, see below
[...]
> diff --gi
On Mon, 14 Dec 2020 12:24:18 -0500
Eduardo Habkost wrote:
> 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
>
On Fri, 11 Dec 2020 17:05:27 -0500
Eduardo Habkost wrote:
> 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
Reviewed-by: Igor Mammedov
> ---
> Changes
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
> qdev_property_set() instead.
>
> The check is being added as a separate function
> (qdev_prop_allow_set()) because it
;UPPERCASE);
>
> Signed-off-by: Eduardo Habkost
for x86/virtio/hostmem/QOM
Acked-by: Igor Mammedov
> ---
> Cc: "Marc-André Lureau"
> Cc: Gerd Hoffmann
> Cc: "Michael S. Tsirkin"
> Cc: "Daniel P. Berrangé"
> Cc:
d to upstream
> coccinelle?
>
> I used spatch 1.0.8 with:
>
> -I include --include-headers \
> --macro-file scripts/cocci-macro-file.h \
> --keep-comments --indent 4
>
> Regards,
>
> Phil.
>
> Based-on: <20200304153311.22959-1-phi...@redhat.com&g
On Wed, 12 Dec 2018 16:00:06 +0400
Marc-André Lureau wrote:
> Hi
> On Mon, Dec 10, 2018 at 8:55 PM Igor Mammedov wrote:
> >
> > On Mon, 10 Dec 2018 17:45:22 +0100
> > Igor Mammedov wrote:
> >
> > > On Tue, 4 Dec 2018 18:20:11 +0400
> > > M
rom a GPtrArray.
>
> Signed-off-by: Marc-André Lureau
other than static leak looks fine, considering that we already
leak compat_props, it doesn't really matter, so:
Reviewed-by: Igor Mammedov
> ---
> include/hw/qdev-core.h | 10 ++
> include/qom/object.h | 3 +++
On Mon, 10 Dec 2018 17:45:22 +0100
Igor Mammedov wrote:
> On Tue, 4 Dec 2018 18:20:11 +0400
> Marc-André Lureau wrote:
>
> > Instead of registering compat properties as globals, let's keep them
> > in their own array, to avoid mixing with user global
On Tue, 4 Dec 2018 18:20:11 +0400
Marc-André Lureau wrote:
> Instead of registering compat properties as globals, let's keep them
> in their own array, to avoid mixing with user globals.
>
> Introduce object_apply_global_props() function, to apply compatibility
> properties from a GPtrArray.
>
On Tue, 27 Nov 2018 13:27:48 +0400
Marc-André Lureau wrote:
> Introduce object_apply_global_props() function, to apply compatibility
> properties from a GPtrArray.
>
> For accel compatibility properties, apply them during
> device_post_init(), after accel_register_compat_props() has set them.
>
On Tue, 27 Nov 2018 00:02:35 +0400
Marc-André Lureau wrote:
> Hi
> On Mon, Nov 26, 2018 at 5:27 PM Igor Mammedov wrote:
> >
> > On Wed, 7 Nov 2018 16:36:48 +0400
> > Marc-André Lureau wrote:
> >
> > > It's now possible to use the common function.
>
On Thu, 22 Nov 2018 00:57:21 +0100
Samuel Ortiz wrote:
> On Fri, Nov 16, 2018 at 05:02:26PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:43 +0100
> > Samuel Ortiz wrote:
> >
> > > In order to decouple ACPI APIs from specific machine types, we are
On Thu, 22 Nov 2018 00:21:06 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Thu, Nov 15, 2018 at 01:36:58PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:35 +0100
> > Samuel Ortiz wrote:
> >
> > > From: Yang Zhong
> > >
> > &
On Thu, 22 Nov 2018 00:27:33 +0100
Samuel Ortiz wrote:
> On Thu, Nov 15, 2018 at 02:28:54PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:38 +0100
> > Samuel Ortiz wrote:
> >
> > > This is the standard way of building SRAT on x86 platfoms. But fu
On Wed, 7 Nov 2018 16:36:38 +0400
Marc-André Lureau wrote:
> Hi,
>
> During "[PATCH v2 05/10] qom/globals: generalize
> object_property_set_globals()" review, Eduardo suggested to rework the
> GlobalProperty handling, so that -global is limited to QDev only and
> we avoid mixing the machine
On Wed, 7 Nov 2018 16:36:48 +0400
Marc-André Lureau wrote:
> It's now possible to use the common function.
>
> Teach object_apply_global_props() to warn if Error argument is NULL.
>
> Signed-off-by: Marc-André Lureau
> ---
> hw/core/qdev-properties.c | 24 ++--
>
On Wed, 7 Nov 2018 16:36:46 +0400
Marc-André Lureau wrote:
> A step towards being able to call object_apply_global_props().
it also makes code more uniform as we don't have to deal with type
inform of GList.
maybe move it at the beginning of series and include accel part as well?
otherwise
On Wed, 7 Nov 2018 16:36:45 +0400
Marc-André Lureau wrote:
> Considering that CPU features are provided via command line, the
I can guess what it is about once I recall how -cpu foo,+-feat works,
but without that knowledge I don't get meaning behind the sentence.
Could you rephrase it?
>
On Wed, 7 Nov 2018 16:36:40 +0400
Marc-André Lureau wrote:
> Interfaces don't have instance, let's make the interface type really
> abstract to avoid confusion.
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Igor Mammedov
> ---
> include/hw/acpi/acpi_d
On Wed, 7 Nov 2018 16:36:44 +0400
Marc-André Lureau wrote:
> Machine & Accel props are not provided by user. Let's not mix them
> with the global properties.
>
> Call a new helper function object_apply_global_props() during
> device_post_init().
>
> Add a stub for current_machine, so
On Thu, 22 Nov 2018 00:12:17 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Wed, Nov 14, 2018 at 11:55:37AM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:34 +0100
> > Samuel Ortiz wrote:
> >
> > > From: Yang Zhong
> > >
> &g
On Wed, 21 Nov 2018 16:43:12 +0100
Samuel Ortiz wrote:
> On Tue, Nov 13, 2018 at 04:59:18PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:33 +0100
> > Samuel Ortiz wrote:
> >
> > > This is going to be needed by the hardware reduced impleme
On Wed, 21 Nov 2018 15:42:11 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Thu, Nov 08, 2018 at 03:16:23PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:28 +0100
> > Samuel Ortiz wrote:
> >
> > > XSDT is the 64-bit version of the legacy ACPI
On Wed, 21 Nov 2018 15:42:37 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Fri, Nov 09, 2018 at 03:23:16PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:24 +0100
> > Samuel Ortiz wrote:
> >
> > > ACPI tables are platform and machine type
On Wed, 21 Nov 2018 15:38:16 +0100
Samuel Ortiz wrote:
> Igor,
>
> On Wed, Nov 21, 2018 at 03:15:26PM +0100, Igor Mammedov wrote:
> > On Wed, 21 Nov 2018 07:35:47 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Mon, Nov 19, 2018 at 04:31:10P
On Wed, 21 Nov 2018 07:35:47 -0500
"Michael S. Tsirkin" wrote:
> On Mon, Nov 19, 2018 at 04:31:10PM +0100, Igor Mammedov wrote:
> > On Fri, 16 Nov 2018 17:37:54 +0100
> > Paolo Bonzini wrote:
> >
> > > On 16/11/18 17:29, Igor Mammedov wrote:
>
On Tue, 20 Nov 2018 19:54:23 +0100
Laszlo Ersek wrote:
> On 11/20/18 17:33, Igor Mammedov wrote:
> > On Wed, 7 Nov 2018 16:36:40 +0400
> > Marc-André Lureau wrote:
> >
> >> Interfaces don't have instance, let's make the interface type really
&g
On Wed, 7 Nov 2018 16:36:43 +0400
Marc-André Lureau wrote:
> The function is only used by a test, move it there.
>
> Signed-off-by: Marc-André Lureau
> Reviewed-by: Eduardo Habkost
Reviewed-by: Igor Mammedov
> ---
> include/hw/qdev-properties.h | 1 -
> hw/c
t doesn't apply to current HEAD anymore
>
> Signed-off-by: Marc-André Lureau
> Reviewed-by: Igor Mammedov
> ---
> include/qom/object_interfaces.h | 4 ++--
> hw/misc/ivshmem.c | 2 +-
> hw/virtio/virtio-rng.c | 2 +-
> qom/object.c
On Wed, 7 Nov 2018 16:36:40 +0400
Marc-André Lureau wrote:
> Interfaces don't have instance, let's make the interface type really
> abstract to avoid confusion.
>
> Signed-off-by: Marc-André Lureau
> ---
> include/hw/acpi/acpi_dev_interface.h | 6 +-
> include/hw/arm/linux-boot-if.h
-type.prop5=105 not used
> warning: global nondevice-type.prop6 has invalid class name
>
> Clarify the function return value.
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Igor Mammedov
> ---
> tests/test-qdev-global-props.c | 12 ++--
> 1 file changed, 6
On Mon, 19 Nov 2018 18:14:26 +0100
Paolo Bonzini wrote:
> On 19/11/18 16:31, Igor Mammedov wrote:
> > I've tried to give suggestions how to restructure series
> > on per patch basis. In my opinion it quite possible to split
> > series in several smaller ones and
On Mon, 19 Nov 2018 18:02:53 +
"Boeuf, Sebastien" wrote:
> On Mon, 2018-11-19 at 16:37 +0100, Igor Mammedov wrote:
> > On Fri, 16 Nov 2018 19:42:08 +
> > "Boeuf, Sebastien" wrote:
> >
> > >
> > > Hi Igor,
> >
On Mon, 19 Nov 2018 13:27:14 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Nov 08, 2018 at 03:16:23PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:28 +0100
> > Samuel Ortiz wrote:
> >
> > > XSDT is the 64-bit version of the legacy ACPI R
On Fri, 16 Nov 2018 19:42:08 +
"Boeuf, Sebastien" wrote:
> Hi Igor,
>
> On Fri, 2018-11-16 at 10:39 +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:42 +0100
> > Samuel Ortiz wrote:
> >
> > >
> > > From: Sebastien Boeuf
On Fri, 16 Nov 2018 17:37:54 +0100
Paolo Bonzini wrote:
> On 16/11/18 17:29, Igor Mammedov wrote:
> > General suggestions for this series:
> > 1. Preferably don't do multiple changes within a patch
> > neither post huge patches (unless it's pure code movement)
On Mon, 5 Nov 2018 02:40:23 +0100
Samuel Ortiz wrote:
> This patch set provides an ACPI code reorganization in preparation for
> adding a shared hardware-reduced ACPI API to QEMU.
>
> The changes are coming from the NEMU [1] project where we're defining
> a new x86 machine type: i386/virt.
On Mon, 5 Nov 2018 02:40:43 +0100
Samuel Ortiz wrote:
> In order to decouple ACPI APIs from specific machine types, we are
> creating an ACPI builder interface that each ACPI platform can choose to
> implement.
> This way, a new machine type can re-use the high level ACPI APIs and
> define some
On Mon, 5 Nov 2018 02:40:45 +0100
Samuel Ortiz wrote:
All remaining patches a bit out of proper order,
they should be around patch 12/24 where you started to touch MCFG code.
> For building the MCFG table, we need to track a given machine
> type PCI host pointer, and we can't get it from the
along with find_i440fx(), it might be worth to mention
in this commit message. Something along lines that ACPI PCIHP
exist to support guests without SHPC support on PCI
based PC machine. Considering that Q35 provides native
PCI-E hotplug, there is no need to add ACPI hotplug there.
On Mon, 5 Nov 2018 02:40:41 +0100
Samuel Ortiz wrote:
> It is going to be used by the PC machine type as the MADT table builder
> method and thus needs to be exported outside of acpi-build.c
>
> Also, now that the generic build_madt() API is exported, we have to
> rename the ARM static one in
On Mon, 5 Nov 2018 02:40:38 +0100
Samuel Ortiz wrote:
> This is the standard way of building SRAT on x86 platfoms. But future
> machine types could decide to define their own custom SRAT build method
> through the ACPI builder methods.
> Moreover, we will also need to reach build_srat() from
t; it to memory-device.h instead.
>
> Signed-off-by: Samuel Ortiz
not sure it belong to this series, but regardless where it end-ups
Reviewed-by: Igor Mammedov
> ---
> include/hw/i386/pc.h | 1 -
> include/hw/mem/memory-device.h | 2 ++
> hw/i386/acpi-build.c
On Mon, 5 Nov 2018 02:40:35 +0100
Samuel Ortiz wrote:
> From: Yang Zhong
>
> The ACPI MCFG getter is not x86 specific and could be called from
> anywhere within generic ACPI API, so let's export it.
So far it's x86 or more exactly q35 specific thing,
for example it won't work with arm/virt
On Mon, 5 Nov 2018 02:40:34 +0100
Samuel Ortiz wrote:
> From: Yang Zhong
>
> The AML build routines for the PCI host bridge and the corresponding
> DSDT addition are neither x86 nor PC machine type specific.
> We can move them to the architecture agnostic hw/acpi folder, and by
> carrying all
On Mon, 5 Nov 2018 02:40:33 +0100
Samuel Ortiz wrote:
> This is going to be needed by the hardware reduced implementation, so
> let's export it.
> Once the ACPI builder methods and getters will be implemented, the
> acpi_get_pci_host() implementation will become hardware agnostic.
>
>
On Mon, 5 Nov 2018 02:40:32 +0100
Samuel Ortiz wrote:
> The PCI hole properties are not pc or i386 specific. They belong to the
> PCI host header instead.
>
> Signed-off-by: Samuel Ortiz
> ---
> include/hw/i386/pc.h | 5 -
> include/hw/pci/pci_host.h | 6 ++
> 2 files changed, 6
On Mon, 5 Nov 2018 02:40:25 +0100
Samuel Ortiz wrote:
> This is going to be needed by the Hardware-reduced ACPI routines.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Tested-by: Philippe Mathieu-Daudé
> Signed-off-by: Samuel Ortiz
the patch is probably misplaced withing series,
if there is an
On Mon, 5 Nov 2018 02:40:24 +0100
Samuel Ortiz wrote:
> ACPI tables are platform and machine type and even architecture
> agnostic, and as such we want to provide an internal ACPI API that
> only depends on platform agnostic information.
>
> For the x86 architecture, in order to build ACPI
On Mon, 5 Nov 2018 02:40:30 +0100
Samuel Ortiz wrote:
> From: Yang Zhong
>
> Most of the AML build routines under acpi-build are not even
> architecture specific. They can be moved to the more generic hw/acpi
> folder where they could be shared across machine types and
> architectures.
I'd
On Mon, 5 Nov 2018 02:40:36 +0100
Samuel Ortiz wrote:
> CPU and memory ACPI hotplug are not necessarily handled through SCI
> events. For example, with Hardware-reduced ACPI, the GED device will
> manage ACPI hotplug entirely.
> As a consequence, we make the CPU and memory specific events AML
>
On Thu, 8 Nov 2018 15:16:23 +0100
Igor Mammedov wrote:
[...]
> patch 4: convert arm's impl. to build_append_int_noprefix() API (commit
> 5d7a334f7)
>... move out to aml-build.c
my mistake, generally when we move something out,
we should do it in separate path preferabl
On Mon, 5 Nov 2018 02:40:26 +0100
Samuel Ortiz wrote:
> For both x86 and ARM architectures, the internal RSDP build API can
> return void as the current return value is unused.
>
> Signed-off-by: Samuel Ortiz
Reviewed-by: Igor Mammedov
> ---
> hw/arm/virt-acpi-build.c |
o value ^
>
> Signed-off-by: Yang Zhong
Reviewed-by: Igor Mammedov
I suggest to put this patch at the beginning of the series
before reference tables in test are updated.
> ---
> hw/acpi/memory_hotplug.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
&g
On Mon, 5 Nov 2018 02:40:28 +0100
Samuel Ortiz wrote:
> XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
> Description Table). RSDT only allow for 32-bit addressses and have thus
> been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and
> no longer RSDTs,
On Mon, 5 Mar 2018 13:29:15 +0100
Igor Mammedov <imamm...@redhat.com> wrote:
> On Thu, 15 Feb 2018 01:28:38 -0300
> Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
>
> > It ease code review, unit is explicit.
> >
> > Signed-off-by:
}
>
> -#define HOLE_640K_START (640 * 1024)
> -#define HOLE_640K_END (1024 * 1024)
> +#define HOLE_640K_START (640 * K_BYTE)
> +#define HOLE_640K_END (1024 * K_BYTE)
nit:
could be 1 * M_BYTE
[...]
Reviewed-by: Igor Mammedov <imamm...@redhat.com>
72 matches
Mail list logo
