From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752518AbdGMRos (ORCPT ); Thu, 13 Jul 2017 13:44:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45078 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751216AbdGMRoq (ORCPT ); Thu, 13 Jul 2017 13:44:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 366F0BC6A3 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mst@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 366F0BC6A3 Date: Thu, 13 Jul 2017 20:44:38 +0300 From: "Michael S. Tsirkin" To: Jean-Philippe Brucker Cc: Will Deacon , Eric Auger , eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, robin.murphy@arm.com, christoffer.dall@linaro.org, Marc.Zyngier@arm.com, alex.williamson@redhat.com, peterx@redhat.com Subject: Re: [RFC 0/2] arm-smmu-v3 tlbi-on-map option Message-ID: <20170713204107-mutt-send-email-mst@kernel.org> References: <1499613303-30173-1-git-send-email-eric.auger@redhat.com> <20170712175454.GF15191@arm.com> <20170712223654-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 13 Jul 2017 17:44:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 13, 2017 at 10:29:42AM +0100, Jean-Philippe Brucker wrote: > On 12/07/17 23:07, Michael S. Tsirkin wrote: > [...] > > I think using hardware support for nesting is the right final > > solution. It will take some time though. Given this, what should > > we do meanwhile? > > > > Assuming that's the final destination, a simple quirk like this > > seems to be preferable to virtio-iommu which we'll never be > > able to offload to hardware. > > That's not entirely true. virtio-iommu will have an extension for hardware > nesting support. It was presented in my initial proposal, and I've made > significant progress since then. > > Thanks, > Jean I don't recall seeing this. Hardware specific extensions to virtio would be interesting, the difficulty is in finding the balance between enabling minor quirks and each vendor going their own way. Is this the proposal you refer to? https://www.spinics.net/lists/kvm/msg147990.html I couldn't find any mention of nesting, it seems to say that map requests are relayed through host. -- MST