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
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
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
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 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
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 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
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 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 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 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 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 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, 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:
>> > >
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.
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
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
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
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
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 +--
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
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
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
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
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
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
We are currently using maxcpus to calculate the omitted sockets
but using cpus to calculate the omitted cores/threads. This makes
cmdlines like:
-smp cpus=8,maxcpus=16
-smp cpus=8,cores=4,maxcpus=16
-smp cpus=8,threads=2,maxcpus=16
work fine but the ones like:
-smp cpus=8,sockets=2,maxcpus=
Hi,
This is a new version (v12) with minor update suggested by Daniel
and Philippe. Two new commits (#1 and #16) are added. Thanks!
Summary of v12:
1) Specifying a CPU topology parameter as zero was implicitly allowed
but undocumented before, while now it's explicitly deprecated.
2) Refactor/fix
We have two requirements for a valid SMP configuration:
the product of "sockets * cores * threads" must represent all the
possible cpus, i.e., max_cpus, and then must include the initially
present cpus, i.e., smp_cpus.
So we only need to ensure 1) "sockets * cores * threads == maxcpus"
at first an
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 testing if we
have strong dependency
The explanation of @cores should be "number of cores per die" but
not "number of cores per thread". Let's fix it.
Fixes: 1e63fe685804 ("machine: pass QAPI struct to mc->smp_parse")
Signed-off-by: Yanan Wang
Reviewed-by: Daniel P. Berrangé
---
qapi/machine.json | 2 +-
1 file changed, 1 insertio
In the SMP configuration, we should either provide a topology
parameter with a reasonable value (greater than zero) or just
omit it and QEMU will compute the missing value.
The users shouldn't provide a configuration with any parameter
of it specified as zero (e.g. -smp 8,sockets=0) which could
po
From: Alistair Francis
Mark the shakti_c machine as not user creatable.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/639
Signed-off-by: Alistair Francis
---
hw/riscv/shakti_c.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/riscv/shakti_c.c b/hw/riscv/shakti_c.c
index
On Tue, Sep 7, 2021 at 6:44 AM Markus Armbruster wrote:
> John Snow writes:
>
> > Annotations do not change runtime behavior.
> >
> > This commit adds mostly annotations, but uses a TYPE_CHECKING runtime
> > check to conditionally import dependencies, which only triggers during
> > runs of mypy.
On Mon, Sep 27, 2021 at 5:22 PM Bin Meng wrote:
>
> If Control.run bit is set while not preserving the Control.claim
> bit, the DMA transfer shall not be started.
>
> The following result is PDMA tested in U-Boot on Unleashed board:
>
> => mw.l 0x300 0x0 <= Disclaim channe
On Wed, Sep 22, 2021 at 07:24:20PM -0300, Leonardo Bras wrote:
> This patch series intends to enable MSG_ZEROCOPY in QIOChannel, and make
> use of it for multifd migration performance improvement.
>
> Patch #1 creates new callbacks for QIOChannel, allowing the implementation
> of asynchronous writ
On Fri, Sep 24, 2021 at 06:43:49PM +0100, Daniel P. Berrangé wrote:
> > @@ -546,6 +546,7 @@ void multifd_save_cleanup(void)
> > MultiFDSendParams *p = &multifd_send_state->params[i];
> > Error *local_err = NULL;
> >
> > +qio_channel_async_flush(p->c, NULL);
> >
On Mon, Sep 27, 2021 at 5:21 PM Bin Meng wrote:
>
> At present the codes detect whether the DMA channel is claimed by:
>
> claimed = !!s->chan[ch].control & CONTROL_CLAIM;
>
> As ! has higher precedence over & (bitwise and), this is essentially
>
> claimed = (!!s->chan[ch].control) & CONTROL_C
On Mon, Sep 27, 2021 at 5:22 PM Bin Meng wrote:
>
> If Control.run bit is set while not preserving the Control.claim
> bit, the DMA transfer shall not be started.
>
> The following result is PDMA tested in U-Boot on Unleashed board:
>
> => mw.l 0x300 0x0 <= Disclaim channe
On Wed, Sep 22, 2021 at 07:24:22PM -0300, Leonardo Bras wrote:
> +static void qio_channel_socket_async_flush(QIOChannel *ioc,
> + Error **errp)
> +{
> +QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc);
> +struct msghdr msg = {};
> +struct pollfd
On Sat, Sep 25, 2021 at 11:34 PM Philippe Mathieu-Daudé wrote:
>
> The current MCHP_PFSOC_MMUART_REG_SIZE definition represent the
> size occupied by all the registers. However all registers are
> 32-bit wide, and the MemoryRegionOps handlers are restricted to
> 32-bit:
>
> static const MemoryRe
Modifies [PATCH] hw/misc: Add an iBT device model
posted by Cédric Le Goater, to use IPMIInterface.
Signed-off-by: Titus Rwantare
---
hw/ipmi/ipmi_extern.h| 1 +
include/hw/arm/aspeed_soc.h | 2 +
include/hw/ipmi/aspeed_ibt.h | 77 +
hw/arm/aspeed_ast2600.c | 12 ++
h
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.
Needed to run:
- [PATCH 4/8] hw/ipmi: Refactor IPMI interface, Hao W
On Sun, Sep 26, 2021 at 6:31 PM Bin Meng wrote:
>
> On Sat, Sep 25, 2021 at 9:34 PM Philippe Mathieu-Daudé
> wrote:
> >
> > The current MCHP_PFSOC_MMUART_REG_SIZE definition represent the
> > size occupied by all the registers. However all registers are
> > 32-bit wide, and the MemoryRegionOps h
On Sat, Sep 25, 2021 at 11:34 PM Philippe Mathieu-Daudé wrote:
>
> The current MCHP_PFSOC_MMUART_REG_SIZE definition represent the
> size occupied by all the registers. However all registers are
> 32-bit wide, and the MemoryRegionOps handlers are restricted to
> 32-bit:
>
> static const MemoryRe
On Sat, Sep 25, 2021 at 11:34 PM Philippe Mathieu-Daudé wrote:
>
> - Embed SerialMM in MchpPfSoCMMUartState and QOM-initialize it
> - Alias SERIAL_MM 'chardev' property on MCHP_PFSOC_UART
> - Forward SerialMM sysbus IRQ in mchp_pfsoc_mmuart_realize()
> - Add DeviceReset() method
> - Add vmstate st
On Sat, Sep 25, 2021 at 11:34 PM Philippe Mathieu-Daudé wrote:
>
> Our device have 2 different I/O regions:
> - a 16550 UART mapped for 32-bit accesses
> - 13 extra registers
>
> Instead of mapping each region on the main bus, introduce
> a container, map the 2 devices regions on the container,
>
On Fri, Sep 24, 2021 at 06:16:04PM +0100, Daniel P. Berrangé wrote:
> > +ssize_t qio_channel_async_writev(QIOChannel *ioc,
> > + const struct iovec *iov,
> > + size_t niov,
> > + int *fds,
> > +
Richard & Alistair,
On Tue, 28 Sept 2021 at 20:45, Philipp Tomsich wrote:
>
> On Tue, 28 Sept 2021 at 20:45, Richard Henderson
> wrote:
> >
> > On 9/28/21 11:45 AM, Philipp Tomsich wrote:
> > > The dup_const macro is returning an unsigned long long, which probably
> > > should be fixed on the tc
dup_const always generates a uint64_t, which may exceed the size of a
target_long (generating warnings with recent-enough compilers).
To ensure that we can use dup_const both for 64bit and 32bit targets,
this adds dup_const_tl, which wraps dup_const and legalises the
truncation to target_long by c
We need to use the newly introduced dup_const_tl in orc.b to legalise
the truncation (to target_long) of the constant generated with dup_const.
Signed-off-by: Philipp Tomsich
---
target/riscv/insn_trans/trans_rvb.c.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/r
module_kconfig is a new directive that should be used with module_obj
whenever that module depends on the Kconfig to be enabled.
When the module is enabled in Kconfig we are sure that its dependencies
will be enabled as well, thus the module will be loaded without any
problem.
The correct way to
This patch changes the way modinfo is generated and built. Instead of
one modinfo.c it generates one modinfo--softmmu.c per target. It
aims a fine-tune control of modules by configuring Kconfig.
Signed-off-by: Jose R. Ziviani
---
meson.build | 25 +++---
scripts/m
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 this change is to fix problems like:
$ ./qemu-system-s390x -nodefaults -dis
From: Anatoly Parshintsev
Signed-off-by: Anatoly Parshintsev
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/cpu.h | 20 ++
target/riscv/translate.c | 56 +---
2 files changed, 66 insertions(+), 10 deletions(-
Signed-off-by: Alexey Baturo
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/insn_trans/trans_rva.c.inc | 3 +++
target/riscv/insn_trans/trans_rvd.c.inc | 2 ++
target/riscv/insn_trans/trans_rvf.c.inc | 2 ++
target/riscv/insn_trans/trans_rvi.c.inc | 2 ++
targ
Signed-off-by: Alexey Baturo
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
---
target/riscv/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 911cd02ea4..c456be39a1 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -582,6
Signed-off-by: Alexey Baturo
---
target/riscv/cpu.c | 2 +
target/riscv/cpu.h | 11 ++
target/riscv/csr.c | 287 +
3 files changed, 300 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7c626d89cd..6a95df559d 100644
--- a/targ
Signed-off-by: Alexey Baturo
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/cpu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 6a95df559d..911cd02ea4 100644
--- a/target/riscv/cpu.c
++
Signed-off-by: Alexey Baturo
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
---
target/riscv/cpu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 5896aca346..cd86f5422f 100644
--- a/target/riscv/cpu.h
+++
Signed-off-by: Alexey Baturo
Reviewed-by: Alistair Francis
---
target/riscv/cpu_bits.h | 96 +
1 file changed, 96 insertions(+)
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 999187a9ee..1a3767804a 100644
--- a/target/riscv/cpu_bits.
v11:
Addressed a few style issues Alistair mentioned in the previous review.
If this patch series would be accepted, I think my further attention would be
to:
- Support pm for memory operations for RVV
- Add proper csr and support pm for memory operations for Hypervisor mode
- Support address wra
On Tue, 28 Sept 2021 at 20:45, Richard Henderson
wrote:
>
> On 9/28/21 11:45 AM, Philipp Tomsich wrote:
> > The dup_const macro is returning an unsigned long long, which probably
> > should be fixed on the tcg.h-level instead of forcing a cast to target_long
> > at the call site.
>
> No, dup_const
On 9/28/21 11:45 AM, Philipp Tomsich wrote:
The dup_const macro is returning an unsigned long long, which probably
should be fixed on the tcg.h-level instead of forcing a cast to target_long
at the call site.
No, dup_const is first and primarily for vector support, and therefore must return a
On 9/28/21 15:04, Alex Bennée wrote:
>
> Niraj Sorathiya writes:
>
>> Hello Team,
>>
>> Would you please give me some suggestions on how I should proceed to
>> build an IOT (Internet of Things) emulator ?
>
> Maybe look at the Musca boards:
>
> https://qemu.readthedocs.io/en/latest/system/ar
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
> 1 file changed, 28 insertions(+), 19 deletions(-)
> -
On 9/24/21 20:43, Titus Rwantare wrote:
On Fri, 24 Sept 2021 at 03:55, Cédric Le Goater wrote:
Hello Titus,
On 9/24/21 10:42, Philippe Mathieu-Daudé wrote:
On 9/24/21 01:48, Titus Rwantare wrote:
Hello all,
I'd like some clarification on how the following code transfers irqs
back and forth
To handle SMMUv3 nested stage support it is practical to
expose the guest with reserved memory regions (RMRs)
covering the IOVAs used by the host kernel to map
physical MSI doorbells.
Those IOVAs belong to [0x800, 0x810] matching
MSI_IOVA_BASE and MSI_IOVA_LENGTH definitions in kernel
arm-
On Tue, Sep 28, 2021 at 9:53 AM Paolo Bonzini wrote:
> I suspect no one has ever looked at socket_scm_helper.c, because when I
> did my reaction was just "why". The functionality of this 136-line program
> can be reproduced in Python with fewer lines of code than it takes to
> invoke it. Do it,
On Tue, Sep 28, 2021 at 9:53 AM Daniel P. Berrangé
wrote:
> On Mon, Sep 27, 2021 at 12:55:34PM -0400, John Snow wrote:
> > Hiya,
> >
> > I'd like to propose that at least the three of us arrange a time to have
> a
> > meeting where we discuss our plans and ideas for QAPI going forward,
> > includ
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 on the correpsonding CONFIG_* switches, too,
On 22/09/21 14:10, Kashyap Chamarthy wrote:
As of writing this, qemu.org is down, so I've used a one-month old
copy[1] of the wiki from 27Aug2021 to do the rST conversion.
My main motivation was to convert SubmitAPatch (when Peter Maydell
pointed out on IRC that it's still on the wiki). But it
Signed-off-by: Eric Auger
---
tests/qtest/bios-tables-test-allowed-diff.h | 1 -
tests/data/acpi/virt/IORT | Bin 124 -> 128 bytes
tests/data/acpi/virt/IORT.memhp | Bin 124 -> 128 bytes
tests/data/acpi/virt/IORT.numamem | Bin 124 -> 128 bytes
tests/data
Ignore IORT till reference blob for E.b spec revision gets
added.
Signed-off-by: Eric Auger
---
tests/qtest/bios-tables-test-allowed-diff.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523
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
1 file changed, 28 insertions(+), 19 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
This series upgrades the ACPI IORT table up to the E.b
specification revision. One of the goal of this upgrade
is to allow the addition of RMR nodes along with the SMMUv3.
It applies on top of Igor's
[PATCH v4 00/35] acpi: refactor error prone build_header() and
packed structures usage in ACPI tab
On 28.09.21 18:56, Daniel P. Berrangé wrote:
On Mon, Aug 16, 2021 at 11:47:38AM +0200, David Hildenbrand wrote:
Add a mutex to protect the SIGBUS case, as we cannot mess concurrently
with the sigbus handler and we have to manage the global variable
sigbus_memset_context. The MADV_POPULATE_WRITE
On 28.09.21 18:59, Daniel P. Berrangé wrote:
On Mon, Aug 16, 2021 at 11:47:39AM +0200, David Hildenbrand wrote:
Temporarily modifying the SIGBUS handler is really nasty, as we might be
unlucky and receive an MCE SIGBUS while having our handler registered.
Unfortunately, there is no way around me
On Tue, Sep 28, 2021 at 05:56:41PM +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 11:47:38AM +0200, David Hildenbrand wrote:
> > Add a mutex to protect the SIGBUS case, as we cannot mess concurrently
> > with the sigbus handler and we have to manage the global variable
> > sigbus_memset
On Mon, Aug 16, 2021 at 11:47:39AM +0200, David Hildenbrand wrote:
> Temporarily modifying the SIGBUS handler is really nasty, as we might be
> unlucky and receive an MCE SIGBUS while having our handler registered.
> Unfortunately, there is no way around messing with SIGBUS when
> MADV_POPULATE_WRI
On Mon, Aug 16, 2021 at 11:47:38AM +0200, David Hildenbrand wrote:
> Add a mutex to protect the SIGBUS case, as we cannot mess concurrently
> with the sigbus handler and we have to manage the global variable
> sigbus_memset_context. The MADV_POPULATE_WRITE path can run
> concurrently.
>
> Note tha
On Mon, Aug 16, 2021 at 11:47:37AM +0200, David Hildenbrand wrote:
> Let's simplify the case when we only want a single thread and don't have
> to mess with signal handlers.
>
> Reviewed-by: Pankaj Gupta
> Signed-off-by: David Hildenbrand
> ---
> util/oslib-posix.c | 8
> 1 file change
On Mon, Aug 16, 2021 at 11:47:36AM +0200, David Hildenbrand wrote:
> Let's limit the number of threads to something sane, especially that
> - We don't have more threads than the number of pages we have
> - We don't have threads that initialize small (< 64 MiB) memory
>
> Reviewed-by: Pankaj Gupta
On Mon, Aug 16, 2021 at 11:47:34AM +0200, David Hildenbrand wrote:
> Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
> does not require a SIGBUS handler, doesn't actually touch page content,
> and avoids context switches; it is, therefore, faster and easier to handle
> than ou
On Tue, Sep 28, 2021 at 06:23:23PM +0200, Christian Schoenebeck wrote:
> On Dienstag, 28. September 2021 15:04:36 CEST Daniel P. Berrangé wrote:
> > On Sun, Aug 22, 2021 at 03:16:46PM +0200, Christian Schoenebeck wrote:
> > > Implements deep auto free of arrays while retaining common C-style
> > >
On Dienstag, 28. September 2021 15:37:45 CEST Alex Bennée wrote:
> Christian Schoenebeck writes:
> > On Montag, 27. September 2021 12:59:40 CEST Greg Kurz wrote:
> >> On Mon, 27 Sep 2021 12:35:16 +0200
> >>
> >> Christian Schoenebeck wrote:
> >> > On Dienstag, 31. August 2021 14:25:04 CEST Chris
On Dienstag, 28. September 2021 15:04:36 CEST Daniel P. Berrangé wrote:
> On Sun, Aug 22, 2021 at 03:16:46PM +0200, Christian Schoenebeck wrote:
> > Implements deep auto free of arrays while retaining common C-style
> > squared bracket access.
> >
> > Signed-off-by: Christian Schoenebeck
> > ---
On Mon, Aug 16, 2021 at 11:47:33AM +0200, David Hildenbrand wrote:
> Let's prepare touch_all_pages() for returning differing errors. Return
> an error from the thread and report the last processed error.
>
> Translate SIGBUS to -EFAULT, as a SIGBUS can mean all different kind of
> things (memory e
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 on the correpsonding CONFIG_* switches, too, so that upper
layers (like libvirt) have a be
Richard,
On Tue, 28 Sept 2021 at 09:07, Alistair Francis wrote:
>
> On Sun, Sep 12, 2021 at 12:07 AM Philipp Tomsich
> wrote:
> >
> > The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
> > orc.b instruction (equivalent to the orc.b pseudo-instruction built on
> > gorci from pre-0.
On 28.09.21 17:34, Peter Xu wrote:
On Sat, Sep 04, 2021 at 06:09:12PM +0200, David Hildenbrand wrote:
Let's factor out prefaulting/populating to make further changes easier to
review and add a comment what we are actually expecting to happen. While at
it, use the actual page size of the ramblock
On Sat, Sep 04, 2021 at 06:09:12PM +0200, David Hildenbrand wrote:
> Let's factor out prefaulting/populating to make further changes easier to
> review and add a comment what we are actually expecting to happen. While at
> it, use the actual page size of the ramblock, which defaults to
> qemu_real_
On Sat, Sep 04, 2021 at 06:09:11PM +0200, David Hildenbrand wrote:
> Let's use QEMU_ALIGN_DOWN() and friends to make the code a bit easier to
> read.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Peter Xu
--
Peter Xu
On 27/09/21 18:55, John Snow wrote:
Hiya,
I'd like to propose that at least the three of us arrange a time to have
a meeting where we discuss our plans and ideas for QAPI going forward,
including rust, python, and golang extensions to the QAPI generator,
what we hope to accomplish with those
On 23/09/21 14:11, Peter Maydell wrote:
The function scsi_bus_new() creates a new SCSI bus; callers can
either pass in a name argument to specify the name of the new bus, or
they can pass in NULL to allow the bus to be given an automatically
generated unique name. Almost all callers want to use
On Tue, Sep 28, 2021 at 8:48 AM Joe Tanen wrote:
> Hello,
>
>
>
> I posted this on qemu-discuss, but it doesn't seem like anybody else has
> seen this issue. I figured I'd try here to see if anybody had any thoughts.
>
>
>
> I'm using qemu-system-aarch64 v5.2 on OSX 11.6. While reading cntvct_el0
Hello,
I posted this on qemu-discuss, but it doesn't seem like anybody else has seen
this issue. I figured I'd try here to see if anybody had any thoughts.
I'm using qemu-system-aarch64 v5.2 on OSX 11.6. While reading cntvct_el0, I've
seen the ticks count go backwards. I dug into the qemu sourc
On Mon, 27 Sept 2021 at 20:26, John Snow wrote:
>
> The following changes since commit de8ed1055c2ce18c95f597eb10df360dcb534f99:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-09-25-v2'
> into staging (2021-09-27 15:03:42 +0100)
>
> are available in the Git repository at:
On Tue, Sep 28, 2021 at 02:25:57PM +0200, Christian Schoenebeck wrote:
> On Montag, 27. September 2021 12:59:40 CEST Greg Kurz wrote:
> > On Mon, 27 Sep 2021 12:35:16 +0200
> >
> > Christian Schoenebeck wrote:
> > > On Dienstag, 31. August 2021 14:25:04 CEST Christian Schoenebeck wrote:
> > > > O
On 04.09.21 18:09, David Hildenbrand wrote:
virtio-mem exposes a dynamic amount of memory within RAMBlocks by
coordinating with the VM. Memory within a RAMBlock can either get
plugged and consequently used by the VM, or unplugged and consequently no
longer used by the VM. Logical unplug is realiz
1 - 100 of 226 matches
Mail list logo
