lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 1 Feb 2017 10:01:02 +0000 From: Marc Zyngier <marc.zyngier@....com> To: Christoffer Dall <christoffer.dall@...aro.org> Cc: Jintack Lim <jintack@...columbia.edu>, pbonzini@...hat.com, rkrcmar@...hat.com, linux@...linux.org.uk, catalin.marinas@....com, will.deacon@....com, andre.przywara@....com, kvm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu, linux-kernel@...r.kernel.org Subject: Re: [RFC v2 06/10] KVM: arm/arm64: Update the physical timer interrupt level On 01/02/17 08:04, Christoffer Dall wrote: > On Sun, Jan 29, 2017 at 03:21:06PM +0000, Marc Zyngier wrote: >> On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim <jintack@...columbia.edu> wrote: >>> Now that we maintain the EL1 physical timer register states of VMs, >>> update the physical timer interrupt level along with the virtual one. >>> >>> Note that the emulated EL1 physical timer is not mapped to any hardware >>> timer, so we call a proper vgic function. >>> >>> Signed-off-by: Jintack Lim <jintack@...columbia.edu> >>> --- >>> virt/kvm/arm/arch_timer.c | 20 ++++++++++++++++++++ >>> 1 file changed, 20 insertions(+) >>> >>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c >>> index 0f6e935..3b6bd50 100644 >>> --- a/virt/kvm/arm/arch_timer.c >>> +++ b/virt/kvm/arm/arch_timer.c >>> @@ -180,6 +180,21 @@ static void kvm_timer_update_mapped_irq(struct kvm_vcpu *vcpu, bool new_level, >>> WARN_ON(ret); >>> } >>> >>> +static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level, >>> + struct arch_timer_context *timer) >>> +{ >>> + int ret; >>> + >>> + BUG_ON(!vgic_initialized(vcpu->kvm)); >> >> Although I've added my fair share of BUG_ON() in the code base, I've >> since reconsidered my position. If we get in a situation where the vgic >> is not initialized, maybe it would be better to just WARN_ON and return >> early rather than killing the whole box. Thoughts? >> > > Could we help this series along by saying that since this BUG_ON already > exists in the kvm_timer_update_mapped_irq function, then it just > preserves functionality and it's up to someone else (me) to remove the > BUG_ON from both functions later in life? Works for me. M. -- Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists