From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754684AbcKIWZ1 (ORCPT ); Wed, 9 Nov 2016 17:25:27 -0500 Received: from foss.arm.com ([217.140.101.70]:37194 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980AbcKIWZZ (ORCPT ); Wed, 9 Nov 2016 17:25:25 -0500 Date: Wed, 9 Nov 2016 22:25:22 +0000 From: Will Deacon To: Alex Williamson Cc: Christoffer Dall , Don Dutile , Eric Auger , eric.auger.pro@gmail.com, marc.zyngier@arm.com, robin.murphy@arm.com, joro@8bytes.org, tglx@linutronix.de, jason@lakedaemon.net, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, drjones@redhat.com, linux-kernel@vger.kernel.org, pranav.sawargaonkar@gmail.com, iommu@lists.linux-foundation.org, punit.agrawal@arm.com, diana.craciun@nxp.com, benh@kernel.crashing.org, arnd@arndb.de, jcm@redhat.com, dwmw@amazon.co.uk Subject: Re: Summary of LPC guest MSI discussion in Santa Fe Message-ID: <20161109222522.GS17771@arm.com> References: <20161103220205.37715b49@t450s.home> <20161108024559.GA20591@arm.com> <20161108202922.GC15676@cbox> <20161108163508.1bcae0c2@t450s.home> <58228F71.6020108@redhat.com> <20161109170326.GG17771@arm.com> <582371FB.2040808@redhat.com> <20161109192303.GD15676@cbox> <20161109203145.GO17771@arm.com> <20161109151709.74927f83@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161109151709.74927f83@t450s.home> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote: > On Wed, 9 Nov 2016 20:31:45 +0000 > Will Deacon wrote: > > On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote: > > > > > > (I suppose it's technically possible to get around this issue by letting > > > QEMU place RAM wherever it wants but tell the guest to never use a > > > particular subset of its RAM for DMA, because that would conflict with > > > the doorbell IOVA or be seen as p2p transactions. But I think we all > > > probably agree that it's a disgusting idea.) > > > > Disgusting, yes, but Ben's idea of hotplugging on the host controller with > > firmware tables describing the reserved regions is something that we could > > do in the distant future. In the meantime, I don't think that VFIO should > > explicitly reject overlapping mappings if userspace asks for them. > > I'm confused by the last sentence here, rejecting user mappings that > overlap reserved ranges, such as MSI doorbell pages, is exactly how > we'd reject hot-adding a device when we meet such a conflict. If we > don't reject such a mapping, we're knowingly creating a situation that > potentially leads to data loss. Minimally, QEMU would need to know > about the reserved region, map around it through VFIO, and take > responsibility (somehow) for making sure that region is never used for > DMA. Thanks, Yes, but my point is that it should be up to QEMU to abort the hotplug, not the host kernel, since there may be ways in which a guest can tolerate the overlapping region (e.g. by avoiding that range of memory for DMA). Will