On 19/07/2019 14:31, Jan Beulich wrote: > 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 <paul.durr...@citrix.com> >> 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.
Oh - even better. I'd not spotted that. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
