>>> On 20.03.18 at 10:32, <[email protected]> wrote: >> From: Jan Beulich [mailto:[email protected]] >> Sent: 20 March 2018 08:12 >> >> >>> On 19.03.18 at 17:57, <[email protected]> wrote: >> > What I meant was that safety (against underflow) is predicated on >> > iommu_lookup_page() failing if the mapping was not established through >> an >> > iommu op hypercall. So, the only things that should be valid in the iommu >> > (and hence that iommu_lookup_page() would succeed for) at the point >> where the >> > guest starts to boot must all fall within reserved regions, so thay they >> > are >> > ruled out by the earlier check. >> >> Ah, I see. What I don't see is how you want to arrange for that. >> The tool stack wouldn't know ahead of time whether the guest >> wants to use the PV IOMMU interfaces, would it? IOW rather than >> guaranteeing said state at start of guest, shouldn't you blow away >> all non-special mappings the first time a PV IOMMU request is made? >> > > I suspect we want both. Kevin suggested a 'big switch' when the domain > boots, in which I could blow away all non-reserved mappings. But, for > performance sake, I think it would also be worth a Xen command line option to > avoid populating the IOMMU mappings for dom0 in the first place (so when it > pulls the 'big switch' it's a no-op). Non-aware dom0s will, of course, > probably > fail to boot but whoever is setting the command line for Xen should know what > their dom0 is capable of. As for other domains, it may be worth adding a > similar domain create option to the toolstack but that could be done at a > later date.
Oh, yes, options to avoid the entire teardown are certainly going to be a good thing to have. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
