From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754948AbdKGPYj (ORCPT ); Tue, 7 Nov 2017 10:24:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37628 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbdKGPYh (ORCPT ); Tue, 7 Nov 2017 10:24:37 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 83F5BC058ED8 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved To: Marc Zyngier , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20171027142855.21584-1-marc.zyngier@arm.com> <20171027142855.21584-24-marc.zyngier@arm.com> Cc: Mark Rutland , Andre Przywara , Shameerali Kolothum Thodi , Christoffer Dall , Shanker Donthineni From: Auger Eric Message-ID: <1f75a11a-41c3-71b8-6abf-4aa2962e348e@redhat.com> Date: Tue, 7 Nov 2017 16:24:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20171027142855.21584-24-marc.zyngier@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 07 Nov 2017 15:24:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > The GICv4 architecture doesn't make it easy for save/restore to > work, as it doesn't give any guarantee that the pending state > is written into the pending table. I don't understand where does the limitation exactly come from. Can't we use the GICR_VPENDBASER table data? Thanks Eric > > So let's not take any chance, and let's return an error if > we encounter any LPI that has the HW bit set. In order for > userspace to distinguish this error from other failure modes, > use -EACCES as an error code. > > Signed-off-by: Marc Zyngier > --- > Documentation/virtual/kvm/devices/arm-vgic-its.txt | 2 ++ > virt/kvm/arm/vgic/vgic-its.c | 9 +++++++++ > 2 files changed, 11 insertions(+) > > diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt > index eb06beb75960..1eec7bcb2d52 100644 > --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt > +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt > @@ -60,6 +60,8 @@ Groups: > -EINVAL: Inconsistent restored data > -EFAULT: Invalid guest ram access > -EBUSY: One or more VCPUS are running > + -EACCES: The virtual ITS is backed by a physical GICv4 ITS, and the > + state is not available > > KVM_DEV_ARM_VGIC_GRP_ITS_REGS > Attributes: > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index eb72eb027060..2710834d0920 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -1989,6 +1989,15 @@ static int vgic_its_save_itt(struct vgic_its *its, struct its_device *device) > list_for_each_entry(ite, &device->itt_head, ite_list) { > gpa_t gpa = base + ite->event_id * ite_esz; > > + /* > + * If an LPI carries the HW bit, this means that this > + * interrupt is controlled by GICv4, and we do not > + * have direct access to that state. Let's simply fail > + * the save operation... > + */ > + if (ite->irq->hw) > + return -EACCES; > + > ret = vgic_its_save_ite(its, device, ite, gpa, ite_esz); > if (ret) > return ret; >