On 2/5/2025 12:13 PM, Cédric Le Goater wrote:
On 1/29/25 15:43, Steve Sistare wrote:
Preserve vfio INTx state across cpr-transfer. Preserve VFIOINTx fields as
follows:
pin : Recover this from the vfio config in kernel space
interrupt : Preserve its eventfd descriptor across exec.
unmas
On Thu, Feb 06, 2025 at 01:51:15PM +, Shameerali Kolothum Thodi wrote:
> Hmm..I don’t think just swapping the order will change the association with
> Guest SMMU here. Because, we have,
>
> > -device arm-smmuv3-accel,id=smmuv2,bus=pcie.2
>
> During smmuv3-accel realize time, this will result
On Thu, Feb 06 2025, Corvin Köhne wrote:
> From: Corvin Köhne
>
> We've recently imported the PCI ID header for Intel GPUs into our tree.
> Add it to our helper script to make it easier for us to sync this file
> in the future.
>
> Signed-off-by: Corvin Köhne
> ---
> scripts/update-linux-heade
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, February 6, 2025 5:47 PM
> To: Daniel P. Berrangé
> Cc: Shameerali Kolothum Thodi
> ; qemu-...@nongnu.org;
> qemu-devel@nongnu.org; eric.au...@redhat.com;
> peter.mayd...@linaro.org; nicol...@nvidia.com; ddut...@redhat.com;
On Thu, Feb 06, 2025 at 05:54:57PM +, Daniel P. Berrangé wrote:
> > > We shouldn't assume any VFIO device exists in the QEMU cnofig at the time
> > > we realize the virtual ssmu. I expect the SMMU may be cold plugged, while
> > > the VFIO devices may be hot plugged arbitrarly later, and we shou
Hi,
We've been discussing a way to stop multifd recv threads from getting
an error at the end of migration when the source threads close the
iochannel without ending the TLS session.
The original issue was introduced by commit 1d457daf86
("migration/multifd: Further remove the SYNC on complete")
We're currently only checking the QEMUFile error after
qemu_loadvm_state(). Check the migration error as well to avoid
missing errors that might be set by the multifd recv thread.
This doesn't break compat between 9.2 and 10.0 because 9.2 still has
the multifd recv threads stuck at sync when the s
On Thu, Feb 06, 2025 at 05:57:38PM +, Shameerali Kolothum Thodi wrote:
> Also how do we do it with multiple VF devices under a pSUMMU ? Which
> cdev fd in that case?
It doesn't matter, they are all interchangeable. Creating the VIOMMU
object just requires any vfio device that is attached to
On Thu, Feb 06, 2025 at 01:46:47PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 05:10:32PM +, Daniel P. Berrangé wrote:
> > On Thu, Feb 06, 2025 at 01:02:38PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 06, 2025 at 03:07:06PM +, Shameerali Kolothum Thodi wrote:
> > > > > If w
On 6.02.2025 18:32, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
On 6.02.2025 16:20, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
(..)
Even if non-TLS behaved the same, why would we choose to port a bug to
the TLS implementation?
We could of course decide at this point to pun
Add a task dispatcher for gnutls_bye similar to the
qio_channel_tls_handshake_task(). The gnutls_bye() call might be
interrupted and so it needs to be rescheduled.
The migration code will make use of this to help the migration
destination identify a premature EOF. Once the session termination is
i
QEMU's TLS session code provides no way to call gnutls_bye() to
terminate a TLS session. Callers of qcrypto_tls_session_read() can
choose to ignore a GNUTLS_E_PREMATURE_TERMINATION error by setting the
gracefulTermination argument.
The QIOChannelTLS ignores the premature termination error whenever
The multifd recv side has been getting a TLS error of
GNUTLS_E_PREMATURE_TERMINATION at the end of migration when the send
side closes the sockets without ending the TLS session. This has been
masked by the code not checking the migration error after loadvm.
Start ending the TLS session at multifd
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, February 6, 2025 5:59 PM
> To: Daniel P. Berrangé
> Cc: Shameerali Kolothum Thodi
> ; qemu-...@nongnu.org;
> qemu-devel@nongnu.org; eric.au...@redhat.com;
> peter.mayd...@linaro.org; nicol...@nvidia.com; ddut...@redhat.com;
On Thu, Feb 06, 2025 at 06:49:38PM +0100, Philippe Mathieu-Daudé wrote:
> On 6/2/25 18:12, Daniel P. Berrangé wrote:
> > On Thu, Feb 06, 2025 at 04:04:20PM +0100, Philippe Mathieu-Daudé wrote:
> > > On 6/2/25 15:31, Daniel P. Berrangé wrote:
> > > > On Thu, Feb 06, 2025 at 02:53:58PM +0100, Philipp
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> Signed-off-by: Bernhard Beschow
> ---
> docs/system/arm/imx8mp-evk.rst | 1 +
> include/hw/arm/fsl-imx8mp.h| 7 +++
> hw/arm/fsl-imx8mp.c| 28
> hw/arm/Kconfig | 1 +
> 4
On Thu, Feb 06, 2025 at 05:53:31PM +0100, Kevin Wolf wrote:
> Commit fc4e394b28 removed the last caller of blk_op_is_blocked(). Remove
> the now unused function.
>
> Signed-off-by: Kevin Wolf
> ---
> include/system/block-backend-global-state.h | 1 -
> block/block-backend.c
On Thu, Feb 06, 2025 at 06:04:57PM +, Shameerali Kolothum Thodi wrote:
> > Some kind of hot plug smmu would have to create a vSMMU without any
> > kernel backing and then later bind it to a kernel implementation.
>
> Not sure I get the problem with associating vSMMU with a pSMMU. Something
> l
On Thu, Feb 06, 2025 at 02:58:21PM -0300, Fabiano Rosas wrote:
> QEMU's TLS session code provides no way to call gnutls_bye() to
> terminate a TLS session. Callers of qcrypto_tls_session_read() can
> choose to ignore a GNUTLS_E_PREMATURE_TERMINATION error by setting the
> gracefulTermination argume
On Thu, Feb 06, 2025 at 01:58:43PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 05:54:57PM +, Daniel P. Berrangé wrote:
> > > > We shouldn't assume any VFIO device exists in the QEMU cnofig at the
> > > > time
> > > > we realize the virtual ssmu. I expect the SMMU may be cold plugge
Remove target-specificity in some units and move them to
the meson common_ss[] source set to build them once.
Philippe Mathieu-Daudé (7):
MAINTAINERS: Unify Alistair's professional email address
target/riscv: Move target-agnostic definitions to 'cpu-qom.h'
hw/riscv/opentitan: Include missing
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, February 6, 2025 6:13 PM
> To: Shameerali Kolothum Thodi
> Cc: Daniel P. Berrangé ; qemu-...@nongnu.org;
> qemu-devel@nongnu.org; eric.au...@redhat.com;
> peter.mayd...@linaro.org; nicol...@nvidia.com; ddut...@redhat.com;
>
Hardware code using HART rarely needs to knows its internals.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/riscv/riscv_hart.h | 4 ++--
hw/riscv/virt-acpi-build.c| 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/hw/riscv/riscv_hart.h b/include/hw/riscv/ris
On 6/2/25 19:29, Daniel P. Berrangé wrote:
On Thu, Feb 06, 2025 at 07:24:55PM +0100, Philippe Mathieu-Daudé wrote:
+Michal
On 6/2/25 19:06, Daniel P. Berrangé wrote:
On Thu, Feb 06, 2025 at 06:49:38PM +0100, Philippe Mathieu-Daudé wrote:
On 6/2/25 18:12, Daniel P. Berrangé wrote:
On Thu, Feb
Found that some of the cache properties are not set correctly for EPYC models.
l1d_cache.no_invd_sharing should not be true.
l1i_cache.no_invd_sharing should not be true.
L2.self_init should be true.
L2.inclusive should be true.
L3.inclusive should not be true.
L3.no_invd_sharing should be true.
Found that some of the cache properties are not set correctly for EPYC models.
l1d_cache.no_invd_sharing should not be true.
l1i_cache.no_invd_sharing should not be true.
L2.self_init should be true.
L2.inclusive should be true.
L3.inclusive should not be true.
L3.no_invd_sharing should be true.
Add the support for AMD EPYC zen 5 processors (EPYC-Turin).
Add the following new feature bits on top of the feature bits from
the previous generation EPYC models.
movdiri : Move Doubleword as Direct Store Instruction
movdir64b : Move 64 Bytes as Direct Store Instruction
avx
Found that some of the cache properties are not set correctly for EPYC models.
l1d_cache.no_invd_sharing should not be true.
l1i_cache.no_invd_sharing should not be true.
L2.self_init should be true.
L2.inclusive should be true.
L3.inclusive should not be true.
L3.no_invd_sharing should be true.
Found that some of the cache properties are not set correctly for EPYC models.
l1d_cache.no_invd_sharing should not be true.
l1i_cache.no_invd_sharing should not be true.
L2.self_init should be true.
L2.inclusive should be true.
L3.inclusive should not be true.
L3.no_invd_sharing should be true.
Add the CPUID bit indicates that a WRMSR to MSR_FS_BASE, MSR_GS_BASE, or
MSR_KERNEL_GS_BASE is non-serializing.
CPUID_Fn8021_EAX
BitFeature description
1 FsGsKernelGsBaseNonSerializing.
WRMSR to FS_BASE, GS_BASE and KernelGSbase are non-serializing.
Link:
https://www.amd.com/
On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 06:18:14PM +, Shameerali Kolothum Thodi wrote:
>
> > > So even if you invent an iommu ID we cannot accept it as a handle to
> > > create viommu in iommufd.
> >
> > Creating the vIOMMU only happens when
On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote:
> On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 06, 2025 at 06:18:14PM +, Shameerali Kolothum Thodi wrote:
> >
> > > > So even if you invent an iommu ID we cannot accept it as a handle to
> > > > c
Am 06.02.2025 um 18:25 hat Philippe Mathieu-Daudé geschrieben:
> On 6/2/25 17:53, Kevin Wolf wrote:
> > Commit fc4e394b28 removed the last caller of blk_op_is_blocked(). Remove
> > the now unused function.
>
> fatal: ambiguous argument 'fc4e394b28': unknown revision or path not in the
> working tr
On Mon, 3 Feb 2025 at 14:40, Alex Bennée wrote:
>
> This reverts commit bc02be4508d8753d1f6071b77d10f4661587df6f.
>
> Now we catch attempts to clock_step to the next timer when none are
> enabled we can revert the previous attempt to prevent deadlock. As
> long as a new target time is given we wil
On 6.02.2025 16:20, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
On 6.02.2025 15:13, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
On 5.02.2025 21:42, Fabiano Rosas wrote:
Fabiano Rosas writes:
Daniel P. Berrangé writes:
On Tue, Feb 04, 2025 at 10:31:31AM -0500, Peter Xu
For pseries machines, commit 567b5b309abe ("vfio/pci: Relax DMA map
errors for MMIO regions") introduced 2 error reports to notify the
user of MMIO mapping errors. Consolidate both code paths under one.
Cc: Harsh Prateek Bora
Cc: Shivaprasad G Bhat
Signed-off-by: Cédric Le Goater
---
hw/vfio/c
Currently, the mapping handlers of the IOMMU backends, VFIO IOMMU Type
1 aka. legacy and IOMMUFD, return an errno and also report an error.
This can lead to excessive log messages at runtime for recurring DMA
mapping errors. Since these errors are already reported by the callers
in the vfio_contain
This is to be consistent with other reported errors related to vIOMMU
devices.
Signed-off-by: Cédric Le Goater
---
hw/vfio/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index
1b90c78c5a1927b1553c59de7a470544bc07788a..90570e9e4ee571d3ec5a
On 6/2/25 13:56, BALATON Zoltan wrote:
On Thu, 6 Feb 2025, Philippe Mathieu-Daudé wrote:
On 5/2/25 08:03, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
MachineClass::auto_create_sdcard is only useful to automatically
create a SD card, attach a IF_SD block drive to it and plug the
c
Rephrase a bit the ending comment about how errors are handled
depending on the phase in which vfio_listener_region_add() is called.
Signed-off-by: Cédric Le Goater
---
hw/vfio/common.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfi
> -Original Message-
> From: Daniel P. Berrangé
> Sent: Thursday, February 6, 2025 10:37 AM
> To: Shameerali Kolothum Thodi
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org;
> eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
> nicol...@nvidia.com; ddut...@redhat.com; Li
Hi Daniel,
On 6/2/25 14:20, Daniel P. Berrangé wrote:
On Thu, Feb 06, 2025 at 02:10:47PM +0100, Philippe Mathieu-Daudé wrote:
Introduce an abstract machine parent class which defines
the 'little_endian' property. Duplicate the current machine,
which endian is tied to the binary endianness, to o
Am 03.02.2025 um 19:25 hat Stefan Hajnoczi geschrieben:
> BLOCK_OP_TYPE_DATAPLANE prevents BlockDriverState from being used by
> virtio-blk/virtio-scsi with IOThread. Commit b112a65c52aa ("block:
> declare blockjobs and dataplane friends!") eliminated the main reason
> for this blocker in 2014.
>
On 6.02.2025 15:13, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
On 5.02.2025 21:42, Fabiano Rosas wrote:
Fabiano Rosas writes:
Daniel P. Berrangé writes:
On Tue, Feb 04, 2025 at 10:31:31AM -0500, Peter Xu wrote:
On Tue, Feb 04, 2025 at 03:39:00PM +0100, Maciej S. Szmigiero wrote
On Thu, Feb 06, 2025 at 02:10:47PM +0100, Philippe Mathieu-Daudé wrote:
> Introduce an abstract machine parent class which defines
> the 'little_endian' property. Duplicate the current machine,
> which endian is tied to the binary endianness, to one big
> endian and a little endian machine; updatin
On 6/2/25 13:49, BALATON Zoltan wrote:
On Thu, 6 Feb 2025, Philippe Mathieu-Daudé wrote:
On 15/1/25 20:04, BALATON Zoltan wrote:
The interrupt enable registers are not reset to 0 but some bits are
enabled on reset. At least some U-Boot versions seem to expect this
and not initialise these regis
> Let's ignore how to place it for now, and focus on where we would *like*
> to place it.
>
> Is it related to anything other than ObjectType / ObjectOptions in the
> QMP reference manual?
Yes!
> I guess qapi/kvm.json is for KVM-specific stuff in general, not just the
> KVM PMU filter. Should w
On 2/3/2025 11:58 AM, Peter Xu wrote:
On Wed, Jan 29, 2025 at 06:42:58AM -0800, Steve Sistare wrote:
Define a vmstate priority that is lower than the default, so its handlers
run after all default priority handlers. Since 0 is no longer the default
priority, translate an uninitialized priority
On Thu, 6 Feb 2025, Philippe Mathieu-Daudé wrote:
On 6/2/25 13:49, BALATON Zoltan wrote:
On Thu, 6 Feb 2025, Philippe Mathieu-Daudé wrote:
On 15/1/25 20:04, BALATON Zoltan wrote:
The interrupt enable registers are not reset to 0 but some bits are
enabled on reset. At least some U-Boot versions
On Thu, Feb 06, 2025 at 04:04:20PM +0100, Philippe Mathieu-Daudé wrote:
> On 6/2/25 15:31, Daniel P. Berrangé wrote:
> > On Thu, Feb 06, 2025 at 02:53:58PM +0100, Philippe Mathieu-Daudé wrote:
> > > Hi Daniel,
> > >
> > > On 6/2/25 14:20, Daniel P. Berrangé wrote:
> > > > On Thu, Feb 06, 2025 at 0
On 2/6/25 08:54, Gerd Hoffmann wrote:
Note that there is a 'guest-phys-bits' property for x86 CPUs, which is a
hint for the guest what the usable address width is. It was added
because there are cases where the guest simply can't figure that it is
not possible to use the full physical address sp
On 06/02/2025 16.04, Philippe Mathieu-Daudé wrote:
On 6/2/25 15:31, Daniel P. Berrangé wrote:
On Thu, Feb 06, 2025 at 02:53:58PM +0100, Philippe Mathieu-Daudé wrote:
Hi Daniel,
On 6/2/25 14:20, Daniel P. Berrangé wrote:
On Thu, Feb 06, 2025 at 02:10:47PM +0100, Philippe Mathieu-Daudé wrote:
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> Signed-off-by: Bernhard Beschow
> ---
> docs/system/arm/imx8mp-evk.rst | 1 +
> include/hw/arm/fsl-imx8mp.h| 8
> hw/arm/fsl-imx8mp.c| 26 ++
> 3 files changed, 35 insertions(+)
Reviewed-
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> Signed-off-by: Bernhard Beschow
Reviewed-by: Peter Maydell
thanks
-- PMM
On 6/2/25 17:53, Kevin Wolf wrote:
Commit fc4e394b28 removed the last caller of blk_op_is_blocked(). Remove
the now unused function.
fatal: ambiguous argument 'fc4e394b28': unknown revision or path not in
the working tree.
Is there a patch on the list?
Signed-off-by: Kevin Wolf
---
inc
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> Signed-off-by: Bernhard Beschow
> ---
> docs/system/arm/imx8mp-evk.rst | 1 +
> include/hw/arm/fsl-imx8mp.h| 11 +++
> hw/arm/fsl-imx8mp.c| 29 +
> hw/arm/Kconfig | 2 ++
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> Signed-off-by: Bernhard Beschow
> ---
> docs/system/arm/imx8mp-evk.rst | 1 +
> include/hw/arm/fsl-imx8mp.h| 11 +++
> include/hw/timer/imx_gpt.h | 1 +
> hw/arm/fsl-imx8mp.c| 53 ++
On 06/02/2025 14.10, Philippe Mathieu-Daudé wrote:
Replace the DEVICE_NATIVE_ENDIAN MemoryRegionOps by a pair
of DEVICE_LITTLE_ENDIAN / DEVICE_BIG_ENDIAN.
Add the "little-endian" property to select the device
endianness, defaulting to little endian.
Set the proper endianness on the single machine
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> The i.MX 8M Plus SoC actually has two ethernet controllers, the usual ENET one
> and a Designware one. There is no device model for the latter, so only add the
> ENET one.
>
> Signed-off-by: Bernhard Beschow
> ---
> docs/system/arm/imx8mp-
On 2/6/25 05:10, Philippe Mathieu-Daudé wrote:
Commit f0ec14c78c4 ("tests/avocado: Fix console data loss") fixed
QEMUMachine's problem with console, we don't need to use the sleep()
kludges.
Suggested-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
---
tests/functional/test_microblazeel_
On Thu, Feb 06, 2025 at 02:32:12PM -0300, Fabiano Rosas wrote:
> > In any case we'd still need some kind of a compatibility behavior for
> > the TLS bit stream emitted by older QEMU versions (which is always
> > improperly terminated).
> >
>
> There is no compat issue. For <= 9.2, QEMU is still do
On Tue, Feb 04, 2025 at 07:25:12PM +0100, Maciej S. Szmigiero wrote:
> That's for the multifd channel recv thread main loop only, if @Peter
> wants to patch also the mid-stream page receive methods and the main
> migration channel receive then qio_channel_read(), qio_channel_read_all(),
> qio_chann
AMD IOMMU provides the base address of control registers through
IVRS table and PCI capability. Since this base address is of 64 bit,
use 32 bits mask (instead of 16 bits) to set BAR low and high.
Fixes: d29a09ca68 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Sairaj Kodilkar
Reviewed-by: Vasan
From: Peter Maydell
The pseudocode ResetSVEState() does:
FPSR = ZeroExtend(0x089f<31:0>, 64);
but QEMU's arm_reset_sve_state() called vfp_set_fpcr() by accident.
Before the advent of FEAT_AFP, this was only setting a collection of
RES0 bits, which vfp_set_fpsr() would then ignore, so the
From: Hongren Zheng
When USBPacket in OUT direction has larger payload
than the ep_out_buffer (of size 512), a buffer overflow
would occur.
It could be fixed by limiting the size of usb_packet_copy
to be at most buffer size. Further optimization gets rid
of the ep_out_buffer and directly uses ep
The following patches are queued for QEMU stable v7.2.16:
https://gitlab.com/qemu-project/qemu/-/commits/staging-7.2
Patch freeze is 2025-02-06 (frozen), and the release is planned for 2025-02-08:
https://wiki.qemu.org/Planning/7.2
Please respond here or CC qemu-sta...@nongnu.org on any pat
On Thu, 2025-02-06 at 14:26 -0700, Alex Williamson wrote:
> On Thu, 6 Feb 2025 13:13:39 +0100
> Corvin Köhne wrote:
>
> > From: Corvin Köhne
> >
> > We've recently imported the PCI ID list of knwon Intel GPU devices from
> > Linux. It allows us to properly match GPUs to their generation withou
On Thu, Feb 06, 2025 at 02:46:42PM -0800, Nicolin Chen wrote:
> > You'd use the command line information and wouldn't need GET_HW_INFO,
> > it would be complicated
>
> Do you mean the "-device arm-smmuv3-accel,id=xx" line? This still
> won't give us the host IDR/IIDR register values to probe a vSM
On 2025/02/06 22:23, BALATON Zoltan wrote:
On Thu, 6 Feb 2025, Akihiko Odaki wrote:
On 2025/02/06 18:48, Markus Armbruster wrote:
This problem can be solved
using an existing mechanism, OnOffAuto, which differentiates the "auto"
state and explicit th
Interrupt passthrough is determine by the bits 191,190,187-184.
These bits are part of the 3rd quad word (i.e. index 2) in DTE. Hence
replace dte[3] by dte[2].
Fixes: b44159fe0 ("x86_iommu/amd: Add interrupt remap support when VAPIC is not
enabled")
Signed-off-by: Sairaj Kodilkar
Reviewed-by: Va
Hi all,
Accidentally added v2 tag. Please ignore it, this is version 1.
On 2/7/2025 10:23 AM, Sairaj Kodilkar wrote:
This series provides few bug fixes for emulated AMD IOMMU. The series is based
on top of qemu upstream master commit d922088eb4ba.
Patch 1: The code was using wrong DTE field to
This series provides few bug fixes for emulated AMD IOMMU. The series is based
on top of qemu upstream master commit d922088eb4ba.
Patch 1: The code was using wrong DTE field to determine interrupt passthrough.
Hence replaced it with correct field according to [1].
Patch 2: Current code
object_property_help() uses the conventional command line syntax instead
of the JSON syntax. In particular,
- Key-value pairs are written in the command line syntax.
- bool description passed to the function says on/off instead of
true/false.
However, there is one exception: default values are f
These 2 values are different between NPCM7XX and NPCM8XX
CLKs. So we add them to the class and assign different values
to them.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_clk.c | 18 --
hw/misc/npcm_gcr.c | 2 ++
include/hw/misc/npcm_clk.h
These 2 values are different between NPCM7XX and NPCM8XX
GCRs. So we add them to the class and assign different values
to them.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_gcr.c | 27 ---
include/hw/misc/npcm_gcr.h | 13 +++--
2 file
NPCM8XX SoC is the successor of the NPCM7XX. It features quad-core
Cortex-A35 (Armv8, 64-bit) CPUs and some additional peripherals.
This document describes the NPCM8XX SoC and an evaluation board
(NPCM 845 EVB).
Signed-off-by: Hao Wu
---
docs/system/arm/nuvoton.rst | 27
Changes since v3:
1. Removed REGS_END constants according to code review.
2. Added a few asserts according to code review.
3. A few minor style changes.
Changes since v2:
1. Update doc to include npcm845-evb description
2. Add g_assert for register size in CLK and GCR enter_reset function
3. Fix
Il gio 6 feb 2025, 11:42 Zhao Liu ha scritto:
> > diff --git a/rust/hw/char/pl011/src/device_class.rs
> b/rust/hw/char/pl011/src/device_class.rs
> > index 8a157a663fb..dbef93f6cb3 100644
> > --- a/rust/hw/char/pl011/src/device_class.rs
> > +++ b/rust/hw/char/pl011/src/device_class.rs
> > @@ -12,7
The bootrom is a minimal bootrom used to load an NPCM8XX image.
The source code is located in the same repo as the NPCM7XX one:
github.com/google/vbootrom/tree/master/npcm8xx.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
MAINTAINERS | 1 +
pc-bios/README |
Signed-off-by: Hao Wu
---
configs/devices/aarch64-softmmu/default.mak | 1 +
hw/arm/Kconfig | 13 +
hw/arm/meson.build | 1 +
hw/arm/npcm8xx.c| 804
include/hw/arm/npcm8xx.h
The PCS exists in NPCM8XX's GMAC1 and is used to control the SGMII
PHY. This implementation contains all the default registers and
the soft reset feature that are required to load the Linux kernel
driver. Further features have not been implemented yet.
Signed-off-by: Hao Wu
Reviewed-by: Peter May
NPCM8XX adds a few new registers and have a different set of reset
values to the CLK modules. This patch supports them.
This patch doesn't support the new clock values generated by these
registers. Currently no modules use these new clock values so they
are not necessary at this point.
Implementat
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_gcr.c | 129 -
include/hw/misc/npcm_gcr.h | 6 +-
2 files changed, 132 insertions(+), 3 deletions(-)
diff --git a/hw/misc/npcm_gcr.c b/hw/misc/npcm_gcr.c
index d89e8c2c3b..fe6e332de7
A lot of NPCM7XX and NPCM8XX GCR modules share the same code,
this commit moves the NPCM7XX GCR to NPCM GCR for these
properties.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_gcr.c | 92 +-
hw/misc/trace-events | 6 +--
inc
From: Dongwon Kim
This partially reverts commit 77bf310084dad38b3a2badf01766c659056f1cf2
which causes some guest display corruption when gtk-gl-area
is used for GTK rendering (e.g. Wayland Compositor) possibly due to
simulataneous accesses on the guest frame buffer by host compositor
and the gues
On Thu, 6 Feb 2025, Bernhard Beschow wrote:
Am 2. Februar 2025 01:25:22 UTC schrieb BALATON Zoltan :
On Sat, 1 Feb 2025, Bernhard Beschow wrote:
Am 1. Februar 2025 14:55:15 UTC schrieb Bernhard Beschow :
Am 30. Januar 2025 12:45:58 UTC schrieb BALATON Zoltan :
On Wed, 15 Jan 2025, BALATON Zol
Am 6. Februar 2025 17:32:31 UTC schrieb Peter Maydell
:
>On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>>
>> The implementation just allows Linux to determine date and time.
>>
>> Signed-off-by: Bernhard Beschow
>> ---
>> MAINTAINERS | 1 +
>> hw/rtc/rs5c372.c| 227 +
NPCM8XX boot block stores the DRAM size in SCRPAD_B register in GCR
module. Since we don't simulate a detailed memory controller, we
need to store this information directly similar to the NPCM7XX's
INCTR3 register.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_gcr.c
On Wed, Feb 05, 2025 at 05:57:12PM +0530, Prasad Pandit wrote:
> From: Prasad Pandit
>
> Migration capabilities are set in multiple '.start_hook'
> functions for various tests. Instead, consolidate setting
> capabilities in 'set_migration_capabilities()' function
> which is called from various 't
On Thu, Feb 06, 2025 at 05:11:13PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 12:48:40PM -0800, Nicolin Chen wrote:
> > On Thu, Feb 06, 2025 at 04:38:55PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote:
> > > > On Thu, Feb 06, 2025 at 0
On Wed, Feb 05, 2025 at 05:57:10PM +0530, Prasad Pandit wrote:
> From: Prasad Pandit
>
> Enable Multifd and Postcopy migration together.
> The migration_ioc_process_incoming() routine
> checks magic value sent on each channel and
> helps to properly setup multifd and postcopy
> channels.
>
> The
A lot of NPCM7XX and NPCM8XX CLK modules share the same code,
this commit moves the NPCM7XX CLK to NPCM CLK for these
properties.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_clk.c | 106 +
hw/misc/trace-events | 6 +--
in
This allows different FIUs to have different flash sizes, useful
in NPCM8XX which has multiple different sized FIU modules.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/arm/npcm7xx.c | 6 ++
hw/ssi/npcm7xx_fiu.c | 16 ++--
include/hw/ssi/npcm7xx_f
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/arm/meson.build | 2 +-
hw/arm/npcm8xx_boards.c | 253 +++
include/hw/arm/npcm8xx.h | 21
3 files changed, 275 insertions(+), 1 deletion(-)
create mode 100644 hw/arm/npcm8xx_boards.c
diff
This newer vbootrom supports NPCM8xx. Similar to the NPCM7XX one
it supports loading the UBoot from the SPI device and not more.
We updated the npcm7xx bootrom to be compiled from this version.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
pc-bios/npcm7xx_bootrom.bin | Bin 768 -> 768 by
NPCM7XX and NPCM8XX have a different set of CLK registers. This
commit changes the name of the clk files to be used by both
NPCM7XX and NPCM8XX CLK modules.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/meson.build | 2 +-
hw/misc/{npcm7xx_clk.c => npcm_
NPCM7XX and NPCM8XX have a different set of GCRs and the GCR module
needs to fit both. This commit changes the name of the GCR module.
Future commits will add the support for NPCM8XX GCRs.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/meson.build | 2 +-
On Thu, Feb 06, 2025 at 12:41:50PM +0100, Maciej S. Szmigiero wrote:
> On 5.02.2025 16:55, Peter Xu wrote:
> > On Wed, Feb 05, 2025 at 12:53:21PM +0100, Maciej S. Szmigiero wrote:
> > > On 4.02.2025 21:34, Peter Xu wrote:
> > > > On Tue, Feb 04, 2025 at 08:32:15PM +0100, Maciej S. Szmigiero wrote:
The NPCM8xx GCR device can be accessed with 64-bit memory operations.
This patch supports that.
Reviewed-by: Peter Maydell
Signed-off-by: Hao Wu
---
hw/misc/npcm_gcr.c | 94 +---
hw/misc/trace-events | 4 +-
2 files changed, 74 insertions(+), 24 deleti
Am 2. Februar 2025 01:25:22 UTC schrieb BALATON Zoltan :
>On Sat, 1 Feb 2025, Bernhard Beschow wrote:
>> Am 1. Februar 2025 14:55:15 UTC schrieb Bernhard Beschow :
>>> Am 30. Januar 2025 12:45:58 UTC schrieb BALATON Zoltan :
On Wed, 15 Jan 2025, BALATON Zoltan wrote:
> This allows guest
201 - 300 of 405 matches
Mail list logo
