From: Thomas Huth
There is no reason why VNC should always be enabled and not be set to
the default value. We already switched the setting in the "configure"
script in commit 3a6a1256d4 ("configure: Allow vnc to get disabled with
--without-default-features"), so let's do that in meson_options.txt
From: Yang Zhong
The QMP and HMP interfaces can be used by monitor or QMP tools to retrieve
the SGX information from VM side when SGX is enabled on Intel platform.
Signed-off-by: Yang Zhong
Message-Id: <20210910102258.46648-2-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
hmp-commands
From: Marc-André Lureau
The QAPI schema shouldn't rely on C system headers #define, but on
configure-time project #define, so we can express the build condition in
a C-independent way.
Signed-off-by: Marc-André Lureau
Message-Id: <20210907121943.3498701-3-marcandre.lur...@redhat.com>
Signed-off
From: Sean Christopherson
SGX capabilities are enumerated through CPUID_0x12.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-16-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
target/i386/cpu.c | 5 +
1 file changed, 5 insertions(+)
From: Peter Maydell
In sev_read_file_base64() we call g_file_get_contents(), which
allocates memory for the file contents. We then base64-decode the
contents (which allocates another buffer for the decoded data), but
forgot to free the memory for the original file data.
Use g_autofree to ensure
From: Sean Christopherson
Note that SGX EPC is currently guaranteed to reside in a single
contiguous chunk of memory regardless of the number of EPC sections.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-19-yang.zh...@intel.com>
Signed-off-by:
From: Sean Christopherson
Enable SGX EPC virtualization, which is currently only support by KVM.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-22-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
hw/i386/pc_piix.c | 1 +
1 file changed, 1
From: Sean Christopherson
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-34-yang.zh...@intel.com>
[Convert to reStructuredText, and adopt the standard === --- ~~~ headings
suggested for example by Linux. - Paolo]
Signed-off-by: Paolo Bonzini
---
From: "Dr. David Alan Gilbert"
Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG'
and the data structure 'virtio_pci_shm_cap' to go with it.
They allow defining shared memory regions with sizes and offsets
of 2^32 and more.
Multiple instances of the capability are allowed and disting
On 2021/9/28 20:25, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
On 9/28/21 05:57, Yanan Wang wrote:
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_
From: Yang Zhong
Libvirt can use query-sgx-capabilities to get the host
sgx capabilities to decide how to allocate SGX EPC size to VM.
Signed-off-by: Yang Zhong
Message-Id: <20210910102258.46648-3-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
hw/i386/sgx-stub.c | 6
hw/
Remove virtio_pci_shm_cap as virtio_pci_cap64 should be used instead.
Signed-off-by: Antonio Caggiano
---
hw/virtio/virtio-pci.c | 4 ++--
include/standard-headers/linux/virtio_pci.h | 7 ---
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/hw/virtio/virtio
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
> ---
> include/qemu/qarray.h | 150 ++
> 1 file
From: Gerd Hoffmann
Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu.
Signed-off-by: Antonio Caggiano
---
hw/display/virtio-gpu-pci.c| 14 ++
hw/display/virtio-gpu.c| 1 +
hw/display/virtio-vga.c| 32 +++-
include/hw/virtio/vi
Previously part of [0], now a patch series on its own.
This patch series cherry picks two commits from [1] and applies one fix
according to [2], which should answer Gerd's comment [3] on previous
patch.
RFC as I believe it needs a proper review from both authors of first two
commits.
[0] https:/
Am 27.09.2021 um 18:55 hat John Snow geschrieben:
> 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 a
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/arm/musca.html
these are based ARM's IoTKit which are m
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 Christian Schoenebeck wrote:
>> > > On Dienstag, 31. August 2021 13:58:02 CEST
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, and let it rest in peace.
The only reason not to do that coul
send_fd_scm can be used as a simple wrapper for self._qmp.send_fd, or it
can be given a file that will be opened for the duration of the sendmsg
system call. Split the two cases to separate functions.
Signed-off-by: Paolo Bonzini
---
python/qemu/machine/machine.py | 34 -
It is not used anymore, remove the source and all remaning traces of it.
Signed-off-by: Paolo Bonzini
---
python/qemu/machine/machine.py | 3 -
python/qemu/machine/qtest.py | 2 -
tests/Makefile.include | 5 +-
tests/meson.build | 4
The previous weird calling convention was a consequence of using
socket_scm_helper. Just use exceptions now that it is gone.
Signed-off-by: Paolo Bonzini
---
python/qemu/machine/machine.py | 11 ++-
tests/qemu-iotests/045 | 3 +--
tests/qemu-iotests/147 | 3 +--
3 file
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,
> including rust, python, and golang extensions to the QAPI generator, what
> we
Hello, Gerd!
On Tue, Sep 28, 2021 at 07:06:28AM +0200, Gerd Hoffmann wrote:
> On Mon, Sep 27, 2021 at 11:11:58AM -0300, Jose R. Ziviani wrote:
> > This patchset introduces the modinfo_need and changes
> > modinfo-generate.py/meson.build to generate/link one modinfo per target.
> >
> > modinfo-gen
Python is able to call sendmsg, it does not need a helper. Write the
code directly; for now, keep the weird calling convention.
Signed-off-by: Paolo Bonzini
---
python/qemu/machine/machine.py | 48 --
python/qemu/qmp/__init__.py| 15 +++
2 files chang
On 16.08.21 11:47, David Hildenbrand wrote:
#1 is a preparation for improved error reporting, #2 adds support for
MADV_POPULATE_WRITE, #3 cleans up the code to avoid global variables and
prepare for concurrency, #4 and #5 optimize thread handling, #6 makes
os_mem_prealloc() safe to be called from
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
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 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:
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 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
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 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 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 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 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
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.
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
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
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 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 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 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 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: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: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: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 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 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 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
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
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
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
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
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
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 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 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,
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 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
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/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
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 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
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
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.
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: 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
---
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: 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
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
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(-
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
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
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
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
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
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
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,
> > +
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 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:
>
> 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 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
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
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
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 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 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 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 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 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 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 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.
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
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
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
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
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
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 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=
101 - 200 of 226 matches
Mail list logo
