[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.