[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] IOMMU/MMU: Adjust top level functions for VT-d Device-TLB flush error.
>>> On 18.03.16 at 10:09, <quan.xu@xxxxxxxxx> wrote: > On March 18, 2016 4:20pm, <JBeulich@xxxxxxxx> wrote: >> As you can infer form the reply I sent yesterday, you first need to settle >> on an >> abstract model: What do failures mean? If, in the flush case, a timeout is >> going >> to kill the domain anyway, then error handling can be lighter weight than if >> you >> mean to try to keep the domain running. Of course in this context you also >> should not forget that iommu_map_page() could already return errors prior to >> your changes (most notably -ENOMEM, but at least the AMD side also produces >> others, with -EFAULT generally being accompanied by domain_crash()). As >> mentioned elsewhere - it seems extremely bogus that these errors weren't >> check for from the beginning. >> > Jan, I am not familiar/confident enough to this single point, could you tell > me more how to fix it? Not sure what exactly you're asking for: As said, we first need to settle on an abstract model. Do we want IOMMU mapping failures to be fatal to the domain (perhaps with the exception of the hardware one)? I think we do, and for the hardware domain we'd do things on a best effort basis (always erring on the side of unmapping). Which would probably mean crashing the domain could be centralized in iommu_{,un}map_page(). How much roll back would then still be needed in callers of these functions for the hardware domain's sake would need to be seen. So before you start coing, give others (namely but not limited to VT-d, AMD IOMMU, other x86, and x86/mm maintainers) a chance to voice differing opinions. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |