On 3/29/25 15:26, Aditya Gupta wrote:
Power8E and Power8NVL variants are not of much use in QEMU now, and not
being maintained either.
Newer skiboot might not be able to boot Power8NVL since skiboot v7.0
It is worth mentioning commit c5424f683ee3 ("Remove support for
POWER8 DD1") too. In fact
Hi Dongli,
I noticed you've sent the V3 patchset, but I believe it's more appropriate to
continue the discussion about the issues you encountered in this thread.
On 3/29/25 12:42 AM, Dongli Zhang wrote:
The vendor and CPU are different. i.e., if we use Zhaoxin CPU without
configuring vendor: "-
The FDT does not normally store name properties but reconsrtucts it
from path but each node in Open Firmware should at least have this
property. This is correctly handled in getprop but nextprop should
also return it even if not present as a property. This patch fixes
that and also skips phandle wh
This patchset addresses four bugs related to AMD PMU virtualization.
1. The PerfMonV2 is still available if PERCORE if disabled via
"-cpu host,-perfctr-core".
2. The VM 'cpuid' command still returns PERFCORE although "-pmu" is
configured.
3. The third issue is that using "-cpu host,-pmu" does no
Since perfmon-v2, the AMD PMU supports additional registers. This update
includes get/put functionality for these extra registers.
Similar to the implementation in KVM:
- MSR_CORE_PERF_GLOBAL_STATUS and MSR_AMD64_PERF_CNTR_GLOBAL_STATUS both
use env->msr_global_status.
- MSR_CORE_PERF_GLOBAL_CTRL
AMD does not have what is commonly referred to as an architectural PMU.
Therefore, we need to rename the following variables to be applicable for
both Intel and AMD:
- has_architectural_pmu_version
- num_architectural_pmu_gp_counters
- num_architectural_pmu_fixed_counters
For Intel processors, th
When the PERFCORE is disabled with "-cpu host,-perfctr-core", it is
reflected in in guest dmesg.
[0.285136] Performance Events: AMD PMU driver.
However, the guest CPUID indicates the PerfMonV2 is still available.
CPU:
Extended Performance Monitoring and Debugging (0x8022):
AMD p
Although AMD PERFCORE and PerfMonV2 are removed when "-pmu" is configured,
there is no way to fully disable KVM AMD PMU virtualization. Neither
"-cpu host,-pmu" nor "-cpu EPYC" achieves this.
As a result, the following message still appears in the VM dmesg:
[0.263615] Performance Events: AMD
Currently, AMD PMU support isn't determined based on CPUID, that is, the
"-pmu" option does not fully disable KVM AMD PMU virtualization.
To minimize AMD PMU features, remove PERFCORE when "-pmu" is configured.
To completely disable AMD PMU virtualization will be implemented via
KVM_CAP_PMU_CAPAB
QEMU uses the kvm_get_msrs() function to save Intel PMU registers from KVM
and kvm_put_msrs() to restore them to KVM. However, there is no support for
AMD PMU registers. Currently, pmu_version and num_pmu_gp_counters are
initialized based on cpuid(0xa), which does not apply to AMD processors.
For A
The kvm_put_msrs() sets the MSRs using KVM_SET_MSRS. The x86 KVM processes
these MSRs one by one in a loop, only saving the config and triggering the
KVM_REQ_PMU request. This approach does not immediately stop the event
before updating PMC.
In additional, PMU MSRs are set only at levels >= KVM_PU
pci_host_data_be_ops became unused after endianness fixes
Signed-off-by: Rakesh Jeyasingh
---
hw/pci/pci_host.c | 6 --
include/hw/pci-host/dino.h | 4
include/hw/pci/pci_host.h | 1 -
3 files changed, 11 deletions(-)
diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c
index 8
The GT-64120 PCI controller requires special handling where:
1. Host bridge(bus 0 ,device 0) must use native endianness
2. Other devices follow MByteSwap bit in GT_PCI0_CMD
Previous implementation accidentally swapped all accesses, breaking
host bridge detection (lspci -d 11ab:4620).
This patch:
v2: https://mail.gnu.org/archive/html/qemu-devel/2025-03/msg06884.html
Rakesh Jeyasingh (2):
hw/pci-host/gt64120: Fix endianness handling
hw/pci-host: Remove unused pci_host_data_be_ops
hw/pci-host/gt64120.c | 99 +-
hw/pci/pci_host.c | 6 --
Now that there is logging support in Rust for QEMU, use it in the pl011 device.
Signed-off-by: Bernhard Beschow
---
rust/hw/char/pl011/src/device.rs | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/rust/hw/char/pl011/src/device.rs b/rust/hw/char/pl011/src/device.r
This series introduces a qemu_log_mask!() macro which works similar to the C
version while catering to Rust expectations. It is just a thin wrapper around
qemu_log(). The macro then gets used in the pl011 device which either had its
logging commented out or relied on eprintln!() which can't be sile
Add skeleton for handle "ibm,configure-kernel-dump" rtas call in QEMU.
Verify basic details mandated by the PAPR, such as number of
inputs/output, and add handling for the three fadump commands:
regiser/unregister/invalidate.
Currently fadump register will always return HARDWARE ERROR, since it's
On 29/3/25 08:51, Akihiko Odaki wrote:
On 2025/03/24 19:21, Alex Bennée wrote:
We can handle larger sized memops now, expand the range of the assert.
Fixes: 4b473e0c60 (tcg: Expand MO_SIZE to 3 bits)
Signed-off-by: Alex Bennée
---
v2
- instead of 128 use 1 << MO_SIZE for future proofing
--
Hello Bernhard,
thanks for interrest in the FlexCAN emulation for QEMU.
On Sunday 30 of March 2025 12:05:45 Bernhard Beschow wrote:
> Am 2. Oktober 2024 15:06:01 UTC schrieb Pavel Pisa :
> >Dear Nikita and other,
> >
> >my student Matyas Bobek has chosen to work
> >on QEMU CAN support in a frame
On Sat, Mar 29, 2025 at 5:18 PM Philippe Mathieu-Daudé
wrote:
> Hi Rakesh,
>
> On 29/3/25 01:49, rakeshj wrote:
> > The GT-64120 PCI controller requires special handling where:
> > 1. Host bridge (device 0) must use native endianness
> > 2. Other devices follow MByteSwap bit in GT_PCI0_CMD
> >
>
On Sat, Mar 29, 2025 at 12:31 PM Rakesh J wrote:
> Paolo: You pointed out the size issue with .min_access_size = 1 and
> .max_access_size = 4, where bswap32 was wrong for 2-byte accesses. I’ve fixed
> this with size-appropriate swaps (bswap16 for 2-byte, bswap32 for 4-byte). On
> the extra swa
Am 2. Oktober 2024 15:06:01 UTC schrieb Pavel Pisa :
>Dear Nikita and other,
>
>my student Matyas Bobek has chosen to work
>on QEMU CAN support in a frame of his study
>final project.
>
>We have identified iMX6 FlexCAN as the next interesting
>CAN controller for emulation.
I'd be interested in
Am 27. März 2025 16:19:32 UTC schrieb "Philippe Mathieu-Daudé"
:
>
>> Bernhard Beschow (3):
>>hw/arm/imx8mp-evk: Fix reference count of SoC object
>>hw/arm/fsl-imx8mp: Derive struct FslImx8mpState from
>> TYPE_SYS_BUS_DEVICE
>>hw/arm/fsl-imx8mp: Remove unused define
>
>Series q
Introduce a functional test which boots Debian 12 on the imx8mp-evk board. Since
the root filesystem resides on an SD card, the test also verifies the basic
operation of the USDHC.
Signed-off-by: Bernhard Beschow
---
MAINTAINERS | 1 +
tests/functional/meson.buil
On 28/3/25 13:37, Chung-Yi Chen wrote:
This patch fixes a misconfiguration issue in the read implementation of
the AUX_MU_IIR_REG register. This issue can lead to a transmit interrupt
being incorrectly interpreted as a receive interrupt when the receive
interrupt is disabled and the receive FIFO
Thanks, BALATON
I looked into PCI_BUS_NUM and PCI_SLOT from include/hw/pci/pci.h (L15-24):
- PCI_BUS_NUM(x) (((x) >> 8) & 0xff)) --> bits 15-8.
- PCI_SLOT(devfn) (((devfn) >> 3) & 0x1f)),
which don’t align properly with the 32-bit phb->config_reg layout used in
your GT-64120 . Since these macros ar
Handle the overlap of source registers with different EEWs.
Co-authored-by: Anton Blanchard
Co-authored-by: Max Chou
Signed-off-by: Max Chou
---
target/riscv/insn_trans/trans_rvv.c.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/riscv/insn_trans/trans_rvv.c.in
27 matches
Mail list logo
