On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote: > On Wed, 9 Nov 2016 20:31:45 +0000 > Will Deacon <will.deacon@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
