From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755681AbdKGQMS (ORCPT ); Tue, 7 Nov 2017 11:12:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33758 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752557AbdKGQMR (ORCPT ); Tue, 7 Nov 2017 11:12:17 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BE9A9C04AC43 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.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> <1f75a11a-41c3-71b8-6abf-4aa2962e348e@redhat.com> <9c1e1c92-e0fa-737f-63ab-a335b93af6da@arm.com> Cc: Mark Rutland , Andre Przywara , Shameerali Kolothum Thodi , Christoffer Dall , Shanker Donthineni From: Auger Eric Message-ID: <77d479e5-98f9-9081-a3a6-87bef1009775@redhat.com> Date: Tue, 7 Nov 2017 17:12:12 +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: <9c1e1c92-e0fa-737f-63ab-a335b93af6da@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.31]); Tue, 07 Nov 2017 16:12:17 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 07/11/2017 16:38, Marc Zyngier wrote: > On 07/11/17 15:24, Auger Eric wrote: >> 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? > You can't. None of the tables that are written by either the ITS or the > redistributors are architected. All you know is that there is one bit > per vLPI, but that's it (you don't even know which one is which). Oh I thought the redistributor config and pending tables were fully specified (6.1.2 and 6.1.3 of the spec), except the 1kB of the pending table. > > But that's not a big deal. I don't think you can realistically migrate a > VM that has a directly assigned device anyway. Or can we? No we can't except for mediated devices for which migration can be supported. Thanks Eric > > Thanks, > > M. >