On Thu, Apr 16, 2015 at 04:46:59PM +0100, Stuart Yoder wrote: > > > > So, whilst it's great that you're looking at the code, I'm not very > > > > keen on > > > > merging anything until we have people committed to using it. Right now, > > > > the > > > > only feedback I've had has been going in the para-virt direction and I > > > > don't > > > > think we should do this "for fun". > > > Freescale would be interested in using the vSMMU implementation. We have > > > use cases for assigning devices to guest user space. Are you suggesting > > > that you are more inclined to using the para virtualized approach? > > > > I can see arguments either way; the vSMMU means that the guest can use the > > same SMMU driver as the host but a para-virtualised approach could > > theoretically be used across multiple SMMU implementations as well as > > potentially being kinder on the TLB. > > In the paravirt approach is the guest managing its own stage 1 > page tables (read directly by the hardware SMMU)?
No; ideally the paravirtualised interface would abstract any details of the hardware, including page table format. So you might have a "map" hvc call that takes iova, (guest) phys, size, for example. Then the hypervisor would manually collapse that into the current page tables using iommu_map. > Is there anything written up anywhere sketching out how the paravirt > approach would work? Are there any limitations vs the vSMMU? Not yet, and that's exactly the kind of research/investigation I'd like to see happening before we commit ourselves one way or the other. Will _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
