From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: vijay.kilari@gmail.com, stefano.stabellini@eu.citrix.com,
Prasun.Kapoor@caviumnetworks.com,
vijaya.kumar@caviumnetworks.com, tim@xen.org,
xen-devel@lists.xen.org, stefano.stabellini@citrix.com
Subject: Re: [PATCH v8a 5/6] xen/arm: split vgic driver into generic and vgic-v2 driver
Date: Thu, 03 Jul 2014 15:21:22 +0100 [thread overview]
Message-ID: <53B566E2.4030403@linaro.org> (raw)
In-Reply-To: <1404396160.19893.30.camel@kazak.uk.xensource.com>
On 07/03/2014 03:02 PM, Ian Campbell wrote:
> On Thu, 2014-07-03 at 14:25 +0100, Julien Grall wrote:
>> On 07/03/2014 02:02 PM, Ian Campbell wrote:
>>> On Thu, 2014-07-03 at 13:57 +0100, Julien Grall wrote:
>>>
>>>>> +struct vgic_ops {
>>>>> + /* Initialize vGIC */
>>>>> + int (*vcpu_init)(struct vcpu *v);
>>>>> + /* Domain specific initialization of vGIC */
>>>>> + int (*domain_init)(struct domain *d);
>>>>> + /* SGI handler of vGIC */
>>>>> + int (*send_sgi)(struct vcpu *v, register_t sgir);
>>>>
>>>> By reviewing the VGIC-v3 support, I still don't think this is the right
>>>> callback to add. You bypass the VGIC common emulation with your
>>>> vgic_emulate...
>>>>
>>>> I would introduce a callback to emulate_sysreg rather than this send_sgi.
>>>
>>> Why? The vgic will either be v2 or v3, so either MMIO or sysreg, once
>>> the thing has been decoded then you want to send an SGI I think, hence
>>> the callback. Passing a register_t does seem odd though, I'd have
>>> thought it would take an SGI number and any other flags which would then
>>> be interpreted for either v2 or v3 as appropriate.
>>
>> The decoding depends on the vgic emulation. For now this function is
>> badly implement in vgic-v3.c.
>>
>> What I was trying to say is send_sgi can be handled internally. If you
>> are looking to the calls of this function, it's only happen within the
>> file vgic-v2.c (or vgic-v3.c)
>>
>> But, the sysreg emulation is called outside the vgic code. So we should
>> add a callaback for this.
>
> So the common code would have
> case HSR_SYSREG_ICC_SGI0R:
> gic->handle_sysreg(esr, val)
> instead of
> case HSR_SYSREG_ICC_SGI0R:
> gic->handle_sysreg(val);
> ?
The is not the actual case,
Actually, the common code is:
case HSR_SYSREG_ICC_SGI0R:
vgic_emulate(regs, hsr)
where vgic_emulate is implemented in vgic-v3.c rather than in vgic.c.
The function will decode the register and then call vgic_send_sgi.
But, as the function send_sgi is only used internaly there is no reason
to create a callback.
What I ask is to have a new callback emulate_sysreg. The common code
(i.e traps.c) will have:
case HSR_SYSREG_ICC_SGI0R:
vgic_emulate(regs, hsr).
The function vgic_emulate will be implemented in vgic.c:
vgic_emulate(...)
{
vgic->emulate_sysreg(regs, hsr);
}
The vgic-v3.c will implement the callback correctly.
> That might be nicer, but TBH given that there is only one trappable gic
> sysreg right now I don't think it is worth getting too worried about. We
> can always rework this interface when gic v4 or v5 needs something more.
I don't see why we should break the vgic common implementation as it
does on the next series:
http://www.gossamer-threads.com/lists/xen/devel/337708.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-07-03 14:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 8:34 [PATCH v8a 0/6] GIC and VGIC code refactoring vijay.kilari
2014-07-03 8:34 ` [PATCH v8a 1/6] xen/arm: move and rename is_vcpu_running function to sched.h vijay.kilari
2014-07-03 9:12 ` Jan Beulich
2014-07-03 9:23 ` Ian Campbell
2014-07-03 12:49 ` Julien Grall
2014-07-03 13:24 ` Jan Beulich
2014-07-03 8:34 ` [PATCH v8a 2/6] xen/arm: move pending_irq structure to vgic header file vijay.kilari
2014-07-03 8:34 ` [PATCH v8a 3/6] xen/arm: calculate vgic irq rank based on register size vijay.kilari
2014-07-03 8:34 ` [PATCH v8a 4/6] xen/arm: Remove REG macro in vgic driver vijay.kilari
2014-07-03 8:34 ` [PATCH v8a 5/6] xen/arm: split vgic driver into generic and vgic-v2 driver vijay.kilari
2014-07-03 12:57 ` Julien Grall
2014-07-03 13:02 ` Ian Campbell
2014-07-03 13:25 ` Julien Grall
2014-07-03 14:02 ` Ian Campbell
2014-07-03 14:21 ` Julien Grall [this message]
2014-07-03 15:18 ` Ian Campbell
2014-07-04 7:01 ` Vijay Kilari
2014-07-04 10:20 ` Julien Grall
2014-07-03 8:34 ` [PATCH v8a 6/6] xen/arm: Restrict saving of gic register for idle domain vijay.kilari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B566E2.4030403@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=vijay.kilari@gmail.com \
--cc=vijaya.kumar@caviumnetworks.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.