On 2023/12/17 18:46, Rene Engel wrote:
--- Ursprüngliche Nachricht ---
Von: Akihiko Odaki
Datum: 17.12.2023 07:25:52
An: Peter Maydell , Philippe Mathieu-Daudé , Gerd
Hoffmann , Marc-André Lureau , Marek Glogowski
Betreff: [PATCH v7] ui/cocoa: Use NSWindow's ability to resize
Tested-by:
Hi Heinrich,
Thanks for the patch!.
On Mon, Dec 18, 2023 at 08:40:18AM +0100, Heinrich Schuchardt wrote:
> Generate SMBIOS tables for the RISC-V mach-virt.
> Add CONFIG_SMBIOS=y to the RISC-V default config.
>
> The implementation is based on the corresponding ARM and Loongson code.
>
> With th
The emulated AIA within the Linux kernel restores the HART index
of the IMSICs according to the configured AIA settings. During
this process, the group setting is used only when the machine
partitions harts into groups. It's unnecessary to set the group
configuration if the machine has only one soc
The interrupts-extended property of PLIC only has 2 * hart number
fields when KVM enabled, copy 4 * hart number fields to fdt will
expose some uninitialized value.
In this patch, I also refactor the code about the setting of
interrupts-extended property of PLIC for improved readability.
Signed-of
Move some boot functions to boot.c and struct
loongarch_boot_info into struct LoongArchMachineState.
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 127
hw/loongarch/meson.build| 1 +
hw/loongarch/virt.c | 118 ++--
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 29 +++--
include/hw/loongarch/boot.h | 9 +
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
index 5d963176bd..1600ae6e55 100644
--- a/hw/loongarch/
Add init_systab and set boot_info->a2
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 39 +
include/hw/loongarch/boot.h | 50 +
2 files changed, 89 insertions(+)
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
inde
The right fdt memory node like [1], not [2]
[1]
memory@0 {
device_type = "memory";
reg = <0x00 0x00 0x00 0x1000>;
};
[2]
memory@0 {
device_type = "memory";
reg = <0x02 0x00 0x02 0x1000>;
};
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 45 +
hw/loongarch/virt.c | 11 ++---
include/hw/loongarch/boot.h | 27 ++
include/hw/loongarch/virt.h | 10 +
4 files changed, 84 insertions(+), 9 deletions(-)
d
uart node need interrupts and interrupt-parent cells.
Signed-off-by: Song Gao
---
hw/loongarch/virt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 02a3af3b5e..e1a6ec86c8 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loon
fdt adds pch msi controller, we use 'loongson,pch-msi-1.0'.
See:
drivers/irqchip/irq-loongson-pch-msi.c
Signed-off-by: Song Gao
---
hw/loongarch/virt.c| 33 -
include/hw/pci-host/ls7a.h | 1 +
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Song Gao
---
hw/loongarch/virt.c | 31 +--
1 file changed, 1 insertion(+), 30 deletions(-)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 74cac07e8a..02a3af3b5e 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -410,34 +410,6 @
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 65 -
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
index 4bfe24274a..076e795714 100644
--- a/hw/loongarch/boot.c
+++ b/hw/loongarch/boot.c
@@ -1
Signed-off-by: Song Gao
---
hw/loongarch/virt.c | 73 ++---
1 file changed, 69 insertions(+), 4 deletions(-)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 859f17c2f6..74cac07e8a 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -
Add init_cmline and set boot_info->a0, a1
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 21 +
include/hw/loongarch/virt.h | 2 ++
target/loongarch/cpu.h | 2 ++
3 files changed, 25 insertions(+)
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
index
Hi, All
We already support boot efi kernel with bios, but not support boot elf kernel.
This series adds boot elf kernel with FDT.
'LoongArch supports ACPI and FDT. The information that needs to be passed
to the kernel includes the memmap, the initrd, the command line, optionally
the ACPI/FDT ta
fdt adds cpu interrupt controller node,
we use 'loongson,cpu-interrupt-controller'.
See:
drivers/irqchip/irq-loongarch-cpu.c
Signed-off-by: Song Gao
---
hw/loongarch/virt.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
ind
we load initrd ramdisk after kernel_high address
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
index 9f25ea5847..2be6dfb037 100644
--- a/hw/loongarch/boot
fdt adds Extend I/O Interrupt Controller,
we use 'loongson,ls2k2000-eiointc'.
See:
drivers/irqchip/irq-loongson-eiointc.c
Signed-off-by: Song Gao
---
hw/loongarch/virt.c| 30 +-
include/hw/intc/loongarch_extioi.h | 1 +
2 files changed, 30 insertio
fdt adds pch pic controller, we use 'loongson,pch-pic-1.0'
See:
drivers/irqchip/irq-loongson-pch-pic.c
Signed-off-by: Song Gao
---
hw/loongarch/virt.c| 30 +-
include/hw/pci-host/ls7a.h | 1 +
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/
rtc node need interrupts and interrupt-parent cells.
Signed-off-by: Song Gao
---
hw/loongarch/virt.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index e1a6ec86c8..c122d86048 100644
--- a/hw/loongarch/virt.c
+++ b/hw/l
Signed-off-by: Song Gao
---
hw/loongarch/boot.c | 11 +++
include/hw/loongarch/boot.h | 4
2 files changed, 15 insertions(+)
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
index 1600ae6e55..8c28a0ef6f 100644
--- a/hw/loongarch/boot.c
+++ b/hw/loongarch/boot.c
@@ -14
From: Inès Varhol
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/arm/Kconfig | 1 +
hw/arm/stm32l4x5_soc.c | 56 --
include/hw/arm/stm32l4x5_soc.h | 3 ++
3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/h
From: Inès Varhol
Although very similar to the STM32F4xx EXTI, STM32L4x5 EXTI generates
more than 32 event/interrupt requests and thus uses more registers
than STM32F4xx EXTI which generates 23 event/interrupt requests.
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/misc/Kconf
From: Inès Varhol
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
tests/qtest/meson.build | 5 +
tests/qtest/stm32l4x5_exti-test.c | 485 ++
2 files changed, 490 insertions(+)
create mode 100644 tests/qtest/stm32l4x5_exti-test.c
diff --git
Changes from non-RFC v2 to non-RFC v3:
- corrected the license
Changes from non-RFC v1 to non-RFC v2:
- correct the commit messages
- remove a misleading comment
Changes from v3 to non-RFC v1:
- separating the patch in 3 commits
- justifying in the commit message why we implement a new
model inst
On 12/18/23 09:49, Sunil V L wrote:
Hi Heinrich,
Thanks for the patch!.
On Mon, Dec 18, 2023 at 08:40:18AM +0100, Heinrich Schuchardt wrote:
Generate SMBIOS tables for the RISC-V mach-virt.
Add CONFIG_SMBIOS=y to the RISC-V default config.
The implementation is based on the corresponding ARM
On Mon, 18 Dec 2023 at 07:26, Markus Armbruster wrote:
>
> Peter Maydell writes:
>
> > On Thu, 14 Dec 2023 at 17:14, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> QOM properties are added on the ARM vCPU object when a
> >> feature is present. Rather than checking the property
> >> is present, che
On Tue, Dec 12, 2023 at 7:26 PM Peter Maydell wrote:
>
> On Tue, 12 Dec 2023 at 01:43, Tomoyuki Hirose
> wrote:
> >
> > Thanks for comment.
> >
> > On Mon, Dec 11, 2023 at 10:57 PM Peter Maydell
> > wrote:
> > > We should definitely look at fixing the unaligned access
> > > stuff, but the linke
On Thu, 14 Dec 2023 at 17:14, Philippe Mathieu-Daudé wrote:
>
> QOM properties are added on the ARM vCPU object when a
> feature is present. Rather than checking the property
> is present, check the feature.
>
> Suggested-by: Markus Armbruster
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> RFC:
Am 17. Dezember 2023 15:40:58 UTC schrieb BALATON Zoltan :
>On Sun, 17 Dec 2023, Bernhard Beschow wrote:
>> The VIA south bridges are able to relocate and enable or disable their
>> SuperI/O
>> functions. So far this is hardcoded such that all functions are always
>> enabled
>> and are located
In many configurations, e.g. multiple vNICs with multiple queues or
with many Ceph OSDs, the default soft limit of 1024 is not enough.
QEMU is supposed to work fine with file descriptors >= 1024 and does
not use select() on POSIX. Bump the soft limit to the allowed hard
limit to avoid issues with t
[ Cc: qemu-block ]
Am 04.12.2023 um 17:42 hat Stefan Hajnoczi geschrieben:
> v2:
> - Reschedule BH in new AioContext if change is detected [Kevin]
> - Drop stray "remember" in Patch 2's commit description [Eric]
>
> The SCSI subsystem uses the AioContext lock to protect internal state. This is
>
ping
https://patchew.org/QEMU/20231117173916.3658-1-n.ostren...@gmail.com/
пт, 17 нояб. 2023 г., 20:39 Nikita Ostrenkov :
> From MCF5253 Reference manual
> https://www.nxp.com/docs/en/reference-manual/MCF5253RM.pdf
>
> Host mode: Port Change Detect. The controller sets this bit to a one when
> on
On Sun, 17 Dec 2023, Bernhard Beschow wrote:
Am 17. Dezember 2023 15:47:33 UTC schrieb BALATON Zoltan :
On Sun, 17 Dec 2023, Bernhard Beschow wrote:
Exposing the internal header allows for exposing struct FDCtrlISABus which is
encuraged by qdev guidelines.
Hopefully the guidelines don't encou
On Thu, Dec 07, 2023 at 12:37:44AM +0800, Hyman Huang wrote:
> By enhancing the LUKS driver, it is possible to enable
> the detachable LUKS header and, as a result, achieve
> general encryption for any disk format that QEMU has
> supported.
>
> Take the qcow2 as an example, the usage of the generi
From: Inès Varhol
Acked-by: Alistair Francis
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
tests/qtest/meson.build | 3 +-
tests/qtest/stm32l4x5_syscfg-test.c | 408
2 files changed, 410 insertions(+), 1 deletion(-)
create mode 100644
From: Inès Varhol
The SYSCFG input GPIOs aren't connected yet. When the STM32L4x5 GPIO
device will be implemented, its output GPIOs will be connected to the
SYSCFG input GPIOs.
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/arm/Kconfig | 1 +
hw/arm/stm32l4x5_
From: Inès Varhol
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/misc/Kconfig| 3 +
hw/misc/meson.build| 1 +
hw/misc/stm32l4x5_syscfg.c | 265 +
hw/misc/trace-events | 6 +
include/hw/m
On Thu, Dec 07, 2023 at 12:37:42AM +0800, Hyman Huang wrote:
> Add the "header" option for the LUKS format. This field would be
> used to identify the blockdev's position where a detachable LUKS
> header is stored.
>
> In addition, introduce header field in struct BlockCrypto
>
> Signed-off-by: H
On Thu, Dec 07, 2023 at 12:37:43AM +0800, Hyman Huang wrote:
> Signed-off-by: Hyman Huang
> ---
> crypto/block.c | 4
> include/crypto/block.h | 1 +
> 2 files changed, 5 insertions(+)
Reviewed-by: Daniel P. Berrangé
however, based on my comment in patch #3, I'm not convinced this
Hello Alistair, thank you for your comments.
Changes from v1 to v2:
- explain in 3rd commit why SYSCFG input GPIOs aren't connected and add
a TODO comment in stm32l4x5_soc.c
- use macros `NUM_GPIOS` and `GPIO_NUM_PINS` in
`stm32l4x5_syscfg_set_irq`
- rename STM32L4XX to STM32L4X5, Stm32l4xx to Stm
On Mon, 18 Dec 2023, Akihiko Odaki wrote:
On 2023/12/17 20:39, BALATON Zoltan wrote:
On Sun, 17 Dec 2023, Akihiko Odaki wrote:
This change brings two new features:
- The window will be resizable if "Zoom To Fit" is eanbled
- The window can be made full screen by clicking full screen button
pro
On Thu, Dec 07, 2023 at 12:37:45AM +0800, Hyman Huang wrote:
> Provide the "detached-mode" option for detached LUKS header
> formatting.
>
> To format the LUKS header on the pre-creating disk, example
> as follows:
>
> 1. add a protocol blockdev node of LUKS header
> $ virsh qemu-monitor-command
On Thu, Dec 07, 2023 at 12:37:41AM +0800, Hyman Huang wrote:
> v2:
> - Simplify the design by reusing the LUKS driver to implement
> the generic Luks encryption, thank Daniel for the insightful
> advice.
> - rebase on master.
>
> Hyman Huang (4):
> crypto: Introduce option and structure f
FEAT_NV2 requires that when HCR_EL2.{NV,NV2} == 0b11 then accesses by
EL1 to certain system registers are redirected to RAM. The full list
of affected registers is in the table in rule R_CSRPQ in the Arm ARM.
The registers may be normally accessible at EL1 (like ACTLR_EL1), or
normally UNDEF at EL
The alias registers like SCTLR_EL12 only exist when HCR_EL2.E2H
is 1; they should UNDEF otherwise. We weren't implementing this.
Add an intercept of the accessfn for these aliases, and implement
the UNDEF check.
Signed-off-by: Peter Maydell
---
target/arm/cpregs.h | 3 ++-
target/arm/helper.c |
The FEAT_NV HCR_EL2.AT bit enables trapping of some address
translation instructions from EL1 to EL2. Implement this behaviour.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/target/arm/helper.c b/t
In handle_sys() we don't do the check for whether the register is
marked as needing an FPU/SVE/SME access check until after we've
handled the special cases covered by ARM_CP_SPECIAL_MASK. This is
conceptually the wrong way around, because if for example we happen
to implement an FPU-access-checked
FEAT_NV requires that when HCR_EL2.{NV,NV1} == {1,0} and an exception
is taken from EL1 to EL1 then the reported EL in SPSR_EL1.M should be
EL2, not EL1. Implement this behaviour.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/targ
This patchset adds support for emulating the Arm architectural features
FEAT_NV and FEAT_NV2 which allow nested virtualization, i.e. where a
hypervisor can run a guest which thinks it is running at EL2.
Nominally FEAT_NV is sufficient for this and FEAT_NV2 merely improves
the performance in the ne
Mark up the cpreginfo structs to indicate offsets for system
registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in
the Arm ARM. This commit covers offsets 0x168 to 0x1f8.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 18 ++
1 file changed, 18 insertions(
We already print various lines of information when we take an
exception, including the ELR and (if relevant) the FAR. Now
that FEAT_NV means that we might report something other than
the old PSTATE to the guest as the SPSR, it's worth logging
this as well.
Signed-off-by: Peter Maydell
---
target
If FEAT_NV2 redirects a system register access to a memory offset
from VNCR_EL2, that access might fault. In this case we need to
report the correct syndrome information:
* Data Abort, from same-EL
* no ISS information
* the VNCR bit (bit 13) is set
and the exception must be taken to EL2.
Sav
When FEAT_NV is turned on via the HCR_EL2.NV bit, ERET instructions
are trapped, with the same syndrome information as for the existing
FEAT_FGT fine-grained trap (in the pseudocode this is handled in
AArch64.CheckForEretTrap()).
Rename the DisasContext and tbflag bits to reflect that they are
no
Mark up the cpreginfo structs for the GIC CPU registers to indicate
the offsets from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ
in the Arm ARM.
Signed-off-by: Peter Maydell
---
hw/intc/arm_gicv3_cpuif.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/intc/arm_gicv3_c
The hypervisor can deliver (virtual) LPIs to a guest by setting up a
list register to have an intid which is an LPI. The GIC has to treat
these a little differently to standard interrupt IDs, because LPIs
have no Active state, and so the guest will only EOI them, it will
not also deactivate them.
For FEAT_NV, when HCR_EL2.{NV,NV1} is {1,1} PAN is always disabled
even when the PSTATE.PAN bit is set. Implement this by having
arm_pan_enabled() return false in this situation.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/ar
When HCR_EL2.{NV,NV1} is {1,1} we must trap five extra registers to
EL2: VBAR_EL1, ELR_EL1, SPSR_EL1, SCXTNUM_EL1 and TFSR_EL1.
Implement these traps.
This trap does not apply when FEAT_NV2 is implemented and enabled;
include the check that HCR_EL2.NV2 is 0 here, to save us having
to come back and
The system registers DBGVCR32_EL2, FPEXC32_EL2, DACR32_EL2 and
IFSR32_EL2 are present only to allow an AArch64 EL2 or EL3 to read
and write the contents of an AArch32-only system register. The
architecture requires that they are present only when EL1 can be
AArch32, but we implement them unconditi
The CTR_EL0 register has some bits which allow the implementation to
tell the guest that it does not need to do cache maintenance for
data-to-instruction coherence and instruction-to-data coherence.
QEMU doesn't emulate caches and so our cache maintenance insns are
all NOPs.
We already have some m
Mark up the cpreginfo structs to indicate offsets for system
registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in
the Arm ARM. This commit covers offsets 0x100 to 0x160.
Many (but not all) of the registers in this range have _EL12 aliases,
and the slot in memory is shared between
FEAT_NV requires that when HCR_EL2.{NV,NV1} == {1,1} the handling
of some of the page table attribute bits changes for the EL1&0
translation regime:
* for block and page descriptors:
- bit [54] holds PXN, not UXN
- bit [53] is RES0, and the effective value of UXN is 0
- bit [6], AP[1], is t
FEAT_NV and FEAT_NV2 will allow EL1 to attempt to access cpregs that
only exist at EL2. This means we're going to want to run their
accessfns when the CPU is at EL1. In almost all cases, the behaviour
we want is "the accessfn returns OK if at EL1".
Mostly the accessfn already does the right thing;
For FEAT_NV, accesses to system registers and instructions from EL1
which would normally UNDEF there but which work in EL2 need to
instead be trapped to EL2. Detect this both for "we know this will
UNDEF at translate time" and "we found this UNDEFs at runtime", and
make the affected registers trap
Under FEAT_NV2, when HCR_EL2.{NV,NV2} == 0b11 at EL1, accesses to the
registers SPSR_EL2, ELR_EL2, ESR_EL2, FAR_EL2 and TFSR_EL2 (which
would UNDEF without FEAT_NV or FEAT_NV2) should instead access the
equivalent EL1 registers SPSR_EL1, ELR_EL1, ESR_EL1, FAR_EL1 and
TFSR_EL1.
Because there are on
When interpreting CPU dumps where FEAT_NV and FEAT_NV2 are in use,
it's helpful to include the values of HCR_EL2.{NV,NV1,NV2} in the CPU
dump format, as a way of distinguishing when we are in EL1 as part of
executing guest-EL2 and when we are just in normal EL1.
Add the bits to the end of the log
FEAT_NV requires (per I_JKLJK) that when HCR_EL2.{NV,NV1} is {1,1} the
unprivileged-access instructions LDTR, STTR etc behave as normal
loads and stores. Implement the check that handles this.
Signed-off-by: Peter Maydell
---
target/arm/tcg/hflags.c | 6 --
1 file changed, 4 insertions(+), 2
FEAT_NV defines three new bits in HCR_EL2: NV, NV1 and AT. When the
feature is enabled, allow these bits to be written, and flush the
TLBs for the bits which affect page table interpretation.
Signed-off-by: Peter Maydell
---
target/arm/cpu-features.h | 5 +
target/arm/helper.c | 6 +++
For FEAT_VHE, we define a set of register aliases, so that for instance:
* the SCTLR_EL1 either accesses the real SCTLR_EL1, or (if E2H is 1)
SCTLR_EL2
* a new SCTLR_EL12 register accesses SCTLR_EL1 if E2H is 1
However when we create the 'new_reg' cpreg struct for the SCTLR_EL12
register, we
FEAT_NV2 defines another new bit in HCR_EL2: NV2. When the
feature is enabled, allow this bit to be written in HCR_EL2.
Signed-off-by: Peter Maydell
---
target/arm/cpu-features.h | 5 +
target/arm/helper.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/target/arm/cpu-features.
For FEAT_NV2, a new system register VNCR_EL2 holds the base
address of the memory which nested-guest system register
accesses are redirected to. Implement this register.
Signed-off-by: Peter Maydell
---
target/arm/cpu.h| 3 +++
target/arm/helper.c | 26 ++
2 files ch
The TBFLAG_A64 TB flag bits go in flags2, which for AArch64 guests
we know is 64 bits. However at the moment we use FIELD_EX32() and
FIELD_DP32() to read and write these bits, which only works for
bits 0 to 31. Since we're about to add a flag that uses bit 32,
switch to FIELD_EX64() and FIELD_DP64(
Mark up the cpreginfo structs to indicate offsets for system
registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in
the Arm ARM. This commit covers offsets below 0x100; all of these
registers are redirected to memory regardless of the value of
HCR_EL2.NV1.
Signed-off-by: Peter Mayde
Mark up the cpreginfo structs to indicate offsets for system
registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in
the Arm ARM. This covers all the remaining offsets at 0x200 and
above, except for the GIC ICH_* registers.
(Note that because we don't implement FEAT_SPE, FEAT_TRF,
F
The HCR_EL2.TSC trap for trapping EL1 execution of SMC instructions
has a behaviour change for FEAT_NV when EL3 is not implemented:
* in older architecture versions TSC was required to have no
effect (i.e. the SMC insn UNDEFs)
* with FEAT_NV, when HCR_EL2.NV == 1 the trap must apply
(i.e.
Enable FEAT_NV on the 'max' CPU, and stop filtering it out for the
Neoverse N2 and Neoverse V1 CPUs. We continue to downgrade FEAT_NV2
support to FEAT_NV for the latter two CPU types.
Signed-off-by: Peter Maydell
---
docs/system/arm/emulation.rst | 1 +
target/arm/cpu.c | 8 +--
Enable FEAT_NV2 on the 'max' CPU, and stop filtering it out for
the Neoverse N2 and Neoverse V1 CPUs.
Signed-off-by: Peter Maydell
---
docs/system/arm/emulation.rst | 1 +
target/arm/cpu.c | 5 -
target/arm/tcg/cpu64.c| 2 +-
3 files changed, 2 insertions(+), 6 deletions
FEAT_NV requires that when HCR_EL2.NV is set reads of the CurrentEL
register from EL1 always report EL2 rather than the real EL.
Implement this.
Signed-off-by: Peter Maydell
---
target/arm/tcg/translate-a64.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/target/arm
With FEAT_NV2, the condition for when SPSR_EL1.M should report that
an exception was taken from EL2 changes.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index
Currently the code in target/arm/helper.c mostly checks the PAN bits
in env->pstate or env->uncached_cpsr directly when it wants to know
if PAN is enabled, because in most callsites we know whether we are
in AArch64 or AArch32. We do have an arm_pan_enabled() function, but
we only use it in a few p
Am 14.12.23 um 20:53 schrieb Stefan Hajnoczi:
>
> I will still try the other approach that Hanna and Paolo have suggested.
> It seems more palatable. I will send a v2.
>
FYI, what I already tried downstream (for VirtIO SCSI):
> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> index
We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
comes with a lot of defaults. This is fine for most regular uses but
it's not suitable when more control of what is actually loaded in the
CPU is required.
A bare-bones CPU would be annoying to deal with if not by profile
suppor
zic64b is defined in the RVA22U64 profile [1] as a named feature for
"Cache blocks must be 64 bytes in size, naturally aligned in the address
space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64
profile mandates this feature, meaning that applications using this
profile expects 64 by
QEMU already implements zicbom (Cache Block Management Operations) and
zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv:
add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for
what would be the instructions for zicbop (Cache Block Prefetch
Operations), which are
Hi,
This is a merge of the two profile series:
"[PATCH for-9.0 v12 00/18] riscv: rv64i/rva22u64 CPUs, RVA22U64 profile support"
"[PATCH for-9.0 v2 0/8] target/riscv: implement RVA22S64 profile"
I'm sending them together since the second series is dependent on the first.
Quick summary of the maj
We have two instances of the setting/clearing a MISA bit from
env->misa_ext and env->misa_ext_mask pattern. And the next patch will
end up adding one more.
Create a helper to avoid code repetition.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: LIU Zhiwei
Rev
KVM does not have the means to support enabling the rva22u64 profile.
The main reasons are:
- we're missing support for some mandatory rva22u64 extensions in the
KVM module;
- we can't make promises about enabling a profile since it all depends
on host support in the end.
We'll revisit this
Some profiles, like RVA22S64, has a priv_spec requirement.
Make this requirement explicit for all profiles. We'll validate this
requirement finalize() time and, in case the user chooses an
incompatible priv_spec while activating a profile, a warning will be
shown.
Signed-off-by: Daniel Henrique B
The rva22U64 profile, described in:
https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles
Contains a set of CPU extensions aimed for 64-bit userspace
applications. Enabling this set to be enabled via a single user flag
makes it convenient to enable a predictable set of fe
RVG behaves like a profile: a single flag enables a set of bits. Right
now we're considering user choice when handling RVG and zicsr/zifencei
and ignoring user choice on MISA bits.
We'll add user warnings for profiles when the user disables its
mandatory extensions in the next patch. We'll do the
'satp_mode' is a requirement for supervisor profiles like RVA22S64.
User-mode/application profiles like RVA22U64 doesn't care.
Add 'satp_mode' to the profile description. If a profile requires it,
set it during cpu_set_profile(). We'll also check it during finalize()
to validate if the running con
This CPU was suggested by Alistair [1] and others during the profile
design discussions. It consists of the bare 'rv64i' CPU with rva22u64
enabled by default, like an alias of '-cpu rv64i,rva22u64=true'.
Users now have an even easier way of consuming this user-mode profile by
doing '-cpu rva22u64'
Previous patches added several g_hash_table_insert() patterns. Add two
helpers, one for each user hash, to make the code cleaner.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/tcg/tcg-cpu.c | 28
1 file changed, 16 insertions(+),
The RVA22S64 profile consists of the following:
- all mandatory extensions of RVA22U64;
- priv spec v1.12.0;
- satp mode sv39;
- Ssccptr, a cache related named feature that we're assuming always
enable since we don't implement a cache;
- Other named features already implemented: Sstvecd, Sstvala
The TCG emulation implements all the extensions described in the
RVA22U64 profile, both mandatory and optional. The mandatory extensions
will be enabled via the profile flag. We'll leave the optional
extensions to be enabled by hand.
Given that this is the first profile we're implementing in TCG w
Enabling a profile and then disabling some of its mandatory extensions
is a valid use. It can be useful for debugging and testing. But the
common expected use of enabling a profile is to enable all its mandatory
extensions.
Add an user warning when mandatory extensions from an enabled profile
are
Named features (zic64b the sole example at this moment) aren't expose to
users, thus we need another way to expose them.
Go through each named feature, get its boolean value, do the needed
conversions (bool to qbool, qbool to QObject) and add it to output dict.
Another adjustment is needed: named
'svade' is a RVA22S64 profile requirement, a profile we're going to add
shortly. It is a named feature (i.e. not a formal extension, not defined
in riscv,isa DT at this moment) defined in [1] as:
"Page-fault exceptions are raised when a page is accessed when A bit is
clear, or written when D bit i
Certain S-mode profiles, like RVA22S64 and RVA23S64, mandate all the
mandatory extensions of their respective U-mode profiles. RVA22S64
includes all mandatory extensions of RVA22U64, and the same happens with
RVA23 profiles.
Add a 'parent' field to allow profiles to enable other profiles. This
wil
1 - 100 of 239 matches
Mail list logo