From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 15/19] arm/arm64: KVM: add opaque private pointer to MMIO accessors
Date: Tue, 04 Nov 2014 20:17:07 +0000 [thread overview]
Message-ID: <54593443.4070904@arm.com> (raw)
In-Reply-To: <20141104191849.GC16138@cbox>
On 04/11/14 19:18, Christoffer Dall wrote:
> On Tue, Nov 04, 2014 at 06:05:17PM +0000, Marc Zyngier wrote:
>> On 04/11/14 17:24, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 04/11/14 15:44, Christoffer Dall wrote:
>>>> On Fri, Oct 31, 2014 at 05:26:50PM +0000, Andre Przywara wrote:
>>>>> For a GICv2 there is always only one (v)CPU involved: the one that
>>>>> does the access. On a GICv3 the access to a CPU redistributor is
>>>>> memory-mapped, but not banked, so the (v)CPU affected is determined by
>>>>> looking at the MMIO address region being accessed.
>>>>> To allow passing the affected CPU into the accessors, extend them to
>>>>> take an opaque private pointer parameter.
>>>>> For the current GICv2 emulation we ignore it and simply pass NULL
>>>>> on the call.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>
>>>> Why does it have to be an opaque private pointer? Would it not always
>>>> be a struct vcpu * or a vcpu_id then?
>>>
>>> IIRC Marc suggested this once be more future proof. Also a pointer makes
>>> it easier to pass NULL in the GICv2 parts of the code, which makes it
>>> more obvious that this value is not used in this case.
>>>
>>> Marc, did I miss some more rationale?
>>> Does that still hold?
>>
>> The main idea was to have a general purpose pointer that you can
>> associate with the decoded region. Some form of private context, just
>> like we have for a lot of other kernel structures.
>>
>> Now, I think having that as a explicit pointer looks truly awful. Can't
>> that be folded into struct kvm_exit_mmio that is already passed around?
>> It would make some sense that the private context is associated with the
>> actual access... I haven't seen how that interacts with the GICv3 code
>> though.
>>
> Well, the idea with a (void *private) is to have something, which is
> *generic* be reusable and extendable, no argument there.
>
> So my question is, are we implementing some generic feature, where
> having that extendability makes things better and clearer, or are we
> just wrapping an int in a (void *) so we don't have to add another
> parameter if sometime in the unknown future we need another additional
> piece of information.
>
> There are plenty of examples where you just pass NULL to a typed pointer
> or 0 to an int parameter as well.
>
> I'm not trying to fight the idea of a private pointer, I just want to
> make sure we do what we can to keep this code somewhat sane, so if we
> have a set of functions where we in 75% of the cases pass a vcpu * and
> in the other cases don't, then I really think we want a vcpu *
> parameter.
For the time being, I don't see any other use than a vcpu pointer for
the GICv3 case. Now, none of the MMIO decoding framework is GICv3
specific, and it feels a bit weird to hardcode the idea of a vcpu
pointer being passed around for code that doesn't really care about it
(GICv2).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2014-11-04 20:17 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 17:26 [PATCH v3 00/19] KVM GICv3 emulation Andre Przywara
2014-10-31 17:26 ` [PATCH v3 01/19] arm/arm64: KVM: rework MPIDR assignment and add accessors Andre Przywara
2014-11-03 13:13 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 02/19] arm/arm64: KVM: pass down user space provided GIC type into vGIC code Andre Przywara
2014-11-03 13:14 ` Christoffer Dall
2014-11-03 13:25 ` Andre Przywara
2014-11-03 16:51 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 03/19] arm/arm64: KVM: refactor vgic_handle_mmio() function Andre Przywara
2014-11-03 13:23 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 04/19] arm/arm64: KVM: wrap 64 bit MMIO accesses with two 32 bit ones Andre Przywara
2014-11-03 13:25 ` Christoffer Dall
2014-11-04 12:18 ` Andre Przywara
2014-11-04 13:24 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 05/19] arm/arm64: KVM: introduce per-VM ops Andre Przywara
2014-11-03 13:59 ` Christoffer Dall
2014-11-04 15:58 ` Andre Przywara
2014-11-04 19:03 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 06/19] arm/arm64: KVM: move [sg]et_lr into " Andre Przywara
2014-11-03 14:15 ` Christoffer Dall
2014-11-04 16:30 ` Andre Przywara
2014-11-04 19:12 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 07/19] arm/arm64: KVM: move kvm_register_device_ops() into vGIC probing Andre Przywara
2014-11-03 20:05 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 08/19] arm/arm64: KVM: dont rely on a valid GICH base address Andre Przywara
2014-11-03 20:05 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 09/19] arm/arm64: KVM: make the maximum number of vCPUs a per-VM value Andre Przywara
2014-11-03 20:06 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 10/19] arm/arm64: KVM: make the value of ICC_SRE_EL1 a per-VM variable Andre Przywara
2014-11-03 20:04 ` Christoffer Dall
2014-11-03 20:17 ` Marc Zyngier
2014-11-07 19:18 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 11/19] arm/arm64: KVM: refactor MMIO accessors Andre Przywara
2014-11-04 11:55 ` Christoffer Dall
2014-11-04 12:25 ` Andre Przywara
2014-10-31 17:26 ` [PATCH v3 12/19] arm/arm64: KVM: refactor/wrap vgic_set/get_attr() Andre Przywara
2014-11-04 19:30 ` Christoffer Dall
2014-11-05 10:27 ` Andre Przywara
2014-11-05 10:37 ` Andre Przywara
2014-11-05 12:57 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 13/19] arm/arm64: KVM: add vgic.h header file Andre Przywara
2014-11-04 19:30 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 14/19] arm/arm64: KVM: split GICv2 specific emulation code from vgic.c Andre Przywara
2014-11-04 19:30 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 15/19] arm/arm64: KVM: add opaque private pointer to MMIO accessors Andre Przywara
2014-11-04 15:44 ` Christoffer Dall
2014-11-04 17:24 ` Andre Przywara
2014-11-04 18:05 ` Marc Zyngier
2014-11-04 19:18 ` Christoffer Dall
2014-11-04 20:17 ` Marc Zyngier [this message]
2014-11-05 9:49 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 16/19] arm/arm64: KVM: add virtual GICv3 distributor emulation Andre Przywara
2014-11-07 14:30 ` Christoffer Dall
2014-11-10 17:30 ` [PATCH v3 16/19] arm/arm64: KVM: add virtual GICv3 distributor emulation / PART 1 Andre Przywara
2014-11-11 13:48 ` Christoffer Dall
2014-11-12 12:39 ` [PATCH v3 16/19] arm/arm64: KVM: add virtual GICv3 distributor emulation / PART 2 Andre Przywara
2014-11-12 19:51 ` Christoffer Dall
2014-11-13 11:18 ` Christoffer Dall
2014-11-13 11:45 ` Marc Zyngier
2014-11-13 12:01 ` Andre Przywara
2014-10-31 17:26 ` [PATCH v3 17/19] arm64: KVM: add SGI system register trapping Andre Przywara
2014-11-07 15:07 ` Christoffer Dall
2014-11-10 11:31 ` Andre Przywara
2014-11-10 12:45 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 18/19] arm/arm64: KVM: enable kernel side of GICv3 emulation Andre Przywara
2014-11-07 16:07 ` Christoffer Dall
2014-11-10 12:19 ` Andre Przywara
2014-11-10 13:24 ` Christoffer Dall
2014-10-31 17:26 ` [PATCH v3 19/19] arm/arm64: KVM: allow userland to request a virtual GICv3 Andre Przywara
2014-11-07 16:15 ` Christoffer Dall
2014-11-10 12:26 ` Andre Przywara
2014-11-10 13:25 ` Christoffer Dall
2014-11-03 12:59 ` [PATCH v3 00/19] KVM GICv3 emulation Christoffer Dall
2014-11-06 10:57 ` Christoffer Dall
2014-11-06 11:21 ` Christoffer Dall
2014-11-06 15:13 ` Andre Przywara
2014-11-06 18:09 ` Christoffer Dall
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=54593443.4070904@arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).