>>> On 07.09.18 at 17:24, <paul.durr...@citrix.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 07 September 2018 15:56 >> >> >>> On 07.09.18 at 14:36, <paul.durr...@citrix.com> wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 07 September 2018 12:11 >> >> >> >> >>> On 23.08.18 at 11:47, <paul.durr...@citrix.com> wrote: >> >> > This patch adds a new method to the VT-d IOMMU implementation to >> find >> >> the >> >> > MFN currently mapped by the specified BFN along with a wrapper >> function >> >> in >> >> > generic IOMMU code to call the implementation if it exists. >> >> >> >> For this to go in, I think the AMD side of it wants to also be >> >> implemented. >> > >> > Why? It can be done later. Nothing existing is going to break if it is not >> > implemented. >> >> If it was something that's terribly difficult to implement, I'd >> probably agree. But introducing PV IOMMU for Intel only (and >> hence once again making AMD a second class citizen) I don't >> really like. Another thing would be if you had the implementation >> ready, but the maintainer(s) don't respond... >> > > It's all time though. The fact is that, in XenServer, we've never had > PV-IOMMU for AMD. It would be wonderful to have it for AMD too and indeed I > may find the time to do it, but is that really a reason to block integration > of these patches when no actual regression will be caused by of the lack of > AMD support?
First of all - I don't mean to block anything. I deliberately said "I think it wants to be", not "It needs to be". But beyond that my second class citizen statement stands - it's no different from e.g. introducing VMX support, but not SVM one. That also is not resulting in any regression, but still is not very desirable. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
