In the sanity-check of smp_cpus and max_cpus against mc in function
machine_set_smp(), we are now using ms->smp.max_cpus for the check
but using current_machine->smp.max_cpus in the error message.
Tweak this by uniformly using the local ms.
Signed-off-by: Yanan Wang
Reviewed-by: Andrew Jones
Rev
Since commit 80d7835749 (qemu-options: rewrite help for -smp options),
the preference of sockets/cores in -smp parsing is considered liable
to change, and actually we are going to change it in a coming commit.
So it'll be more stable to use detailed -smp CLIs in the testcases
that have strong depen
Put both sanity-check of the input SMP configuration and sanity-check
of the output SMP configuration uniformly in the generic parser. Then
machine_set_smp() will become cleaner, also all the invalid scenarios
can be tested only by calling the parser.
Signed-off-by: Yanan Wang
Reviewed-by: Andrew
In the real SMP hardware topology world, it's much more likely that
we have high cores-per-socket counts and few sockets totally. While
the current preference of sockets over cores in smp parsing results
in a virtual cpu topology with low cores-per-sockets counts and a
large number of sockets, whic
Currently we directly calculate the omitted cpus based on the given
incomplete collection of parameters. This makes some cmdlines like:
-smp maxcpus=16
-smp sockets=2,maxcpus=16
-smp sockets=2,dies=2,maxcpus=16
-smp sockets=2,cores=4,maxcpus=16
not work. We should probably set the value of
To pave the way for the functional improvement in later patches,
make some refactor/cleanup for the smp parsers, including using
local maxcpus instead of ms->smp.max_cpus in the calculation,
defaulting dies to 0 initially like other members, cleanup the
sanity check for dies.
We actually also fix
Now we have a generic smp parser for all arches, and there will
not be any other arch specific ones, so let's remove the callback
from MachineClass and call the parser directly.
Signed-off-by: Yanan Wang
Reviewed-by: Andrew Jones
Reviewed-by: Daniel P. Berrangé
---
hw/core/machine.c | 3 +--
Quoting one of the Rules described in include/qapi/error.h:
"
Whenever practical, also return a value that indicates success /
failure. This can make the error checking more concise, and can
avoid useless error object creation and destruction. Note that
we still have many functions returning void
Hi Peter,
On Tue, 28 Sept 2021 at 03:21, Peter Maydell wrote:
>
> On Mon, 27 Sept 2021 at 21:12, Simon Glass wrote:
> > I think you are misunderstanding my patch and that may be the problem here.
> >
> > Where QEMU is provided with a dtb (-dtb) it uses that and passes it
> > on. This is absolute
Currently the only difference between smp_parse and pc_smp_parse
is the support of dies parameter and the related error reporting.
With some arch compat variables like "bool dies_supported", we can
make smp_parse generic enough for all arches and the PC specific
one can be removed.
Making smp_pars
Now that all the possible topology parameters are integrated in struct
CpuTopology, tweak the order of topology members to be "cpus/sockets/
dies/cores/threads/maxcpus" for readability and consistency. We also
tweak the comment by adding explanation of dies parameter.
Signed-off-by: Yanan Wang
Re
Now we have a common structure SMPCompatProps used to store information
about SMP compatibility stuff, so we can also move smp_prefer_sockets
there for cleaner code.
No functional change intended.
Signed-off-by: Yanan Wang
Acked-by: David Gibson
Reviewed-by: Andrew Jones
Reviewed-by: Daniel P.
On Tue, Sep 28, 2021 at 6:10 PM Frank Chang wrote:
>
> On Fri, Jul 2, 2021 at 3:17 PM Alistair Francis wrote:
>>
>> On Fri, Jul 2, 2021 at 4:11 PM LIU Zhiwei wrote:
>> >
>> >
>> > On 2021/7/2 下午1:38, Alistair Francis wrote:
>> > > On Thu, Jul 1, 2021 at 6:45 PM Frank Chang
>> > > wrote:
>> > >
On Fri, Sep 24, 2021 at 10:57 PM Richard Henderson
wrote:
>
> On 9/24/21 2:48 AM, Alistair Francis wrote:
> >> But... more specific to this case. Prior to this, was the exception
> >> handler allowed to
> >> assume anything about the contents of stval? Should the value have been
> >> zero? Wo
On Tue, Aug 31, 2021 at 4:36 PM Anup Patel wrote:
>
> The RISC-V Advanced Core Local Interruptor (ACLINT) is an improvement
> over the SiFive CLINT but also maintains backward compatibility with
> the SiFive CLINT.
>
> Latest RISC-V ACLINT specification (will be frozen soon) can be found at:
> htt
On Wed, Sep 29, 2021 at 2:09 PM Anup Patel wrote:
>
> On Tue, Aug 31, 2021 at 4:36 PM Anup Patel wrote:
> >
> > The RISC-V Advanced Core Local Interruptor (ACLINT) is an improvement
> > over the SiFive CLINT but also maintains backward compatibility with
> > the SiFive CLINT.
> >
> > Latest RISC-
On Wed, Sep 29, 2021 at 9:52 AM Alistair Francis wrote:
>
> On Wed, Sep 29, 2021 at 2:09 PM Anup Patel wrote:
> >
> > On Tue, Aug 31, 2021 at 4:36 PM Anup Patel wrote:
> > >
> > > The RISC-V Advanced Core Local Interruptor (ACLINT) is an improvement
> > > over the SiFive CLINT but also maintains
On Aug 3 12:54, Padmakar Kalghatgi wrote:
> From: padmakar
>
> This patch contains the implementation of certain commands
> of nvme-mi specification.The MI commands are useful to
> manage/configure/monitor the device.Eventhough the MI commands
> can be sent via the inband NVMe-MI send/recieve c
On Tue, Sep 28, 2021 at 05:46:26PM -0300, Jose R. Ziviani wrote:
> This patchset introduces the modinfo_kconfig aiming for a fine-tune
> control of module loading by simply checking Kconfig options during the
> compile time, then generates one modinfo--softmmu.c per target.
>
> The main reason of
On Tue, Sep 7, 2021 at 5:03 PM Jason Wang wrote:
>
> Hi All:
>
> This patch implements the multiqueue support for vhost-vDPA. The most
> important requirement si the control virtqueue support. The virtio-net
> and vhost-net core are tweak to support control virtqueue as if what
> data queue pairs
Hi Philippe,
On 9/28/21 7:56 PM, Philippe Mathieu-Daudé wrote:
> Hi Eric,
>
> On 9/28/21 19:21, Eric Auger wrote:
>> Upgrade the IORT table from B to E.b specification
>> revision (ARM DEN 0049E.b).
>>
>> Signed-off-by: Eric Auger
>> ---
>> hw/arm/virt-acpi-build.c | 47 -
On 28/09/2021 19.39, Philippe Mathieu-Daudé wrote:
On 9/28/21 18:02, Thomas Huth wrote:
Some of the ObjectType entries already depend on CONFIG_* switches.
Some others also only make sense with certain configurations, but
are currently always listed in the ObjectType enum. Let's make them
depend
Hello Titus,
On 9/29/21 00:39, Titus Rwantare wrote:
This patch follows the Handing IPMI for emulating BMC patch set by Hao Wu.
Building on top of the work in [PATCH] hw/misc: Add an iBT device model posted
by Cédric Le Goater, this iBT model works as a backend to ipmi-host-extern.
Could you p
On 29/09/2021 07.30, ~farzon wrote:
From: Farzon Lotfi
Hi!
Thanks for your contribution! However, there are some more rules that need
to be followed to get a patch accepted in the QEMU project:
Please provide a proper patch description for your changes (something like:
"QEMU coding style
On 24/09/2021 10:05, Philippe Mathieu-Daudé wrote:
On 9/24/21 11:01, Philippe Mathieu-Daudé wrote:
On 9/24/21 09:06, Mark Cave-Ayland wrote:
On 23/09/2021 10:49, Philippe Mathieu-Daudé wrote:
On 9/23/21 11:13, Mark Cave-Ayland wrote:
Each Nubus slot has an IRQ line that can be used to reque
For vdpa device, if the host support VIRTIO_NET_F_MAC
we need to read the mac address from hardware, so need
to check this bit, the logic is
1 if the host support VIRTIO_NET_F_MAC and the mac address
is correct, qemu will use the mac address in hardware
2.if the host not support , qemu will use
201 - 226 of 226 matches
Mail list logo
