On Wed, Jul 05, 2017 at 08:20:31AM +0200, Alexander Graf wrote:
> The kvm_age_hva callback may be called all the way concurrently while
> kvm_mmu_notifier_release() is running.
>
> The release function sets kvm->arch.pgd = NULL which the aging function
> however implicitly relies on in stage2_get_
On Tue, Jul 04, 2017 at 07:32:37PM +, Raz wrote:
> The entry woken in the vector is IRQ 64-bit EL1 ( same as el1_irq in
> kvn/hyp.S ).
> ESR_EL2.EC = 0x16 -" HVC executed in EL2". It does not change.
ESR_EL2 doesn't say anything meaningful if you're taking an asynchronous
exception, like the
The kvm_age_hva callback may be called all the way concurrently while
kvm_mmu_notifier_release() is running.
The release function sets kvm->arch.pgd = NULL which the aging function
however implicitly relies on in stage2_get_pud(). That means they can
race and the aging function may dereference a N
On Wed, 28 Jun 2017, Marc Zyngier wrote:
> When assigning an interrupt to a vcpu, it is not unlikely that
> the level of the hierarchy implementing irq_set_vcpu_affinity
> is not the top level (think a generic MSI domain on top of a
> virtualization aware interrupt controller).
>
> In such a ca
The entry woken in the vector is IRQ 64-bit EL1 ( same as el1_irq in
kvn/hyp.S ).
ESR_EL2.EC = 0x16 -" HVC executed in EL2". It does not change.
Jintack
CPSR.I is 1 , but I do not think I can just clear it, if that what you
mean...
Chrtistoph
You deactivate traps in kvm_vcpu_return( called fro
On 04/07/2017 15:58, Andrew Jones wrote:
> Add a test for the vtimer. I've tested on
> accel=tcg
> accel=kvm,kernel-irqchip=on : on thunderx, seattle, and mustang
> accel=kvm,kernel-irqchip=off : on thunderx and mustang
>
> It works everywhere without modification except on mustang. My mustang
Signed-off-by: Andrew Jones
---
arm/timer.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arm/timer.c b/arm/timer.c
index ec110ee08d97..89f4c9400ab6 100644
--- a/arm/timer.c
+++ b/arm/timer.c
@@ -17,6 +17,21 @@
static u32 vtimer_irq, vtimer_irq_flag
Add a test for the vtimer. I've tested on
accel=tcg
accel=kvm,kernel-irqchip=on : on thunderx, seattle, and mustang
accel=kvm,kernel-irqchip=off : on thunderx and mustang
It works everywhere without modification except on mustang. My mustang
seems to have a hardware problem requiring bit 31 of
From: Alexander Graf
All virtualization capable ARM cores support the ARM virtual timer.
Add minimalistic check for firing a virtual timer event, confirming
by checking that the timer pin is marked as pending on the GIC.
Signed-off-by: Alexander Graf
[ Applied my review comments and a few othe
Hi Eric,
On 15/06/17 13:52, Eric Auger wrote:
> Currently, the line level of unmapped level sensitive SPIs is
> toggled down by the maintenance IRQ handler/resamplefd mechanism.
>
> As mapped SPI completion is not trapped, we cannot rely on this
> mechanism and the line level needs to be observed
On Mon, Jul 03, 2017 at 09:56:06PM +, Raz wrote:
> Hey
>
> I am trying to trap any real IRQ into EL2.
> I created a thin hypervisor with mmu enabled and set hcr_el2 as follows:
> hcr_el2= HCR_IMO | HCR_VM | HCR_RW.
>
>
> Now it seems that once I set hcr_el2 to the above value and then exit
Hi Drew,
On Sat, Jul 01, 2017 at 06:26:54PM +0200, Andrew Jones wrote:
> kvm_pmu_overflow_set() is called from perf's interrupt handler,
> making the call of kvm_vgic_inject_irq() from it introduced with
> "KVM: arm/arm64: PMU: remove request-less vcpu kick" a really bad
> idea, as it's quite easy
Hi James,
Thanks for the review. I will read your comments carefully and then reply to
you.
On 2017/7/4 18:14, James Morse wrote:
> Hi gengdongjiu,
>
> Can you give us a specific example of an error you are trying to handle?
> How would a non-KVM user space process handle the error?
>
> KVM-
Hi gengdongjiu,
Can you give us a specific example of an error you are trying to handle?
How would a non-KVM user space process handle the error?
KVM-users should be regular user space processes, we should not have a KVM-way
and everyone-else-way of handling errors.
On 04/07/17 05:46, gengdongj
Hi Dongjiu,
On Tue, Jul 04, 2017 at 12:46:23PM +0800, gengdongjiu wrote:
> Hi Christoffer,
> thanks for the review.
>
>
> On 2017/7/3 16:39, Christoffer Dall wrote:
> > Hi Dongjiu,
> >
> > On Mon, Jun 26, 2017 at 08:46:39PM +0800, Dongjiu Geng wrote:
> >> when SError happen, kvm notifies user
Hi Dongjiu,
On Tue, Jul 04, 2017 at 02:30:21PM +0800, gengdongjiu wrote:
> Hi Christoffer,
>
> On 2017/7/3 16:23, Christoffer Dall wrote:
> > On Tue, Jun 27, 2017 at 08:15:49PM +0800, gengdongjiu wrote:
> >> correct the commit message:
> >>
> >> In the firmware-first RAS solution, OS receives a
Hi Dongjiu,
On Tue, Jul 04, 2017 at 03:04:54PM +0800, gengdongjiu wrote:
> Hi Christoffer,
>
> On 2017/7/3 16:21, Christoffer Dall wrote:
> > On Mon, Jun 26, 2017 at 08:45:43PM +0800, Dongjiu Geng wrote:
> >> Handle userspace's detection for RAS extension, because sometimes
> >> the userspace nee
On Tue, Jul 04, 2017 at 01:41:49AM +0200, Andrea Arcangeli wrote:
> Hello,
>
> On Mon, Jul 03, 2017 at 10:48:03AM +0200, Alexander Graf wrote:
> > On 07/03/2017 10:03 AM, Christoffer Dall wrote:
> > > Hi Alex,
> > >
> > > On Fri, Jun 23, 2017 at 05:21:59PM +0200, Alexander Graf wrote:
> > >> If we
Hi Christoffer,
On 2017/7/3 16:21, Christoffer Dall wrote:
> On Mon, Jun 26, 2017 at 08:45:43PM +0800, Dongjiu Geng wrote:
>> Handle userspace's detection for RAS extension, because sometimes
>> the userspace needs to know the CPU's capacity
>
> Why? Can you please provide some more rationale.
19 matches
Mail list logo
