From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings Date: Tue, 02 Sep 2014 19:10:15 +0800 Message-ID: <5405A597.9040103@intel.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> <5405B4E1020000780002FCBC@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5405B4E1020000780002FCBC@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich 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 2014/9/2 18:15, Jan Beulich wrote: >>>> 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? I don't know how to handle this in the hypercall case. > >> 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); Do we still need this iommu_ops somewhere else? >> + if ( !nr_entries ) Do we still need this 'nr_entries' here? >> + 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 > >