On 19.07.2019 14:41, Andrew Cooper wrote: > On 19/07/2019 13:25, Paul Durrant wrote: >> When commit 3f8f1228 "x86/mm: add HYPERVISOR_memory_op to acquire guest >> resources" introduced the concept of directly mapping some guest resources, >> it was envisaged that the memory for some resources associated with a guest >> may not actually be assigned to that guest, specifically the IOREQ server >> resource introduces in commit 6e387461 "x86/hvm/ioreq: add a new mappable >> resource type...". Such resources were dubbed "caller owned" and resulted >> in the owned resources" and acquiring them resulted in the >> XENMEM_rsrc_acq_caller_owned flag being passed back to the caller of the >> memory op. >> >> Unfortunately the implementation led to XSA-276, which was mitigated >> by commit f6b6ae78 "x86/hvm/ioreq: fix page referencing" and then a related >> memory accounting problem was worked around by commit e862e6ce >> "x86/hvm/ioreq: use ref-counted target-assigned shared pages". This latter >> commit removed the only instance of a "caller owned" resource, but the >> flag was left in header and checked in one place in the core code. >> This patch removes that now redundant check and removes the definition of >> XENMEM_rsrc_acq_caller_owned from the public header. Also, since this was >> the only flag defined for the XENMEM_acquire_resource memory op, it removes >> the 'flags' field of struct xen_mem_acquire_resource and replaces it with >> an equivalently sized 'pad' field. >> >> Signed-off-by: Paul Durrant <[email protected]> > > This is a modification to a public header, but in this specific case, I > think it is the correct thing to do.
This is in a large "#if defined(__XEN__) || defined(__XEN_TOOLS__)" section, and we consider public interface parts in such sections volatile anyway. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
