From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings Date: Tue, 02 Sep 2014 11:15:29 +0100 Message-ID: <5405B4E1020000780002FCBC@mail.emea.novell.com> References: <1409050980-21933-1-git-send-email-tiejun.chen@intel.com> <1409050980-21933-4-git-send-email-tiejun.chen@intel.com> <53FC774D.8000501@citrix.com> <53FC9BB1020000780002D986@mail.emea.novell.com> <53FD3669.3070705@intel.com> <53FD9C03020000780002DEFF@mail.emea.novell.com> <53FD86E9.4020205@intel.com> <53FE92C6.6050605@intel.com> <53FEED4F020000780002E76C@mail.emea.novell.com> <53FED5AF.7080803@intel.com> <53FED802.7080707@intel.com> <53FEF9F8020000780002E7E2@mail.emea.novell.com> <53FFED5D.7040406@intel.com> <54006196020000780002EFC6@mail.emea.novell.com> <54043FEA.6080100@intel.com> <540466A8020000780002F656@mail.emea.novell.com> <540594F2.4000406@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <540594F2.4000406@intel.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tiejun Chen Cc: kevin.tian@intel.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, Andrew Cooper , ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, yang.z.zhang@intel.com List-Id: xen-devel@lists.xenproject.org >>> On 02.09.14 at 11:59, wrote: > So could you take a look at the follows? I'm sorry, but this is a nightmare. Do you know what the term "callback" means? > Then when call the hypercall, > > + case XENMEM_reserved_device_memory_map: > + { > + struct xen_mem_reserved_device_memory *xmrdm = NULL; > + struct xen_mem_reserved_device_memory_map xmrdmm; > + XEN_GUEST_HANDLE(xen_mem_reserved_device_memory_t) buffer; > + XEN_GUEST_HANDLE_PARAM(xen_mem_reserved_device_memory_t) buffer_param; > + const struct iommu_ops *ops = iommu_get_ops(); > + unsigned int nr_entries = 0; > + unsigned int i = 0; > + > + xmrdm = ops->get_device_reserved_memory(&nr_entries); > + if ( !nr_entries ) > + return -ENOENT; > + if ( nr_entries < 0 ) > + return -EFAULT; > + > + if ( copy_from_guest(&xmrdmm, arg, 1) ) > + return -EFAULT; > + > + if ( xmrdmm.nr_entries < nr_entries ) > + { > + xmrdmm.nr_entries = nr_entries; > + if ( copy_to_guest(arg, &xmrdmm, 1) ) > + return -EFAULT; > + return -ENOBUFS; > + } > + > + buffer_param = guest_handle_cast(xmrdmm.buffer, > + xen_mem_reserved_device_memory_t); > + buffer = guest_handle_from_param(buffer_param, > + xen_mem_reserved_device_memory_t); > + if ( !guest_handle_okay(buffer, xmrdmm.nr_entries) ) > + return -EFAULT; > + > + for ( i = 0; i < nr_entries; i++ ) > + { > + if ( copy_to_guest_offset(buffer, i, xmrdm + i, 1) ) > + return -EFAULT; > + } The equivalent of this loop would move into the new (abstracted at the IOMMU level) VT-d function. Out of that loop you'd call the callback passed from here once per iteration; the called function would take care of storing the needed information and advancing a private counter. No memory allocation, and no VT-d specific knowledge required in generic code. Jan