Re: [RFC PATCH v1 02/10] xen/arm: register mmio handler at runtime

[Julien Grall <julien.grall@linaro.org>]

On 03/27/2014 05:40 AM, Vijay Kilari wrote:
> On Wed, Mar 26, 2014 at 8:17 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> On 03/26/2014 12:29 PM, Vijay Kilari wrote:
>>> Hi Julien,
>>>
>>>
>>> On Fri, Mar 21, 2014 at 10:53 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>> On 03/21/2014 05:17 PM, Ian Campbell wrote:
>>>>> On Wed, 2014-03-19 at 19:47 +0530, vijay.kilari@gmail.com wrote:
>>>>>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>>>>>
>>>>>> mmio handlers are registers at compile time
>>>>>> for drivers like vuart and vgic.
>>>>>> Make mmio handler registered at runtime by
>>>>>> creating linked list of mmio handlers
>>>>>
>>>>> I'm not convinced of the need for this, certainly the vgic side can just
>>>>> demux into v2 or v3 as necessary.
>>>>
>>>> Demux the code just add an indirection. We could have a list of mmio
>>>> handler per domain and rely on it to call the right handler. A bit like x86.
>>>>
>>>  Until Andrii adds IOMMU  handling should keep this patch? and adopt
>>> to it later?
>>
>> I'm not sure to understand. IHMO, it doesn't sound right to upstream a
>> patch that we know it will be superseded in a couple of months. Why
>> can't you rework your patch to have it in good shape now?
>>
>  I assume that Andii's patch will be required to make mmio handlers
> per domain. If not let me know references in x86 that I can make it
> per domain specific mmio handlers.

I have already pointed out to the x86 code few mails before.

You can look at xen/arch/x86/intercept.c.

> 
> I was more inclined to go with this patch for now because it helps to
> go ahead with GICv3 and anything beyond this can be managed separately.
> Please let me know you opinion.

As I said on the email you answered, I'm not in favor to allow a this
patch that we know it will superseded in less than a couple of months.

It won't take you longer time than addressing the current requests on
this patch.

In last resort, you can use the demux solution from Ian. I don't agree
with it but it's better than upstreaming an half-feature for no valid
reason.

Regards,

-- 
Julien Grall