On 3/29/22 14:45, Daniel Henrique Barboza wrote:
The timebase is allocated during spapr_realize_vcpu() and it's not
freed. This results in memory leaks when doing vcpu unplugs:
==636935==
==636935== 144 (96 direct, 48 indirect) bytes in 1 blocks are definitely lost
in loss record 6
,461 of 8,13
On 4/1/22 11:19, Frederic Barrat wrote:
The spec defines 3 registers, even though only index 0 and 2 are valid
on POWER9. The same model is used on POWER10. Register 1 is defined
there but we currently don't use it in skiboot. So we can keep
reporting an error on write.
Reported by Coverity (CID
On 4/1/22 21:16, Richard Henderson wrote:
Coverity warns that we shift a 32-bit value by N, and then
accumulate it into a 64-bit type (target_ulong on ppc64).
The ccr is always 8 * 4-bit fields, and thus is always a
32-bit quantity; narrow the type to avoid the warning.
Fixes: Coverity CID 1487
Paolo Bonzini writes:
> On 4/1/22 15:11, Markus Armbruster wrote:
>>> If it can do really serious interprocedural analysis, it _might_ be able
>>> to see through the visitor constructor and know that the "value = *obj"
>>> is not initialized (e.g. "all callers of object_property_set use an
>>> in
Victor Toso writes:
> Example output has the optional member @dnssearch as string type. It
> should be an array of strings instead. Fix it.
"of String objects". Happy to fix this in my tree.
>
> For reference, see NetdevUserOptions.
>
> Signed-off-by: Victor Toso
> ---
> qapi/net.json | 2 +-
Changes the check from only allowing the APIC base address to
allowing the entire APIC address space.
Signed-off-by: Austin Conatser
---
hw/i386/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index ea8eaeb330..61b7416d50
Signed-off-by: Sakshi Kaushik
---
contrib/vhost-user-scsi/vhost-user-scsi.c | 71 +++
1 file changed, 48 insertions(+), 23 deletions(-)
diff --git a/contrib/vhost-user-scsi/vhost-user-scsi.c
b/contrib/vhost-user-scsi/vhost-user-scsi.c
index 4f6e3e2a24..41f3314cdc 100644
---
On Sun, Apr 03, 2022 at 02:21:48AM -0500, Sakshi Kaushik wrote:
Hi Sakshi,
Thanks for the patch. I left comments below on things that are
incomplete. Please compile and run it with the new command-line options
you've added to test if the code works.
> Signed-off-by: Sakshi Kaushik
> ---
> contr
Hi everyone,
I have a question, does a guide or documentation exist to porting new
target to qemu ?
I have found in the list a very old topic about that , but it's not
very clear.
What files into target folder in the source I need to modify ?
Because I can't find any guide or documentatio
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt machine.
This reworks build_pptt() to avoid by reusing the existing one in
ms->possible_cpus. Currently, the only user of bui
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association based on the socket
ID of the given CPU.
This takes account of SMP configuration when the CPU topology
is populated. The die
When CPU-to-NUMA association isn't explicitly provided by users,
the default one is given by mc->get_default_cpu_node_id(). However,
the CPU topology isn't fully considered in the default association
and this causes CPU topology broken warnings on booting Linux guest.
For example, the following wa
This adds cluster-id in CPU instance properties, which will be used
by arm/virt machine. Besides, the cluster-id is also verified or
dumped in various spots:
* hw/core/machine.c::machine_set_cpu_numa_node() to associate
CPU with its NUMA node.
* hw/core/machine.c::machine_numa_finish_cpu_
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the broken CPU topology warning message in Linux guest. This series int
Hi Igor,
On 3/30/22 10:10 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:37 +0800
Gavin Shan wrote:
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt machine.
This a
On 3/28/22 17:26, Alex Bennée wrote:
Sometimes the whole execlog is just two much so add the ability to
filter by instruction opcode or address.
[AJB: this shows for example
.qemu-system-aarch64 -display none -serial mon:stdio \
-M virt -cpu max \
-semihosting-config enable=on \
Hi Igor and Yanan,
On 4/3/22 7:00 PM, Gavin Shan wrote:
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the broken C
Hi Yanan,
On 4/2/22 10:02 AM, wangyanan (Y) wrote:
On 2022/3/23 15:24, Gavin Shan wrote:
When CPU-to-NUMA association isn't explicitly provided by users,
the default on is given by mc->get_default_cpu_node_id(). However,
s/on/one
Will be corrected in v5.
the CPU topology isn't fully consid
Hi Yanan,
On 4/2/22 10:17 AM, wangyanan (Y) wrote:
On 2022/3/23 15:24, Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association based on the socket
ID of the gi
When CPU-to-NUMA association isn't explicitly provided by users,
the default on is given by mc->get_default_cpu_node_id(). However,
the CPU topology isn't fully considered in the default association
and this causes CPU topology broken warnings on booting Linux guest.
For example, the following war
When the PPTT table is built, the CPU topology is re-calculated, but
it's unecessary because the CPU topology has been populated in
virt_possible_cpu_arch_ids() on arm/virt machine.
This avoids to re-calculate the CPU topology by reusing the existing
one in ms->possible_cpus. Currently, the only u
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association based on the socket
ID of the given CPU.
This takes account of SMP configuration when the CPU topology
is populated. The die
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the broken CPU topology warning message in Linux guest. This series int
Reviewed-by: Konstantin Kostiuk
On Thu, Mar 31, 2022 at 11:34 PM Philippe Mathieu-Daudé <
philippe.mathieu.da...@gmail.com> wrote:
> On 31/3/22 22:11, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > Since the introduction of the variable in commit 9dacf32d2cb ("qemu-ga:
>
Hi Igor,
On 3/30/22 9:18 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:35 +0800
Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this case, it's impossible to provide
the default CPU-to-NUMA mapping or association based on the soc
Hi Igor,
On 3/30/22 8:50 PM, Igor Mammedov wrote:
On Sat, 26 Mar 2022 02:49:59 +0800
Gavin Shan wrote:
On 3/25/22 9:19 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:35 +0800
Gavin Shan wrote:
Currently, the SMP configuration isn't considered when the CPU
topology is populated. In this
Hi Igor,
On 3/30/22 8:52 PM, Igor Mammedov wrote:
On Sat, 26 Mar 2022 03:08:19 +0800
Gavin Shan wrote:
On 3/25/22 10:00 PM, Igor Mammedov wrote:
On Wed, 23 Mar 2022 15:24:38 +0800
Gavin Shan wrote:
The value of the following field has been used in ACPI PPTT table
to identify the corresp
Signed-off-by: Yuval Shaia
---
hw/rdma/vmw/pvrdma_main.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c
index 91206dbb8e..aae382af59 100644
--- a/hw/rdma/vmw/pvrdma_main.c
+++ b/hw/rdma/vmw/pvrdma_main.c
@@ -159,1
Guest driver might execute HW commands when shared buffers are not yet
allocated.
This could happen on purpose (malicious guest) or because of some other
guest/host address mapping error.
We need to protect againts such case.
Fixes: CVE-2022-1050
Reported-by: Raven
Signed-off-by: Yuval Shaia
--
Guest driver might execute HW commands when shared buffers are not yet
allocated.
This could happen on purpose (malicious guest) or because of some other
guest/host address mapping error.
We need to protect againts such case.
Fixes: CVE-2022-1050
While there, fix some coding style errors.
Report
Signed-off-by: Sakshi Kaushik
---
contrib/vhost-user-scsi/vhost-user-scsi.c | 35 +++
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/contrib/vhost-user-scsi/vhost-user-scsi.c
b/contrib/vhost-user-scsi/vhost-user-scsi.c
index 4f6e3e2a24..9bdc088ce8 100644
--- a
31 matches
Mail list logo
