Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.03.18 at 10:32, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 20 March 2018 08:12
>> 
>> >>> On 19.03.18 at 17:57, <Paul.Durrant@xxxxxxxxxx> 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel