On 02/14/2020 09:28 PM, Peter Maydell wrote:
> On Fri, 14 Feb 2020 at 04:23, Anshuman Khandual
> wrote:
>>
>>
>>
>> On 01/28/2020 06:09 PM, Anshuman Khandual wrote:
>>> This series is primarily motivated from an adhoc list from Mark Rutland
>>> during our ID_ISAR6 discussion [1]. Besides, it also
When a guest delibarately uses an SSMC32 function number (which is allowed),
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: Marc Zyngier
---
virt/kvm/arm/psci.c | 16
1 file
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 guest is allowed to do that. Duh.
Whist I was
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 implies that any AArch32
caller of an SMC64 function
Fix spelling and typos (e.g., repeated words) in comments.
Signed-off-by: Fuad Tabba
---
arch/arm64/kvm/guest.c| 4 ++--
arch/arm64/kvm/reset.c| 6 +++---
arch/arm64/kvm/sys_regs.c | 6 +++---
virt/kvm/arm/arm.c| 6 +++---
virt/kvm/arm/hyp/vgic-v3-sr.c | 2 +-
Hi Yi,
On 4/1/20 3:18 PM, Liu, Yi L wrote:
> Hi Eric,
>
> Just curious about your plan on this patch, I just heard my colleague would
> like
> to reference the functions from this patch in his dsa driver work.
Well I intend to respin until somebody tells me it is completely vain or
dead
Hi Eric,
Just curious about your plan on this patch, I just heard my colleague would like
to reference the functions from this patch in his dsa driver work.
Regards,
Yi Liu
> From: Eric Auger
> Sent: Saturday, March 21, 2020 12:19 AM
> To: eric.auger@gmail.com; eric.au...@redhat.com;
On 2020/4/1 18:27, Marc Zyngier wrote:
And I think there is a similar issue in vgic_v3_lpi_sync_pending_status().
Why sync something back from the pending table when the LPI wasn't
mapped yet?
vgic_v3_lpi_sync_pending_status() can be called on the ITE restore path:
On Wed, Apr 01, 2020 at 06:08:10PM +0800, Jingyi Wang wrote:
> With the development of arm gic architecture, we think it will be useful
> to add some simple performance test in kut to measure the cost of
> interrupts. X86 arch has implemented similar test.
>
> Jingyi Wang (2):
> arm/arm64: gic:
On Tue, 31 Mar 2020 17:11:37 +0800
Zenghui Yu wrote:
Hi Zenghui,
> Hi Marc,
>
> On 2020/3/31 16:07, Marc Zyngier wrote:
> > Hi Zenghui,
[...]
> >> > > I've been thinking about this, and I wonder why we don't simply
> >> clear
> > the whole pending table instead of carefully wiping it
With the development of arm gic architecture, we think it will be useful
to add some simple performance test in kut to measure the cost of
interrupts. X86 arch has implemented similar test.
Jingyi Wang (2):
arm/arm64: gic: Add IPI latency test
arm/arm64: Add vtimer latency test
arm/gic.c
This patch add a test to measure the latency of IPI injection.
Signed-off-by: Jingyi Wang
---
arm/gic.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arm/gic.c b/arm/gic.c
index fcf4c1f..f5e830e 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -27,6 +27,9 @@ struct
This patch add a test to measure the precise vtimer firing time.
Signed-off-by: Jingyi Wang
---
arm/timer.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arm/timer.c b/arm/timer.c
index f390e8e..1d5b3dc 100644
--- a/arm/timer.c
+++ b/arm/timer.c
@@ -16,6 +16,9 @@
#define
13 matches
Mail list logo
