Re: [Xen-devel] [PATCH v4 16/16] xen/arm: add SGI handling for GICv3

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

On Wed, Jun 11, 2014 at 6:08 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> On 06/11/2014 01:35 PM, Vijay Kilari wrote:
>> On Mon, Jun 2, 2014 at 9:47 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>>> Hi Vijay,
>>>
>>> On 05/26/2014 11:26 AM, vijay.kilari@xxxxxxxxx wrote:
>>>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>>>> index d80683d..99d0d46 100644
>>>> --- a/xen/arch/arm/vgic-v3.c
>>>> +++ b/xen/arch/arm/vgic-v3.c
>>>
>>> [..]
>>>
>>>> +int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>>>> +{
>>>
>>> You are by-passing without any reason the vgic structure. Why didn't you
>>> add a new callback there?
>>
>> Sorry, I could not get you. Can you please be more clear?
>
> Why didn't you add a callback in the vgic structure?
>
> The vgic structure is per-domain, so it's perfectly valid (even though
> it's not you use case) to run a GICv2 guest and a GICv3 guest at the
> same time.
>
   In GICv3 case the sending SGI by guest raises sysreg trap where
as in GICv2 it raises mmio write trap. So these traps lands in respective
vgic driver. ( mmio write trap => vgic-v2.c and sysreg => vgic-v3.c)
These vgic-v{2,3}.c driver calls generic vgic driver to inject SGI to VCPU.

If I understand correctly, you mean creating callback in vgic, which is
common function in vgic driver and from there it should call
respective vgic-v{2,3}.c driver.

> On the former, you don't want to let the guest send an SGI via this
> solution.
>
> Regards,
>
> --
> Julien Grall

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