From: Marc Zyngier <marc.zyngier@arm.com>
To: Andrew Jones <drjones@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, will.deacon@arm.com,
shannon.zhao@linaro.org, Ashok Kumar <ashoks@broadcom.com>,
kvmarm@lists.cs.columbia.edu
Subject: Re: [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1
Date: Thu, 21 Apr 2016 10:25:24 +0100 [thread overview]
Message-ID: <57189C84.8080206@arm.com> (raw)
In-Reply-To: <20160421070447.nwuqlxvpq7fj6h7m@hawk.localdomain>
Hey Andrew,
On 21/04/16 08:04, Andrew Jones wrote:
> On Wed, Apr 20, 2016 at 06:33:54PM +0100, Marc Zyngier wrote:
>> On Wed, 20 Apr 2016 07:08:39 -0700
>> Ashok Kumar <ashoks@broadcom.com> wrote:
>>
>>> For guests with NUMA configuration, Node ID needs to
>>> be recorded in the respective affinity byte of MPIDR_EL1.
>>
>> As others have said before, the mapping between the NUMA hierarchy and
>> MPIDR_EL1 are completely arbitrary, and only the firmware description
>> can help the kernel in interpreting the affinity levels.
>>
>> If you want any patch like this one to be considered, I'd like to see
>> the corresponding userspace that:
>>
>> - programs the affinity into the vcpus,
>
> I have a start on this for QEMU that I can dust off and send as an RFC
> soon.
>
>> - pins the vcpus to specific physical CPUs,
>
> This wouldn't be part of the userspace directly interacting with KVM,
> but rather a higher level (even higher than libvirt, e.g.
> openstack/ovirt). I also don't think we should need to worry about
> which/how the phyiscal cpus get chosen. Let's assume that entity
> knows how to best map the guest's virtual topology to a physical one.
Surely the platform emulation userspace has to implement the pinning
itself, because I can't see high level tools being involved in the
creation of the vcpu threads themselves.
Also, I'd like to have a "simple" tool to test this without having to
deploy openstack (the day this becomes mandatory for kernel development,
I'll move my carrier to something more... agricultural).
So something in QEMU would be really good...
>
>> - exposes the corresponding firmware description (either DT or ACPI) to
>> the kernel.
>
> The QEMU patches I've started on already generate the DT (the cpu-map
> node). I started looking into how to do it for ACPI too, but there
> were some questions about whether or not the topology description
> tables added to the 6.1 spec were sufficient. I can send the DT part
> soon, and continue to look into the ACPI part later though.
That'd be great. Can you please sync with Ashok so that we have
something consistent between the two of you?
Thanks!
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1
Date: Thu, 21 Apr 2016 10:25:24 +0100 [thread overview]
Message-ID: <57189C84.8080206@arm.com> (raw)
In-Reply-To: <20160421070447.nwuqlxvpq7fj6h7m@hawk.localdomain>
Hey Andrew,
On 21/04/16 08:04, Andrew Jones wrote:
> On Wed, Apr 20, 2016 at 06:33:54PM +0100, Marc Zyngier wrote:
>> On Wed, 20 Apr 2016 07:08:39 -0700
>> Ashok Kumar <ashoks@broadcom.com> wrote:
>>
>>> For guests with NUMA configuration, Node ID needs to
>>> be recorded in the respective affinity byte of MPIDR_EL1.
>>
>> As others have said before, the mapping between the NUMA hierarchy and
>> MPIDR_EL1 are completely arbitrary, and only the firmware description
>> can help the kernel in interpreting the affinity levels.
>>
>> If you want any patch like this one to be considered, I'd like to see
>> the corresponding userspace that:
>>
>> - programs the affinity into the vcpus,
>
> I have a start on this for QEMU that I can dust off and send as an RFC
> soon.
>
>> - pins the vcpus to specific physical CPUs,
>
> This wouldn't be part of the userspace directly interacting with KVM,
> but rather a higher level (even higher than libvirt, e.g.
> openstack/ovirt). I also don't think we should need to worry about
> which/how the phyiscal cpus get chosen. Let's assume that entity
> knows how to best map the guest's virtual topology to a physical one.
Surely the platform emulation userspace has to implement the pinning
itself, because I can't see high level tools being involved in the
creation of the vcpu threads themselves.
Also, I'd like to have a "simple" tool to test this without having to
deploy openstack (the day this becomes mandatory for kernel development,
I'll move my carrier to something more... agricultural).
So something in QEMU would be really good...
>
>> - exposes the corresponding firmware description (either DT or ACPI) to
>> the kernel.
>
> The QEMU patches I've started on already generate the DT (the cpu-map
> node). I started looking into how to do it for ACPI too, but there
> were some questions about whether or not the topology description
> tables added to the 6.1 spec were sufficient. I can send the DT part
> soon, and continue to look into the ACPI part later though.
That'd be great. Can you please sync with Ashok so that we have
something consistent between the two of you?
Thanks!
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2016-04-21 9:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 14:08 [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1 Ashok Kumar
2016-04-20 14:08 ` Ashok Kumar
2016-04-20 14:38 ` Mark Rutland
2016-04-20 14:38 ` Mark Rutland
2016-04-20 14:39 ` Andrew Jones
2016-04-20 14:39 ` Andrew Jones
2016-04-20 17:33 ` Marc Zyngier
2016-04-20 17:33 ` Marc Zyngier
2016-04-21 7:04 ` Andrew Jones
2016-04-21 7:04 ` Andrew Jones
2016-04-21 9:25 ` Marc Zyngier [this message]
2016-04-21 9:25 ` Marc Zyngier
2016-04-21 9:56 ` Andrew Jones
2016-04-21 9:56 ` Andrew Jones
2016-04-21 11:46 ` Ashok Kumar
2016-04-21 11:46 ` Ashok Kumar
2016-04-21 11:46 ` Ashok Kumar
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=57189C84.8080206@arm.com \
--to=marc.zyngier@arm.com \
--cc=ashoks@broadcom.com \
--cc=drjones@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=shannon.zhao@linaro.org \
--cc=will.deacon@arm.com \
/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.