Hi Thomas, (and also ping Markus) ;-)
> > > > vfio_ap_unregister_irq_notifier(VFIOAPDevice *vapdev,
> > > > static void vfio_ap_realize(DeviceState *dev, Error **errp)
> > > > {
> > > > + ERRP_GUARD();
> > > > int ret;
> > > > Error *err = NULL;
> > >
> > > Now this function
On Thu, Feb 29, 2024 at 01:51:16PM -0600, Eric Blake wrote:
> Date: Thu, 29 Feb 2024 13:51:16 -0600
> From: Eric Blake
> Subject: Re: [PATCH 03/16] block: Fix missing ERRP_GUARD() for
> error_prepend()
>
> On Thu, Feb 29, 2024 at 12:37:10AM +0800, Zhao Liu wrote:
On Thu, Feb 29, 2024 at 02:48:44PM -0600, Eric Blake wrote:
> Date: Thu, 29 Feb 2024 14:48:44 -0600
> From: Eric Blake
> Subject: Re: [PATCH 08/16] block/qcow2: Fix missing ERRP_GUARD() for
> error_prepend()
>
> On Thu, Feb 29, 2024 at 12:37:15AM +0800, Zhao Liu wrote:
Hi Thomas,
> > void s390_realize_cpu_model(CPUState *cs, Error **errp)
> > {
> > +ERRP_GUARD();
> > Error *err = NULL;
>
> I think that function could use an additional clean-up now: Remove the local
> "err" variable and use "errp" only instead.
>
Since many cases check @err to
> Hyper-V is a role you can enable in various Windows versions, both
> server and client. When enabled, you get a hypervisor (which is called
> 'Microsoft Hypervisor' as I was told) and your Windows becomes the root
> partition (similar to Xen Dom0). In case you run this on KVM, Windows
> becomes
Hi Vitaly,
On Tue, Mar 05, 2024 at 05:42:04PM +0100, Vitaly Kuznetsov wrote:
> Date: Tue, 5 Mar 2024 17:42:04 +0100
> From: Vitaly Kuznetsov
> Subject: [PATCH RESEND v3 3/3] docs/system: Add recommendations to Hyper-V
> enlightenments doc
>
> While hyperv.rst already has all currently
Hi Philippe,
> In a previous community call, Zhao asked us how his work will scale
> in the heterogeneous context.
>
> My first idea is CPUs must belong to a cluster.
Thank you for considering this!
At present, cluster is a arch-specific topology level used by ARM.
So maybe we need call this
On Thu, Mar 07, 2024 at 07:22:10AM +0100, Thomas Huth wrote:
> Date: Thu, 7 Mar 2024 07:22:10 +0100
> From: Thomas Huth
> Subject: Re: [PATCH 02/14] hw/core/machine-smp: Deprecate unsupported
> "parameter=1" SMP configurations
>
> On 06/03/2024 10.53, Zhao L
Hi Thomas,
> > /*
> > - * config: -smp 512
> > + * config: -smp 4096
> >* The test machine should tweak the supported max CPUs to
> > - * 511 (MAX_CPUS - 1) for testing.
> > + * 4095 (MAX_CPUS - 1) for testing.
> >*/
> > -
Hi Philippe,
On Tue, Mar 05, 2024 at 02:42:04PM +0100, Philippe Mathieu-Daudé wrote:
> Date: Tue, 5 Mar 2024 14:42:04 +0100
> From: Philippe Mathieu-Daudé
> Subject: [PATCH-for-9.1 02/18] hw/usb/hcd-xhci: Enumerate xhci_flags
> setting values
> X-Mailer: git-send-email 2.41.0
>
> xhci_flags
From: Zhao Liu
The "parameter=0" SMP configurations have been marked as deprecated
since v6.2.
For these cases, -smp currently returns the warning and adjusts the
zeroed parameters to 1 by default.
Remove the above compatibility logic in v9.0, and return error directly
if any -smp
From: Zhao Liu
The q35 machine is trying to support up to 4096 vCPUs [1], so it's
necessary to bump max_cpus in test-smp-parse to 4096 to cover the
topological needs of future machines.
[1]:
https://lore.kernel.org/qemu-devel/20240228143351.3967-1-anisi...@redhat.com/
Signed-off-by: Zhao Liu
From: Zhao Liu
Currently, -smp supports 2 more new levels: book and drawer.
It is necessary to consider the effects of book and drawer in the test
cases to ensure that the calculations are correct. This is also the
preparation to add new book and drawer test cases.
Signed-off-by: Zhao Liu
From: Zhao Liu
Although book was introduced to -smp along with drawer by s390 machine,
as a general topology level in QEMU that may be reused by other arches
in the future, it is desirable to cover this parameter's parsing in a
separate case.
Signed-off-by: Zhao Liu
Tested-by: Xiaoling Song
From: Zhao Liu
SMPConfiguration initializes its int64_t members as 0 by default.
Therefore, in machine_parse_smp_config(), initialize local topology
variables with SMPConfiguration's members directly.
Suggested-by: Prasad Pandit
Signed-off-by: Zhao Liu
---
hw/core/machine-smp.c | 18
From: Zhao Liu
Use MAX_CPUS/MIN_CPUS macros in invalid topology case. This gives us the
flexibility to change the maximum and minimum CPU limits.
Signed-off-by: Zhao Liu
Tested-by: Xiaoling Song
Reviewed-by: Thomas Huth
---
tests/unit/test-smp-parse.c | 22 ++
1 file
From: Zhao Liu
In machine_parse_smp_config(), the number of total CPUs is calculated
by:
drawers * books * sockets * dies * clusters * cores * threads
To avoid missing the future new topology level, use a local variable to
cache the calculation result so that total CPUs are only calculated
From: Zhao Liu
Currentlt, it was allowed for users to specify the unsupported
topology parameter as "1". For example, x86 PC machine doesn't
support drawer/book/cluster topology levels, but user could specify
"-smp drawers=1,books=1,clusters=1".
This is meaningle
From: Zhao Liu
Hi all,
To make review easier, I've merged my previous single SMP patch [1] and
SMP test series [2] into this series as well.
So this series includes:
* [Patch 1] Remove deprecated "parameter=0" SMP configurations, which
is marked as deprecated in v6.2.
From: Zhao Liu
Since s390 machine supports both "drawers" and "books" in -smp, add the
"drawers" and "books" combination test case to match the actual topology
usage scenario.
Signed-off-by: Zhao Liu
Tested-by: Xiaoling Song
From: Zhao Liu
The smp_props.has_clusters in MachineClass is not a user configured
field, and it indicates if user specifies "clusters" in -smp.
After -smp parsing, other module could aware if the cluster level
is configured by user. This is used when the machine has only 1 clu
From: Zhao Liu
Currently, -smp supports up to 7-levels topology hierarchy:
-drawers/books/sockets/dies/clusters/cores/threads.
Though no machine supports all these 7 levels yet, these 7 levels have
the strict containment relationship and together form the generic CPU
topology representation
From: Zhao Liu
Unsupported "parameter=1" SMP configurations is marked as deprecated,
so drop the related test case.
Signed-off-by: Zhao Liu
---
tests/unit/test-smp-parse.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tests/unit/test-smp-parse.c b/tests/unit/test-smp-par
From: Zhao Liu
Although drawer was introduced to -smp along with book by s390 machine,
as a general topology level in QEMU that may be reused by other arches
in the future, it is desirable to cover this parameter's parsing in a
separate case.
Signed-off-by: Zhao Liu
Tested-by: Xiaoling Song
From: Zhao Liu
The support for "parameter=0" SMP configurations is removed, and QEMU
returns error for those cases.
So add the related test cases to ensure parameters can't accept 0.
Signed-off-by: Zhao Liu
---
tests/unit/test-smp-parse.c | 92 +++
On Wed, Mar 06, 2024 at 10:19:41AM +0530, Prasad Pandit wrote:
> Date: Wed, 6 Mar 2024 10:19:41 +0530
> From: Prasad Pandit
> Subject: Re: [PATCH] hw/core/machine-smp: Remove deprecated "parameter=0"
> SMP configurations
>
> Hello Zhao,
>
> On Wed, 6
Hi Prasad,
> On Tue, 5 Mar 2024 at 12:59, Zhao Liu wrote:
> > After simple test, if user sets maxcpus as 0, the has_maxcpus will be
> > true as well...I think it's related with QAPI code generation logic.
>
> * Right.
>
> [Maybe we digressed a bit in the di
Hi Prasad,
> On Mon, 4 Mar 2024 at 12:19, Zhao Liu wrote:
> > > unsigned maxcpus = config->has_maxcpus ? config->maxcpus : 0;
> >
> > This indicates the default maxcpus is initialized as 0 if user doesn't
> > specifies it.
>
> * 'has_maxcpus' should b
Hi Prasad,
On Mon, Mar 04, 2024 at 11:23:58AM +0530, Prasad Pandit wrote:
> Date: Mon, 4 Mar 2024 11:23:58 +0530
> From: Prasad Pandit
> Subject: Re: [PATCH] hw/core/machine-smp: Remove deprecated "parameter=0"
> SMP configurations
>
> On Mon, 4 Mar 2024 at 10:0
From: Zhao Liu
The "parameter=0" SMP configurations have been marked as deprecated
since v6.2.
For these cases, -smp currently returns the warning and adjusts the
zeroed parameters to 1 by default.
Remove the above compatibility logic in v9.0, and return error directly
if any -smp
-/* Use uin32_t for vendor & device so PCI_ANY_ID expands and cannot match hw
> */
> +/* Use uint32_t for vendor & device so PCI_ANY_ID expands and cannot
> match hw */
It would be better to also change the comment style as:
/*
* Use uint32_t for vendor & device so PCI_ANY_ID expa
On Fri, Mar 01, 2024 at 04:30:51PM +, Alex Bennée wrote:
> Date: Fri, 01 Mar 2024 16:30:51 +
> From: Alex Bennée
> Subject: Re: [PULL 26/29] contrib/plugins: extend execlog to track register
> changes
>
> Zhao Liu writes:
>
> > On Fri, Mar 01, 2024 at 10
On Fri, Mar 01, 2024 at 10:22:08AM +, Alex Bennée wrote:
> Date: Fri, 01 Mar 2024 10:22:08 +
> From: Alex Bennée
> Subject: Re: [PULL 26/29] contrib/plugins: extend execlog to track register
> changes
>
> Zhao Liu writes:
>
> > Hi Alex,
> >
Hi Thomas,
On Fri, Mar 01, 2024 at 08:40:54AM +0100, Thomas Huth wrote:
> Date: Fri, 1 Mar 2024 08:40:54 +0100
> From: Thomas Huth
> Subject: Re: [PATCH 2/8] tests/unit/test-smp-parse.c: Bump max_cpus to 4096
>
> On 18/01/2024 15.48, Zhao Liu wrote:
> > From: Zhao Li
Hi Alex,
I hit the following warnings (with "./configure --enable-werror"):
/qemu/contrib/plugins/execlog.c: In function ‘registers_init’:
/qemu/contrib/plugins/execlog.c:330:17: warning: ‘g_pattern_match_string’ is
deprecated: Use 'g_pattern_spec_match_string' instead
> > diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> > index a63d990e4e8e..1a1c09612271 100644
> > --- a/target/s390x/cpu_models.c
> > +++ b/target/s390x/cpu_models.c
> > @@ -503,6 +503,7 @@ static void error_prepend_missing_feat(const char
> > *name, void *opaque)
> >
> > @@ -220,6 +220,7 @@ static int vhost_scsi_set_workers(VHostSCSICommon *vsc,
> > bool per_virtqueue)
> > static void vhost_scsi_realize(DeviceState *dev, Error **errp)
> > {
> > +ERRP_GUARD();
> > VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
> > VHostSCSICommon *vsc =
> > @@ -832,6 +832,7 @@ static void ivshmem_write_config(PCIDevice *pdev,
> > uint32_t address,
> > static void ivshmem_common_realize(PCIDevice *dev, Error **errp)
> > {
> > +ERRP_GUARD();
> > IVShmemState *s = IVSHMEM_COMMON(dev);
> > Error *err = NULL;
>
> Please remove
> >> You have added drawers, books here. Were they missing before?
> >>
> >
> > ...so yes, I think those 2 parameters are missed at this place.
>
> ok. If there is another revision then add a line about this change in the
> commit message. Otherwise it is fine.
>
> Reviewed-by: Babu Moger
>
Hi Markus,
> > ERRP_GUARD() could avoid the case when @errp is the pointer of
> > error_fatal, the user can't see this additional information, because
>
> Suggest "when @errp is _fatal"
Sure! It's clearer.
> > exit() happens in error_setg earlier than information is added [1].
> >
> > The
> > * Without ERRP_GUARD(), use of the @errp parameter is restricted:
> > * - It must not be dereferenced, because it may be null.
> > - * - It should not be passed to error_prepend() or
> > + * - It should not be passed to error_prepend(), error_vprepend() or
> > * error_append_hint(),
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
Hi list,
This series is the second part to add missing ERRP_GUARD() for
error_prepend(), which is based on my first part:
<20240228163723.1775791-1-zhao1@linux.intel.com> [1]
The @errp's second restriction (in qapi/error) said:
* Without ERRP_GUARD(), use of the
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
Hi Babu,
> > DEF("smp", HAS_ARG, QEMU_OPTION_smp,
> > "-smp
> > [[cpus=]n][,maxcpus=maxcpus][,drawers=drawers][,books=books][,sockets=sockets]\n"
Here the "drawers" and "books" are listed...
> > -"
> > [,dies=dies][,clusters=clusters][,cores=cores][,threads=threads]\n"
Hi JeeHeng,
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index d7cb0f1e49b4..4b5c551fe7f0 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -7582,6 +7582,27 @@ static void x86_cpu_realizefn(DeviceState *dev,
> > Error **errp)
> >
> > #ifndef CONFIG_USER_ONLY
>
Hi JeeHeng,
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 426f71770a84..cb5173927b0d 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -886,6 +886,10 @@ static void machine_get_smp(Object *obj, Visitor *v,
> > const char *name,
> > .has_cores =
Hi JeeHeng,
> > +const char *cpu_topo_to_string(CPUTopoLevel topo)
> > +{
> > +return cpu_topo_descriptors[topo].name;
> > +}
> > +
> > +CPUTopoLevel string_to_cpu_topo(char *str)
>
> Can use const char *str.
Okay, I'll.
> > +{
> > +for (int i = 0; i < ARRAY_SIZE(cpu_topo_descriptors);
Hi Vladimir,
> > Signed-off-by: Zhao Liu
>
> Your actual email is at linux.intel.com, is it all OK?
Yes, I'm used to sending patches from linux.intel.com, and both
addresses are OK.
>
> I'd prefer not to abbreviate copy-before-write in subject, but anyway:
> Reviewed-b
Hi Philippe,
> +/*
> + * Real ICH9 contains a single SMI output line and doesn't broadcast CPUs.
> + * Virtualized ICH9 allows broadcasting upon negatiation with guest, see
> + * commit 5ce45c7a2b.
> + */
> +enum {
> +ICH9_VIRT_SMI_BROADCAST,
> +ICH9_VIRT_SMI_CURRENT,
> +#define
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
Hi list,
This series is the follow-up of my previous @errp related patch set
[1].
The @errp's second restriction (in qapi/error) said:
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend() or
* error_append_hint
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
The error_vprepend() should use ERRP_GUARD() just as the documentation
of ERRP_GUARD() says:
> It must be used when the function dereferences @errp or passes
> @errp to error_prepend(), error_vprepend(), or error_append_hint().
Considering that error_vprepend() is also
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
From: Zhao Liu
As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend
> No need to quote the dereferences in full.
>
> But in cxl_fixed_memory_window_config(), @errp is dereferenced in 2
> places without ERRP_GUARD().
>
> In these two places, we check "*errp", because neither function
>
> would do.
>
> Same for the other commit messages.
>
> Hardly worth
_64-w64-mingw32)
>
> On Tue, 20 Feb 2024 17:25:04 +0800
> Zhao Liu wrote:
>
> > From: Zhao Liu
> >
> > Signed-off-by: Zhao Liu
>
> Hi,
>
> A trivial comment, but also a possibly more significant one about
> whether the defaults are correct
Feb 2024 17:20:25 +0800
> Zhao Liu wrote:
>
> > Hi Jonathan,
> >
> > > Hi Zhao Liu
> > >
> > > I like the scheme. Strikes a good balance between complexity of
> > > description
> > > and systems that actually exist. Sure the
Hi Paolo & Michael,
BTW, may I ask if this series could land in v9.0? ;-)
Thanks,
Zhao
On Tue, Feb 27, 2024 at 06:32:10PM +0800, Zhao Liu wrote:
> Date: Tue, 27 Feb 2024 18:32:10 +0800
> From: Zhao Liu
> Subject: [PATCH v9 00/21] Introduce smp.modules for x86 in QEMU
> X-Mailer
From: Zhao Liu
CPUID[0xB] defines SMT, Core and Invalid types, and this leaf is shared
by Intel and AMD CPUs.
But for extended topology levels, Intel CPU (in CPUID[0x1F]) and AMD CPU
(in CPUID[0x8026]) have the different definitions with different
enumeration values.
Though CPUID
> > > > +if (smp_cache_string_to_topology(ms, config->l1d_cache,
> > > > +>smp_cache.l1d, errp)) {
> > >
> > > Indent is to wrong opening bracket.
> > > Same for other cases.
> >
> > Could you please educate me about the correct style here?
> > I'm unsure if it should be
From: Zhao Liu
Intel CPUs implement module level on hybrid client products (e.g.,
ADL-N, MTL, etc) and E-core server products.
A module contains a set of cores that share certain resources (in
current products, the resource usually includes L2 cache, as well as
module scoped features and MSRs
From: Zhao Liu
At present, the subleaf 0x02 of CPUID[0x1F] is bound to the "die" level.
In fact, the specific topology level exposed in 0x1F depends on the
platform's support for extension levels (module, tile and die).
To help expose "module" level in 0x1F, decouple
From: Zhao Liu
CPUID[0x801D].EAX[bits 25:14] NumSharingCache: number of logical
processors sharing cache.
The number of logical processors sharing this cache is
NumSharingCache + 1.
After cache models have topology information, we can use
CPUCacheInfo.share_level to decide which topology
From: Zhao Liu
The commit 8f4202fb1080 ("i386: Populate AMD Processor Cache Information
for cpuid 0x801D") adds the cache topology for AMD CPU by encoding
the number of sharing threads directly.
>From AMD's APM, NumSharingCache (CPUID[0x801D].EAX[bits 25:14])
means [1]
From: Zhao Liu
Add module_id member in X86CPUTopoIDs.
module_id can be parsed from APIC ID, so also update APIC ID parsing
rule to support module level. With this support, the conversions with
module level between X86CPUTopoIDs, X86CPUTopoInfo and APIC ID are
completed.
module_id can be also
From: Zhao Liu
CPUID[4].EAX[bits 25:14] is used to represent the cache topology for
Intel CPUs.
After cache models have topology information, we can use
CPUCacheInfo.share_level to decide which topology level to be encoded
into CPUID[4].EAX[bits 25:14].
And since with the helper
From: Zhao Liu
Linux kernel (from v6.4, with commit edc0a2b595765 ("x86/topology: Fix
erroneous smp_num_siblings on Intel Hybrid platforms") is able to
handle platforms with Module level enumerated via CPUID.1F.
Expose the module level in CPUID[0x1F] if the machine has more than
From: Zhuocheng Ding
After i386 supports module level, it's time to add the test for module
level's parsing.
Signed-off-by: Zhuocheng Ding
Co-developed-by: Zhao Liu
Signed-off-by: Zhao Liu
Reviewed-by: Yanan Wang
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
From: Zhao Liu
Introduce module-id to be consistent with the module-id field in
CpuInstanceProperties.
Following the legacy smp check rules, also add the module_id validity
into x86_cpu_pre_plug().
Tested-by: Yongwei Ma
Co-developed-by: Zhuocheng Ding
Signed-off-by: Zhuocheng Ding
Signed
From: Zhao Liu
Add "modules" parameter parsing support in -smp.
Suggested-by: Xiaoyao Li
Tested-by: Yongwei Ma
Signed-off-by: Zhao Liu
---
Changes since v8:
* Add module description in qemu_smp_opts.
Changes since v7:
* New commit to introduce module level in -smp.
---
hw/co
From: Zhao Liu
Currently, by default, the cache topology is encoded as:
1. i/d cache is shared in one core.
2. L2 cache is shared in one core.
3. L3 cache is shared in one die.
This default general setting has caused a misunderstanding, that is, the
cache topology is completely equated
From: Zhao Liu
Support module level in i386 cpu topology structure "X86CPUTopoInfo".
Since x86 does not yet support the "modules" parameter in "-smp",
X86CPUTopoInfo.modules_per_die is currently always 1.
Therefore, the module level width in AP
501 - 600 of 1312 matches
Mail list logo
