Hello,
On 4/1/20 5:58 PM, Marc Zyngier wrote:
> Implementing (and even advertising) 64bit PSCI functions to 32bit
> guests is at least a bit odd, if not altogether violating the
> spec which says ("5.2.1 Register usage in arguments and return values"):
>
> "Adherence to the SMC Calling Conventions
Hi,
On 4/1/20 5:58 PM, Marc Zyngier wrote:
> When a guest delibarately uses an SSMC32 function number (which is allowed),
s/SSMC32/SMC32
> we should make sure we drop the top 32bits from the input arguments, as they
> could legitimately be junk.
>
> Reported-by: Christoffer Dall
> Signed-off-by
Hi,
On 4/3/20 12:20 PM, Marc Zyngier wrote:
> Hi Alexandru,
>
> On Fri, 3 Apr 2020 11:35:00 +0100
> Alexandru Elisei wrote:
>
>> Hi,
>>
>> On 4/1/20 5:58 PM, Marc Zyngier wrote:
>>> Christoffer recently pointed out that we don't narrow the arguments to
>>> SMC32 PSCI functions called by a 64bit g
On Fri, Mar 27, 2020 at 02:59:47PM +, Steven Price wrote:
> I proposed something similar a while ago[1], but Marc was concerned about
> the microarch detail[2] and hence I split the workaround into VHE/non-VHE.
>
> That said I'm not saying this is necessarily wrong, just that we'd need some
>
Hi Alexandru,
On Fri, 3 Apr 2020 11:35:00 +0100
Alexandru Elisei wrote:
> Hi,
>
> On 4/1/20 5:58 PM, Marc Zyngier wrote:
> > Christoffer recently pointed out that we don't narrow the arguments to
> > SMC32 PSCI functions called by a 64bit guest. This could result in a
> > guest failing to boot
Hi,
On 4/1/20 5:58 PM, Marc Zyngier wrote:
> Christoffer recently pointed out that we don't narrow the arguments to
> SMC32 PSCI functions called by a 64bit guest. This could result in a
> guest failing to boot its secondary CPUs if it had junk in the upper
> 32bits. Yes, this is silly, but the gu
On 2020-04-03 10:36, George Cherian wrote:
-Original Message-
From: Marc Zyngier
Sent: Friday, April 3, 2020 1:32 PM
To: George Cherian
Cc: dave.mar...@arm.com; alexandru.eli...@arm.com;
andre.przyw...@arm.com; christoffer.d...@arm.com;
james.mo...@arm.com; jint...@cs.columbia.edu;
juli
> -Original Message-
> From: Marc Zyngier
> Sent: Friday, April 3, 2020 1:32 PM
> To: George Cherian
> Cc: dave.mar...@arm.com; alexandru.eli...@arm.com;
> andre.przyw...@arm.com; christoffer.d...@arm.com;
> james.mo...@arm.com; jint...@cs.columbia.edu;
> julien.thierry.k...@gmail.com;
Hi Marc,
On 2/11/20 9:48 AM, Marc Zyngier wrote:
> This is a major rework of the NV series that I posted over 6 months
> ago[1], and a lot has changed since then:
>
> - Early ARMv8.4-NV support
> - ARMv8.4-TTL support in host and guest
> - ARMv8.5-GTG support in host and guest
> - Lots of comments
On Mon, Mar 23, 2020 at 11:32:27AM +, Beata Michalska wrote:
> Injecting external data abort through KVM might trigger
> an issue on kernels that do not get updated to include the KVM fix.
> For those and aarch32 guests, the injected abort gets misconfigured
> to be an implementation defined ex
Hi Drew,
On 4/3/20 9:37 AM, Andrew Jones wrote:
> On Fri, Apr 03, 2020 at 07:07:10AM +0200, Auger Eric wrote:
>> Hi Drew,
>>
>> On 4/2/20 8:01 PM, Andrew Jones wrote:
>>> [ Without the fix this test would hang, as timeouts don't work with
>>> the migration scripts (yet). Use errata to skip instea
Hi George,
On 2020-04-03 08:27, George Cherian wrote:
Hi Marc,
On 2/11/20 9:48 AM, Marc Zyngier wrote:
This is a major rework of the NV series that I posted over 6 months
ago[1], and a lot has changed since then:
- Early ARMv8.4-NV support
- ARMv8.4-TTL support in host and guest
- ARMv8.5-GTG
On Fri, Apr 03, 2020 at 07:07:10AM +0200, Auger Eric wrote:
> Hi Drew,
>
> On 4/2/20 8:01 PM, Andrew Jones wrote:
> > [ Without the fix this test would hang, as timeouts don't work with
> > the migration scripts (yet). Use errata to skip instead of hang. ]
> > Signed-off-by: Andrew Jones
> > --
Test configurations where we transit from 32b to 64b
counters and conversely. Also tests configuration where
chain counters are configured but only one counter is
enabled.
Signed-off-by: Eric Auger
---
v3 -> v4:
- allo report messages are different
v2 -> v3:
- added prefix pop
---
arm/pmu.c
Add tests dedicated to SW_INCR event counting.
Signed-off-by: Eric Auger
---
v3: new
- Formerly in chained counter tests but as QEMU does not
support chained counters, the whole test was failing. Peter
split the test.
---
arm/pmu.c | 47 +
Allows to set or clear the enable state of a PPI/SGI/SPI.
Signed-off-by: Eric Auger
---
---
lib/arm/asm/gic.h | 4
lib/arm/gic.c | 31 +++
2 files changed, 35 insertions(+)
diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
index 922cbe9..57e81c6 100644
--
Adds the following tests:
- event-counter-config: test event counter configuration
- basic-event-count:
- programs counters #0 and #1 to count 2 required events
(resp. CPU_CYCLES and INST_RETIRED). Counter #0 is preset
to a value close enough to the 32b
overflow limit so that we check the o
Add 2 tests exercising chained counters. The first one uses
CPU_CYCLES and the second one uses SW_INCR.
Signed-off-by: Eric Auger
---
v3 -> v4:
- each report_info has a different message
v2 -> v3:
- added prefix pop
- added pmu prefix to the test names
- defines, event array ...
---
arm/pmu.c
Test overflows for MEM_ACCESS and SW_INCR events. Also tests
overflows with 64-bit events.
Signed-off-by: Eric Auger
---
v3 -> v4:
- all report messages are different
v2 -> v3:
- added prefix pop
- added pmu_stats.unexpected
- added pmu- prefix
- remove traces in irq_handler()
v1 -> v2:
- inli
This series implements tests exercising the PMUv3 event counters.
It tests both the 32-bit and 64-bit versions. Overflow interrupts
also are checked. Those tests only are written for arm64.
It allowed to reveal some issues related to SW_INCR implementation
(esp. related to 64-bit implementation),
As we intend to introduce more PMU tests, let's add
a sub-test parameter that will allow to categorize
them. Existing tests are in the cycle-counter category.
Signed-off-by: Eric Auger
Reviewed-by: Andre Przywara
---
v2 -> v3:
- added report_prefix_pop()
---
arm/pmu.c | 25 +++
check_pmcr() checks the IMP field is different than 0.
However A zero IMP field is permitted by the architecture,
meaning the MIDR_EL1 should be looked at instead. This
causes TCG to fail this test on '-cpu max' because in
that case PMCR.IMP is set equal to MIDR_EL1.Implementer
which is 0.
So let'
This struct aims at storing information potentially used by
all tests such as the pmu version, the read-only part of the
PMCR, the number of implemented event counters, ...
Signed-off-by: Eric Auger
Reviewed-by: Andre Przywara
---
v2 -> v3:
- Fix pmcr_ro and add a comment
---
arm/pmu.c | 29 +
If event counters are implemented check the common events
required by the PMUv3 are implemented.
Some are unconditionally required (SW_INCR, CPU_CYCLES,
either INST_RETIRED or INST_SPEC). Some others only are
required if the implementation implements some other features.
Check those wich are unco
Introduce some defines encoding the different PMU versions.
v3 is encoded differently in 32 and 64 bits.
Signed-off-by: Eric Auger
---
arm/pmu.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index d827e82..a04588a 100644
---
From: Andrew Jones
Sometimes we need to test access to system registers which are
missing assembler mnemonics.
Signed-off-by: Andrew Jones
Reviewed-by: Alexandru Elisei
---
lib/arm64/asm/sysreg.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/arm64/asm/sysreg.h b/lib/arm
26 matches
Mail list logo
