Re: [Xen-devel] [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies

[Parth Dixit <parth.dixit@xxxxxxxxxx>]

On 5 February 2015 at 11:08, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi Parth,
>
> On 04/02/2015 14:02, parth.dixit@xxxxxxxxxx wrote:
>>
>> From: Parth Dixit <parth.dixit@xxxxxxxxxx>
>>
>> Some bugs are identified in edk2 and some of the functionality is not
>> yet merged. This patch contains workarounds for them
>
>
> While I understand some workaround (based on your cover letter), some of
> them is unclear to me and need explanation.
Sure, ask them, i'll reply to it.
>>
>> Signed-off-by: Parth Dixit <parth.dixit@xxxxxxxxxx>
>> ---
>
>
> [..]
>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 97061ce..e74555d 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int
>> n)
>>       }
>>   }
>>
>> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
>> +
>>   void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>>   {
>>       struct domain *d = v->domain;
>> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int
>> n)
>>
>>       while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>>           irq = i + (32 * n);
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> +        if( ( n!=0 ) && is_hardware_domain(d) ){
>> +            struct vgic_irq_rank *vr = vgic_get_rank(v, n);
>> +            uint32_t tr;
>> +            tr = vr->icfg[i >> 4] ;
>> +
>> +            if( ( tr & VGIC_ICFG_MASK(i) ) )
>> +                acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
>> +            else
>> +                acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
>
>
> What's the status of the dynamic IRQ configuration?
It would be on top of your patches but this is the place where i am
planning to trap it.
I have not rebased it on top of your patches, so that needs to be done.
>> +
>> +            route_irq_to_guest(d,irq,NULL);
>
>
> Hmmm, do you really plan to keep that here? What's your plan for this?
yes, but i am open to suggestions , if you think there is a better
place i'll move it there.
>> +        }
>> +#endif
>>           v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
>>           p = irq_to_pending(v_target, irq);
>>           set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
>> index 73da9d9..2d78ba0 100644
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list
>> args)
>>
>>   acpi_physical_address __init acpi_os_get_root_pointer(void)
>>   {
>> -       if (efi_enabled) {
>> +    if (efi_enabled) {
>
>
> Spurious change
will take care in next patchset
>>                 if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>>                         return efi.acpi20;
>>                 else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
>> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr,
>> u32 value, u32 width)
>>
>>         return AE_OK;
>>   }
>> -
>> +#ifdef CONFIG_X86
>>   #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
>> +#else
>> +#define is_xmalloc_memory(ptr) 1
>> +#endif
>
>
> Why? I though this was resolved?
i am not aware what was the resolution on it?
>>   void *__init acpi_os_alloc_memory(size_t sz)
>>   {
>>
>
> Regards,
>
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel