From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: [PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation Date: Wed, 07 Oct 2015 18:46:04 +0300 Message-ID: <028c01d10117$46bd9440$d438bcc0$@samsung.com> References: <1444229726-31559-1-git-send-email-andre.przywara@arm.com> <1444229726-31559-13-git-send-email-andre.przywara@arm.com> <026901d10112$4dea39d0$e9bead70$@samsung.com> <56153BD2.1050904@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: eric.auger@linaro.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org To: 'Marc Zyngier' , 'Andre Przywara' , christoffer.dall@linaro.org Return-path: Received: from mailout2.w1.samsung.com ([210.118.77.12]:13093 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754410AbbJGPqI (ORCPT ); Wed, 7 Oct 2015 11:46:08 -0400 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NVU00EJ3X4T2P60@mailout2.w1.samsung.com> for kvm@vger.kernel.org; Wed, 07 Oct 2015 16:46:05 +0100 (BST) In-reply-to: <56153BD2.1050904@arm.com> Content-language: ru Sender: kvm-owner@vger.kernel.org List-ID: Hello! > Sure. And you then have to parse and validate all the tables each and > every time you're going to inject an interrupt (because the guest can > change the table content behind your back). You are quickly going to > notice that your performance is abysmal. I don't see any real problems, at least with LPI tables. If the guest changes something, it will be immediately available to us. I don't see any need to seriously validate something, at least here. Pending bit is just pending bit, and configuration is just priority value plus enable bit. But, well, if we think a bit better, in case of pending bit modification, the operations on both guest and host side have to be atomic, otherwise we can clobber our table if, for example, both host and guest modify adjacent bits. And there's no way to interlock with the guest. So, OK, i accept your point. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia