From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Zhao Subject: Re: [PATCH v2 32/41] arm : acpi dynamically map mmio regions Date: Fri, 31 Jul 2015 09:15:14 +0800 Message-ID: <55BACC22.4050905@linaro.org> References: <1431893048-5214-1-git-send-email-parth.dixit@linaro.org> <1431893048-5214-33-git-send-email-parth.dixit@linaro.org> <5575C7E9.6@citrix.com> <557E280A.10601@citrix.com> <55BA1665.7070006@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Parth Dixit Cc: keir@xen.org, Ian Campbell , andrew.cooper3@citrix.com, tim@xen.org, xen-devel , Julien Grall , Stefano Stabellini , Jan Beulich , Christoffer Dall List-Id: xen-devel@lists.xenproject.org On 2015/7/31 2:02, Parth Dixit wrote: > Hi Shannon, > instead of getting mmio information for individual > devices from dsdt, we will map all the non-ram regions described in > uefi. Yes, I don't want to use AML interpreter either. But how to get all the non-ram regions? > AML interpreter option was discussed earlier and it was decided > not to go with that approach. You can find more details in the linaro > xen wiki for the reasoning behind it. > > regards > parth > > On 30 July 2015 at 17:49, Shannon Zhao wrote: >> >> >> On 2015/7/5 21:30, Parth Dixit wrote: >>> +shannon >>> >>> On 15 June 2015 at 06:49, Julien Grall wrote: >>>> Hi Parth, >>>> >>>> On 14/06/2015 11:27, Parth Dixit wrote: >>>>> >>>>> On 8 June 2015 at 22:20, Julien Grall wrote: >>>>>> >>>>>> Hi Parth, >>>>>> >>>>>> On 17/05/2015 21:03, Parth Dixit wrote: >>>>>>> >>>>>>> >>>>>>> In ACPI mmio regions are described in DSDT which requires >>>>>>> AML interpreter. Defer the mapping of mmio until DSDT is parsed in >>>>>>> DOM0 and map mmio's dynamically at the time of request. >>>>>> >>>>>> >>>>>> >>>>>> I'm against a such solution. Even though it's DOM0 we should avoid to >>>>>> allow >>>>>> him to map anything (RAM,...) on data abort. >>>>> >>>>> I think we agreed to this solution >>>>> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02059.html >>>> >>>> >>>> Firstly, this kind of link should have been put in the changelog of the >>>> patch (after ---). It helps the reviewer to know what was decided (or not) >>>> on the previous discussion. It's more true with a series of more than 40 >>>> patches... >>>> >>>> Secondly, the thread you pointed as some discussion on it but no formal >>>> agreement about what to do. If there is no answer, it's better to do a >>>> resume and ask if anyone are agree. >>>> >>>> Finally, what you've implemented and what was suggested by Ian is different. >>>> You are allowing any region to be mapped in DOM0 via this way. Only MMIO >>>> should be allowed. >>>> >>>> Concerning the mapping attribute used. Based on Ard answer "The UEFI spec >>>> mandates that the memory map describes all memory in the system, so if dom0 >>>> accesses any ranges outside of that, it makes sense >>>> to just use device mappings for stage 2.". We should use by default Device >>>> Stage 2, it's safer. If it doesn't work later (because some PCI BAR may be >>>> memory, which if I wasn't able to prove), then we can think differently. >>>> >>>> For the mapping of the MMIO to DOM0, I believe we can map any non-RAM (and >>>> any non-RAM not used by Xen) regions to DOM0 at boot time (I think x86 does >>>> that). It would keep the ACPI code contained at boot time and no difference >>>> during runtime. >>>> >> >> But How do we get the MMIO information of the devices in DSDT table? If >> we want to parse DSDT table, we must introduce AML interpreter, IIUC. >> >> Julien, do you have any other ideas? >> >> Thanks, >> -- >> Shannon -- Shannon