Advice on HYP interface for AsyncPF
I'm working with AsyncPF, and currently using hyp call to communicate guest GFN for host to inject virtual abort - page not available/page available. Currently only PSCI makes use of that interface, (handle_hvc()) can we overload interface with additional hyp calls in this case pass guest gfn? Set arg0 to some range outside of PSCI use. - Mario ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH] arm: KVM: force execution of HCPTR access on VM exit
On Mon, Mar 16, 2015 at 10:59:43AM +, Marc Zyngier wrote: On VM entry, we disable access to the VFP registers in order to perform a lazy save/restore of these registers. On VM exit, we restore access, test if we did enable them before, and save/restore the guest/host registers if necessary. In this sequence, the FPEXC register is always accessed, irrespective of the trapping configuration. If the guest didn't touch the VFP registers, then the HCPTR access has now enabled such access, but we're missing a barrier to ensure architectural execution of the new HCPTR configuration. If the HCPTR access has been delayed/reordered, the subsequent access to FPEXC will cause a trap, which we aren't prepared to handle at all. The fix is to introduce a barrier that only takes place if the guest hasn't accessed its view of the VFP registers, making the access to FPEXC safe. Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- arch/arm/kvm/interrupts.S | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S index 79caf79..3ac7aca 100644 --- a/arch/arm/kvm/interrupts.S +++ b/arch/arm/kvm/interrupts.S @@ -175,10 +175,13 @@ __kvm_vcpu_return: #ifdef CONFIG_VFPv3 @ Save floating point registers we if let guest use them. tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11)) - bne after_vfp_restore + beq 1f + + isb @ Force execution of HCPTR if we've just reenabled VFP access + b after_vfp_restore @ Switch VFP/NEON hardware state to the host's - add r7, vcpu, #VCPU_VFP_GUEST +1: add r7, vcpu, #VCPU_VFP_GUEST store_vfp_state r7 add r7, vcpu, #VCPU_VFP_HOST ldr r7, [r7] -- 2.1.4 Reviewed-by: Christoffer Dall christoffer.d...@linaro.org ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: linux-next: manual merge of the kvm-arm tree with Linus' tree
On Wed, Apr 08, 2015 at 09:15:13AM +0100, Marc Zyngier wrote:
On Tue, 7 Apr 2015 17:20:15 +0100
Paolo Bonzini pbonz...@redhat.com wrote:
Hi Paolo,
On 18/03/2015 08:55, Christoffer Dall wrote:
Hi Stephen,
On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit ae705930fca6 (arm/arm64: KVM: Keep
elrsr/aisr in sync with software model) from Linus' tree and commit
71760950bf3d (arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn)
from the kvm-arm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,ffd937ca5141..
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
if (vlr.source == sgi_source_id) {
kvm_debug(LR%d piggyback for IRQ%d\n, lr,
vlr.irq);
BUG_ON(!test_bit(lr, vgic_cpu-lr_used));
-vlr.state |= LR_STATE_PENDING;
-vgic_set_lr(vcpu, lr, vlr);
+vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
+ vgic_sync_lr_elrsr(vcpu, lr, vlr);
return true;
}
}
@@@ -1001,12 -1109,8 +1116,9 @@@
vlr.irq = irq;
vlr.source = sgi_source_id;
-vlr.state = LR_STATE_PENDING;
-if (!vgic_irq_is_edge(vcpu, irq))
-vlr.state |= LR_EOI_INT;
-
-vgic_set_lr(vcpu, lr, vlr);
+vlr.state = 0;
+vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
+ vgic_sync_lr_elrsr(vcpu, lr, vlr);
return true;
}
Looks great, thanks!
-Christoffer
Got the same conflict when pulling from the kvm-arm tree, I used
a different resolution though:
diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,b70174e74868..8d550ff14700
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
}
}
+ static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
+int lr_nr, struct vgic_lr vlr)
+ {
+ if (vgic_irq_is_active(vcpu, irq)) {
+ vlr.state |= LR_STATE_ACTIVE;
+ kvm_debug(Set active, clear distributor: 0x%x\n, vlr.state);
+ vgic_irq_clear_active(vcpu, irq);
+ vgic_update_state(vcpu-kvm);
+ } else if (vgic_dist_irq_is_pending(vcpu, irq)) {
+ vlr.state |= LR_STATE_PENDING;
+ kvm_debug(Set pending: 0x%x\n, vlr.state);
+ }
+
+ if (!vgic_irq_is_edge(vcpu, irq))
+ vlr.state |= LR_EOI_INT;
+
+ vgic_set_lr(vcpu, lr_nr, vlr);
++ vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
+ }
+
/*
* Queue an interrupt to a CPU virtual interface. Return true on success,
* or false if it wasn't possible to queue it.
@@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
if (vlr.source == sgi_source_id) {
kvm_debug(LR%d piggyback for IRQ%d\n, lr,
vlr.irq);
BUG_ON(!test_bit(lr, vgic_cpu-lr_used));
- vlr.state |= LR_STATE_PENDING;
- vgic_set_lr(vcpu, lr, vlr);
- vgic_sync_lr_elrsr(vcpu, lr, vlr);
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
return true;
}
}
@@@ -1001,12 -1158,8 +1165,8 @@@
vlr.irq = irq;
vlr.source = sgi_source_id;
- vlr.state = LR_STATE_PENDING;
- if (!vgic_irq_is_edge(vcpu, irq))
- vlr.state |= LR_EOI_INT;
-
- vgic_set_lr(vcpu, lr, vlr);
- vgic_sync_lr_elrsr(vcpu, lr, vlr);
+ vlr.state = 0;
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
return true;
}
Christoffer, this is the same logic as Stephen's resolution, but
can you confirm that it makes sense semantically as well?
This looks like a sensible resolution to me. I've given it a spin, and
it seems to behave as expected.
Yes, this is semantically slightly nicer in fact.
Thanks,
-Christoffer
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: linux-next: manual merge of the kvm-arm tree with Linus' tree
On Tue, 7 Apr 2015 17:20:15 +0100
Paolo Bonzini pbonz...@redhat.com wrote:
Hi Paolo,
On 18/03/2015 08:55, Christoffer Dall wrote:
Hi Stephen,
On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit ae705930fca6 (arm/arm64: KVM: Keep
elrsr/aisr in sync with software model) from Linus' tree and commit
71760950bf3d (arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn)
from the kvm-arm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,ffd937ca5141..
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
if (vlr.source == sgi_source_id) {
kvm_debug(LR%d piggyback for IRQ%d\n, lr, vlr.irq);
BUG_ON(!test_bit(lr, vgic_cpu-lr_used));
- vlr.state |= LR_STATE_PENDING;
- vgic_set_lr(vcpu, lr, vlr);
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
+ vgic_sync_lr_elrsr(vcpu, lr, vlr);
return true;
}
}
@@@ -1001,12 -1109,8 +1116,9 @@@
vlr.irq = irq;
vlr.source = sgi_source_id;
- vlr.state = LR_STATE_PENDING;
- if (!vgic_irq_is_edge(vcpu, irq))
- vlr.state |= LR_EOI_INT;
-
- vgic_set_lr(vcpu, lr, vlr);
+ vlr.state = 0;
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
+ vgic_sync_lr_elrsr(vcpu, lr, vlr);
return true;
}
Looks great, thanks!
-Christoffer
Got the same conflict when pulling from the kvm-arm tree, I used
a different resolution though:
diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,b70174e74868..8d550ff14700
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
}
}
+ static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
+ int lr_nr, struct vgic_lr vlr)
+ {
+ if (vgic_irq_is_active(vcpu, irq)) {
+ vlr.state |= LR_STATE_ACTIVE;
+ kvm_debug(Set active, clear distributor: 0x%x\n, vlr.state);
+ vgic_irq_clear_active(vcpu, irq);
+ vgic_update_state(vcpu-kvm);
+ } else if (vgic_dist_irq_is_pending(vcpu, irq)) {
+ vlr.state |= LR_STATE_PENDING;
+ kvm_debug(Set pending: 0x%x\n, vlr.state);
+ }
+
+ if (!vgic_irq_is_edge(vcpu, irq))
+ vlr.state |= LR_EOI_INT;
+
+ vgic_set_lr(vcpu, lr_nr, vlr);
++vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
+ }
+
/*
* Queue an interrupt to a CPU virtual interface. Return true on success,
* or false if it wasn't possible to queue it.
@@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
if (vlr.source == sgi_source_id) {
kvm_debug(LR%d piggyback for IRQ%d\n, lr, vlr.irq);
BUG_ON(!test_bit(lr, vgic_cpu-lr_used));
- vlr.state |= LR_STATE_PENDING;
- vgic_set_lr(vcpu, lr, vlr);
- vgic_sync_lr_elrsr(vcpu, lr, vlr);
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
return true;
}
}
@@@ -1001,12 -1158,8 +1165,8 @@@
vlr.irq = irq;
vlr.source = sgi_source_id;
- vlr.state = LR_STATE_PENDING;
- if (!vgic_irq_is_edge(vcpu, irq))
- vlr.state |= LR_EOI_INT;
-
- vgic_set_lr(vcpu, lr, vlr);
- vgic_sync_lr_elrsr(vcpu, lr, vlr);
+ vlr.state = 0;
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
return true;
}
Christoffer, this is the same logic as Stephen's resolution, but
can you confirm that it makes sense semantically as well?
This looks like a sensible resolution to me. I've given it a spin, and
it seems to behave as expected.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
