[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v14 4/9] iommu: don't domain_crash() inside iommu_map/unmap_page()
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: 05 October 2018 08:33 > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> > Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap > <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Wei Liu > <wei.liu2@xxxxxxxxxx>; Jun Nakajima <jun.nakajima@xxxxxxxxx>; Stefano > Stabellini <sstabellini@xxxxxxxxxx>; xen-devel <xen- > devel@xxxxxxxxxxxxxxxxxxxx>; Konrad Rzeszutek Wilk > <konrad.wilk@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx> > Subject: Re: [Xen-devel] [PATCH v14 4/9] iommu: don't domain_crash() > inside iommu_map/unmap_page() > > >>> On 04.10.18 at 18:36, <Paul.Durrant@xxxxxxxxxx> wrote: > > I still think an implicit domain_crash() doesn't really belong in > something > > that looks like a straightforward wrapper around a per-implementation > jump > > table. How about iommu_map/unmap_may_crash() instead to highlight the > > semantic? > > If anything then the other way around, i.e. iommu_unmap_no_crash(), > such that only callers who explicitly mean to deal with the crashing > themselves would use the otherwise insecure variant. > Ok. George, what is your preference? At this point my proposal is to drop this patch and replace it with one that removes the implicit crash from from everything except the unmap. I can then introduce a 'nocrash' variant of unmap if I need it... although I'm no longer convinced I can really do anything else if a PV-IOMMU unmap fails. Paul > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |