xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: stefano.stabellini@eu.citrix.com
Subject: Re: [PATCH v6 4/6] xen/arm: vgic: Optimize the way to store the target vCPU in the rank
Date: Wed, 25 Nov 2015 11:37:42 +0000	[thread overview]
Message-ID: <1448451462.17688.73.camel@citrix.com> (raw)
In-Reply-To: <1447864963-21577-5-git-send-email-julien.grall@citrix.com>

On Wed, 2015-11-18 at 16:42 +0000, Julien Grall wrote:
> Xen is currently directly storing the value of GICD_ITARGETSR register
> (for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
> emulation of the registers access very simple but makes the code to get
> the target vCPU for a given vIRQ more complex.
> 
> While the target vCPU of an vIRQ is retrieved every time an vIRQ is
> injected to the guest, the access to the register occurs less often.
> 
> So the data structure should be optimized for the most common case
> rather than the inverse.
> 
> This patch introduces the usage of an array to store the target vCPU for
> every interrupt in the rank. This will make the code to get the target
> very quick. The emulation code will now have to generate the
> GICD_ITARGETSR
> and GICD_IROUTER register for read access and split it to store in a
> convenient way.
> 
> With the new way to store the target vCPU, the structure vgic_irq_rank
> is shrunk down from 320 bytes to 92 bytes. This is saving about 228
> bytes of memory allocated separately per vCPU.
> 
> Note that with these changes, any read to those register will list only
> the target vCPU used by Xen. As the spec is not clear whether this is a
> valid choice or not, OSes which have a different interpretation of the
> spec (i.e OSes which perform read-modify-write operations on these
> registers) may not boot anymore on Xen. Although, I think this is fair
> trade between memory usage in Xen (1KB less on a domain using 4 vCPUs
> with no SPIs) and a strict interpretation of the spec (though all the
> cases are not clearly defined).
> 
> Furthermore, the implementation of the callback get_target_vcpu is now
> exactly the same. Consolidate the implementation in the common vGIC code
> and drop the callback.
> 
> Finally take the opportunity to fix coding style and replace "irq" by
> "virq" to make clear that we are dealing with virtual IRQ in section we
> are modifying.
> 
> Signed-off-by: Julien Grall <julien.grall@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I have one clarifying question, which may or may not be worth a followup:

> + * Fetch an ITARGETSR register based on the offset from ITARGETSR0.

Is the offset here in terms of bytes or in terms of entire ITARGETSR<n>
registers (i.e. 4 bytes)?

Might be worth clarifying the comment?

Ian.

  reply	other threads:[~2015-11-25 11:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 16:42 [PATCH v6 0/6] xen/arm: vgic: Support 32-bit access for 64-bit registers Julien Grall
2015-11-18 16:42 ` [PATCH v6 1/6] xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7 read-only Julien Grall
2015-11-18 16:42 ` [PATCH v6 2/6] xen/arm: vgic-v2: Handle correctly byte write in ITARGETSR Julien Grall
2015-11-18 16:42 ` [PATCH v6 3/6] xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0 Julien Grall
2015-11-25 11:34   ` Ian Campbell
2015-11-18 16:42 ` [PATCH v6 4/6] xen/arm: vgic: Optimize the way to store the target vCPU in the rank Julien Grall
2015-11-25 11:37   ` Ian Campbell [this message]
2015-11-30 13:32     ` Julien Grall
2015-11-30 13:55       ` Ian Campbell
2015-11-30 14:02         ` Julien Grall
2015-11-18 16:42 ` [PATCH v6 5/6] xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC register Julien Grall
2015-11-18 16:42 ` [PATCH v6 6/6] xen/arm: vgic-v3: Support 32-bit access for 64-bit registers Julien Grall
2015-11-25 12:29 ` [PATCH v6 0/6] xen/arm: vgic: " Ian Campbell

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=1448451462.17688.73.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.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).