All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Fedin <p.fedin@samsung.com>
To: 'Peter Maydell' <peter.maydell@linaro.org>
Cc: kvmarm@lists.cs.columbia.edu, 'kvm-devel' <kvm@vger.kernel.org>,
	'Marc Zyngier' <marc.zyngier@arm.com>,
	'Andre Przywara' <andre.przywara@arm.com>
Subject: RE: [PATCH v2 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace
Date: Fri, 04 Sep 2015 10:06:47 +0300	[thread overview]
Message-ID: <012201d0e6e0$43de9db0$cb9bd910$@samsung.com> (raw)
In-Reply-To: <CAFEAcA8PDSnTX54mQAoVsuwWzv3CWo0B3-7YQP8=Nqi_Epoj6A@mail.gmail.com>

 Hello!

> > +  KVM_DEV_ARM_VGIC_GRP_REDIST_REGS
> > +  Attributes:
> > +    The attr field of kvm_device_attr encodes two values:
> > +    bits:     |  63  | 62  ..  40 | 39 ..  32  |  31   ....    0 |
> > +    values:   | size |  reserved  |   cpu id   |      offset     |
> 
> We should avoid imposing an accidental limit on the maximum
> number of CPUs in the userspace API. GICv3 doesn't have a
> limit at 256 CPUs

 Ops, my fault, forgot. :(
 However, it seems to be very simple. "cpu id" is actually an index, not a real affinity ID (see http://lxr.free-electrons.com/source/include/linux/kvm_host.h#L427). Would it be OK just to enlarge KVM_DEV_ARM_VGIC_CPUID_MASK?

    bits:     |  63  | 62 ..  32 |  31   ....    0 |
    values:   | size |  cpu id   |      offset     |

 I think 31 bits is more than enough for CPU index.
 And, since id is actually an index, may be we should fix up docs?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



  reply	other threads:[~2015-09-04  7:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02  8:09 [PATCH v2 0/5] KVM: arm64: Implement API for vGICv3 live migration Pavel Fedin
2015-09-02  8:09 ` [PATCH v2 1/5] KVM: arm/arm64: Refactor vGIC attributes handling code Pavel Fedin
2015-09-04 13:03   ` Andre Przywara
2015-09-04 15:11     ` Pavel Fedin
2015-09-04 15:16       ` Andre Przywara
2015-09-02  8:09 ` [PATCH v2 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace Pavel Fedin
2015-09-03 15:20   ` Peter Maydell
2015-09-04  7:06     ` Pavel Fedin [this message]
2015-09-02  8:09 ` [PATCH v2 3/5] KVM: arm64: Refactor system register handlers Pavel Fedin
2015-09-02  8:09 ` [PATCH v2 4/5] KVM: arm64: Introduce find_reg_by_id() Pavel Fedin
2015-09-02  8:09 ` [PATCH v2 5/5] Implement vGICv3 CPU interface access Pavel Fedin

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='012201d0e6e0$43de9db0$cb9bd910$@samsung.com' \
    --to=p.fedin@samsung.com \
    --cc=andre.przywara@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    --cc=peter.maydell@linaro.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.