Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp2396383ybh; Mon, 5 Aug 2019 00:11:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwn7oefObJFqj6cKr1mR5kJpkroX6iH4fAg+ZJo72Myv01aqEbZkBb1sEbA1HURj+Ubz0En X-Received: by 2002:a63:1341:: with SMTP id 1mr27973668pgt.48.1564989085636; Mon, 05 Aug 2019 00:11:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564989085; cv=none; d=google.com; s=arc-20160816; b=cIIcCFLrBHst5Agg8M32IB3zJ7rkaOUbPOXDcxkr1G/uajmJRbOga7KpBy2hPlhZLe 3I2GBrR+FSoAa5vG0yaLZ7BCWPvagyFI3x5VAD6xaAdOS3k+TivG9I6SQTk2qPtkI74n RZdI4wGXYrrMiI0o1y4mH21IKzv4cUtgHrMSu10vrfuIpy5o9F2dvNir0+PhWJPIvK8D W2uPXtcxtHy2bkrtTMEZCGzofya3X/ycsxOPbR+ac3ATAYvEnOLaWKkePKoAoFzKN4oK EgDa8scBTXZlnsC781zIpyZjW2RGNRUVReEd1Lxu2uaXneKT9vqAJNdom5cHyPNlHlhK /L3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:openpgp:from:references:cc:to:subject; bh=ZevUiv8uwSdDDjAx9KzB+mkgl2A2MlBAMqJYEcYxJb4=; b=lIXjJv6sBuFAjViMfNjJNN4ARQU+rNYBCOilqOnxeQqb9cyb6NvshCecvU10Dl6eaN OlEaVknQjsBytVDAbSRKV8uXPddeEhmr11ea4Lu3h0Om4u3dUASoIl1KCyWxN8qG0PD5 NiaN+JuUh8WJgQ+6bninwzyTCJ+p4VzkrIwbB7CDmCMGpdc/vgYIjWmI/GMmoEj1AE0q LQkwh1wgRDvIeEqn3abPe6wLlSJkZRaC4g498rUuUAmF+AppkT2n2NQ1ltg5AUL3Kldh l8DdiONJeBfI21CKAvR2XqdbFL0KA2VW6PkQtvp4IMb+w5PIfvEuw9CxPEk87YT9NOYj Dt5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j185si43530030pge.91.2019.08.05.00.11.09; Mon, 05 Aug 2019 00:11:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727256AbfHEHKf (ORCPT + 99 others); Mon, 5 Aug 2019 03:10:35 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:42682 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726518AbfHEHKf (ORCPT ); Mon, 5 Aug 2019 03:10:35 -0400 Received: by mail-wr1-f65.google.com with SMTP id x1so33329437wrr.9 for ; Mon, 05 Aug 2019 00:10:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZevUiv8uwSdDDjAx9KzB+mkgl2A2MlBAMqJYEcYxJb4=; b=VNkFjk2VA4yKzW2hyeg0goQYjSulpLwjv34xgLelHkORELoJMe0IcUALiS2QYAJajA rhZhDuKTuBYv48wzkQ0tlXrNTwzQyul0i59ev5o38kKnVJXUCGNHr1V/J9DO/Akpu9b6 q3GqlS6vCVe7NHJfjf8gD0yJD3v3PUxTqDVvntUqMGQZAsmxGO3CgLUy3a/MDxrlmUyf HOS+nNGcs5HZ7Qt47lSDpFo/MWW9Ilc6JaKzHbZn3uAJDb7N+ilpzrzbfJ7G+CGC9jgY EmaaR4Hl0Qqw9f2sF0wKE5hR+K932FDFDudZIluk1d1jwJAWKPuoau/E41zdbgUOyg04 XNng== X-Gm-Message-State: APjAAAWp0tyGGXQBh39CqyNkNrEh3DaW4qcWzy5qVBkzmuFOx61x5emN j6iMwuN0wWUIwuLvTCtyJwNVTSmtKs4= X-Received: by 2002:a05:6000:42:: with SMTP id k2mr38385884wrx.80.1564989033079; Mon, 05 Aug 2019 00:10:33 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:4013:e920:9388:c3ff? ([2001:b07:6468:f312:4013:e920:9388:c3ff]) by smtp.gmail.com with ESMTPSA id t185sm74525739wma.11.2019.08.05.00.10.31 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 00:10:32 -0700 (PDT) Subject: Re: [RFC PATCH v2 07/19] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls To: Anup Patel Cc: Anup Patel , Palmer Dabbelt , Paul Walmsley , Radim K , Daniel Lezcano , Thomas Gleixner , Atish Patra , Alistair Francis , Damien Le Moal , Christoph Hellwig , "kvm@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-kernel@vger.kernel.org" References: <20190802074620.115029-1-anup.patel@wdc.com> <20190802074620.115029-8-anup.patel@wdc.com> <03f60f3a-bb50-9210-8352-da16cca322b9@redhat.com> From: Paolo Bonzini Openpgp: preference=signencrypt Message-ID: Date: Mon, 5 Aug 2019 09:10:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/08/19 08:55, Anup Patel wrote: > On Fri, Aug 2, 2019 at 2:33 PM Paolo Bonzini wrote: >> >> On 02/08/19 09:47, Anup Patel wrote: >>> + if (reg_num == KVM_REG_RISCV_CSR_REG(sip)) >>> + kvm_riscv_vcpu_flush_interrupts(vcpu, false); >> >> Not updating the vsip CSR here can cause an interrupt to be lost, if the >> next call to kvm_riscv_vcpu_flush_interrupts finds a zero mask. > > Thanks for catching this issue. I will address it in v3. > > If we think more on similar lines then we also need to handle the case > where Guest VCPU had pending interrupts and we suddenly stopped it > for Guest migration. In this case, we would eventually use SET_ONE_REG > ioctl on destination Host which should set vsip_shadow instead of vsip so > that we force update HW after resuming Guest VCPU on destination host. I think it's simpler than that. vcpu->vsip_shadow is just the current value of CSR_VSIP so that you do not need to update it unconditionally on every vmentry. That is, kvm_vcpu_arch_load should do csr_write(CSR_VSIP, vcpu->arch.guest_csr.vsip); vcpu->vsip_shadow = vcpu->arch.guest_csr.vsip; while every other write can go through kvm_riscv_update_vsip. But vsip_shadow is completely disconnected from SET_ONE_REG; SET_ONE_REG can just write vcpu->arch.guest_csr.vsip and clear irqs_pending_mask, the next entry will write CSR_VSIP and vsip_shadow if needed. In fact, instead of placing it in kvm_vcpu, vsip_shadow could be a percpu variable; on hardware_enable you write 0 to both vsip_shadow and CSR_VSIP, and then kvm_arch_vcpu_load does not have to touch CSR_VSIP at all (only kvm_riscv_vcpu_flush_interrupts). I think this makes the purpose of vsip_shadow even clearer, so I highly suggest doing that. >> You could add a new field vcpu->vsip_shadow that is updated every time >> CSR_VSIP is written (including kvm_arch_vcpu_load) with a function like >> >> void kvm_riscv_update_vsip(struct kvm_vcpu *vcpu) >> { >> if (vcpu->vsip_shadow != vcpu->arch.guest_csr.vsip) { >> csr_write(CSR_VSIP, vcpu->arch.guest_csr.vsip); >> vcpu->vsip_shadow = vcpu->arch.guest_csr.vsip; >> } >> } >> >> And just call this unconditionally from kvm_vcpu_ioctl_run. The cost is >> just a memory load per VS-mode entry, it should hardly be measurable. > > I think we can do this at start of kvm_riscv_vcpu_flush_interrupts() as well. Did you mean at the end? (That is, after modifying vcpu->arch.guest_csr.vsip based on mask and val). With the above switch to percpu, the only write of CSR_VSIP and vsip_shadow should be in kvm_riscv_vcpu_flush_interrupts, which in turn is only called from kvm_vcpu_ioctl_run. Thanks, Paolo