> -----Original Message----- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 13 September 2018 07:41 > To: Paul Durrant <paul.durr...@citrix.com>; 'Jan Beulich' > <jbeul...@suse.com> > Cc: Stefano Stabellini <sstabell...@kernel.org>; Wei Liu > <wei.l...@citrix.com>; Konrad Rzeszutek Wilk <konrad.w...@oracle.com>; > Andrew Cooper <andrew.coop...@citrix.com>; Tim (Xen.org) > <t...@xen.org>; George Dunlap <george.dun...@citrix.com>; Julien Grall > <julien.gr...@arm.com>; xen-devel <xen-devel@lists.xenproject.org>; Ian > Jackson <ian.jack...@citrix.com> > Subject: RE: [PATCH v6 13/14] x86: add iommu_ops to modify and flush > IOMMU mappings > > > From: Paul Durrant > > Sent: Wednesday, September 12, 2018 4:02 PM > > > > > > > In order to avoid shooting down all pre-existing RAM mappings - is > > > there no way the page table entries could be marked to identify > > > their origin? > > > > > > > I don't know whether that is possible; I'll have to find specs for Intel and > > AMD IOMMUs and see if they have PTE bits available for such a use. > > there are ignored bits > > > > > > I also have another more general concern: Allowing the guest to > > > manipulate its IOMMU page tables means that it can deliberately > > > shatter large pages, growing the overall memory footprint of the > > > domain. I'm hesitant to say this, but I'm afraid that resource > > > tracking of such "behind the scenes" allocations might be a > > > necessary prereq for the PV IOMMU work. > > > > > > > Remember that PV-IOMMU is only available for dom0 as it stands (and that > > is the only use-case that XenServer currently has) so I think that, whilst > > the > > concern is valid, there is no need danger in putting the code without such > > tracking. Such work can be deferred to making PV-IOMMU for de- > privileged > > guests... if that facility is needed. > > > > I didn't get why this is PV-IOMMU specific. Guest can always manipulate > guest CPU page table to shatter large pages too... >
At the moment that is true. I guess Jan doesn't want to introduce another way for a guest to cause Xen to consume large amounts of memory. Paul > Thanks > Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
