From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Zhao Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 4 Date: Thu, 20 Aug 2015 20:29:54 +0800 Message-ID: <55D5C842.6000704@linaro.org> References: <55D472D4.9010007@huawei.com> <55D49AA1.3030702@citrix.com> <55D54483.5000103@huawei.com> <55D58DD9.9090500@citrix.com> <55D5B860.9070307@linaro.org> <55D5B9ED.7010207@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <55D5B9ED.7010207@citrix.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: =?windows-1252?Q?Roger_Pau_Monn=E9?= , Shannon Zhao , xen-devel , Christoffer Dall , Ian Campbell , Stefano Stabellini , Julien Grall , Stefano Stabellini , Jan Beulich , Parth Dixit , andrew@fubar.geek.nz, Boris Ostrovsky , David Vrabel Cc: Hangaohuai , "Huangpeng (Peter)" List-Id: xen-devel@lists.xenproject.org On 2015/8/20 19:28, Roger Pau Monn=E9 wrote: > El 20/08/15 a les 13.22, Shannon Zhao ha escrit: >> Hi Roger, >> >> On 2015/8/20 16:20, Roger Pau Monn=E9 wrote: >>> El 20/08/15 a les 5.07, Shannon Zhao ha escrit: >>>> On 2015/8/19 23:02, Roger Pau Monn=E9 wrote: >>>>> El 19/08/15 a les 14.13, Shannon Zhao ha escrit: >>>>>> XENMAPSPACE "XENMAPSPACE_dev_mmio". The usage of this hypercall >>>>>> parameters: >>>>>> - domid: DOMID_SELF. >>>>>> - space: XENMAPSPACE_dev_mmio. >>>>>> - gpfns: guest physical addresses where the mapping should appear. >>>>> >>>>> This is not complete, you have forgotten to add the idxs field, >>>> >>>> Sorry, I didn't use the idx for the mmio region mapping. What's the idx >>>> useful for here? >>> >>> I've already posted this in the previous version, and you agreed on the >>> interface and the usage of the fields, please see: >>> >>> http://marc.info/?l=3Dxen-devel&m=3D143986236212359 >>> >>> The idxs field is explicitly mentioned there with it's usage. >>> >> >> Yeah, I said I will add the description of hypercall parameters. >> It seems that we are talking about a different parameter. >> To map the mmio region, I reuse the struct xen_add_to_physmap and there > > You should also take into account xen_add_to_physmap_batch (or are you > planning to issue an hypercall for every single MMIO page that you want > to map?), but anyway the idx(s) field is there in both structs. > Yeah, current approach is to issue an hypercall for every single MMIO = page. But if we want to batch map MMIO pages, I think it needs the size = parameter and what's idxs useful for? As we map the MMIO pages 1:1, it = seems it's unnecessary to check "idxs[i] =3D=3D gpfns[i]", right? >> is idx not idxs. Everytime Dom0 maps one page and it's mapped 1:1(guest >> physical address is same with real physical hardware address), so it >> only needs to tell the hypervisor the gpfn. > > IMHO, I'm not sure why we should restrict this to 1:1 (although I admit > this is going to be the common case). Didn't we are that we are going to > allow non 1:1 mapping of MMIO regions? > > If you want you can check in the hypercall handler that idxs[i] =3D=3D > gpfns[i], and return -EOPNOTSUPP if they don't match, but I still don't > see why this should be restricted to 1:1 mappings. > For Dom0 which get the device MMIO information from the DT or ACPI DSDT = table. To ACPI, we don't (or can't)modify anything in DSDT table. So = actually the MMIO regions Dom0 gets are the real physical hardware MMIO = regions and the start address and size of them are same. -- = Shannon