From: Julien Grall <julien@xen.org>
To: Wei Chen <Wei.Chen@arm.com>, Stefano Stabellini <sstabellini@kernel.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Bertrand Marquis <Bertrand.Marquis@arm.com>,
Penny Zheng <Penny.Zheng@arm.com>,
Henry Wang <Henry.Wang@arm.com>, nd <nd@arm.com>
Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
Date: Tue, 1 Mar 2022 13:17:16 +0000 [thread overview]
Message-ID: <7260f050-9022-4adf-618b-a8b271aca8c3@xen.org> (raw)
In-Reply-To: <PAXPR08MB74200F4B0B4EFFD5BE1A6E699E029@PAXPR08MB7420.eurprd08.prod.outlook.com>
On 01/03/2022 06:29, Wei Chen wrote:
> Hi Julien,
Hi,
>> -----Original Message-----
>> From: Julien Grall <julien@xen.org>
>> Sent: 2022年2月26日 4:12
>> To: Wei Chen <Wei.Chen@arm.com>; Stefano Stabellini
>> <sstabellini@kernel.org>
>> Cc: xen-devel@lists.xenproject.org; Bertrand Marquis
>> <Bertrand.Marquis@arm.com>; Penny Zheng <Penny.Zheng@arm.com>; Henry Wang
>> <Henry.Wang@arm.com>; nd <nd@arm.com>
>> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
>>
>> Hi Wei,
>>
>> On 25/02/2022 10:48, Wei Chen wrote:
>>>>> Armv8-R64 can support max to 256 MPU regions. But that's just
>>>> theoretical.
>>>>> So we don't want to define `pr_t mpu_regions[256]`, this is a
>> memory
>>>> waste
>>>>> in most of time. So we decided to let the user specify through a
>>>> Kconfig
>>>>> option. `CONFIG_ARM_MPU_EL1_PROTECTION_REGIONS` default value can
>> be
>>>> `32`,
>>>>> it's a typical implementation on Armv8-R64. Users will recompile
>> Xen
>>>> when
>>>>> their platform changes. So when the MPU changes, respecifying the
>>>> MPU
>>>>> protection regions number will not cause additional problems.
>>>>
>>>> I wonder if we could probe the number of MPU regions at runtime and
>>>> dynamically allocate the memory needed to store them in arch_vcpu.
>>>>
>>>
>>> We have considered to used a pr_t mpu_regions[0] in arch_vcpu. But it
>> seems
>>> we will encounter some static allocated arch_vcpu problems and sizeof
>> issue.
>>
>> Does it need to be embedded in arch_vcpu? If not, then we could allocate
>> memory outside and add a pointer in arch_vcpu.
>>
>
> We had thought to use a pointer in arch_vcpu instead of embedding mpu_regions
> into arch_vcpu. But we noticed that arch_vcpu has a __cacheline_aligned
> attribute, this may be because of arch_vcpu will be used very frequently
> in some critical path. So if we use the pointer for mpu_regions, may cause
> some cache miss in these critical path, for example, in context_swtich.
From my understanding, the idea behind ``cacheline_aligned`` is to
avoid the struct vcpu to be shared with other datastructure. Otherwise
you may end up to have two pCPUs to frequently write the same cacheline
which is not ideal.
arch_vcpu should embbed anything that will be accessed often (e.g.
entry/exit) to certain point. For instance, not everything related to
the vGIC are embbed in the vCPU/Domain structure.
I am a bit split regarding the mpu_regions. If they are mainly used in
the context_switch() then I would argue this is a premature optimization
because the scheduling decision is probably going to take a lot more
time than the context switch itself.
Note that for the P2M we already have that indirection because it is
embbed in the struct domain.
This raises one question, why is the MPUs regions will be per-vCPU
rather per domain?
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2022-03-01 13:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 6:01 Proposal for Porting Xen to Armv8-R64 - DraftA Wei Chen
2022-02-24 11:52 ` Ayan Kumar Halder
2022-02-25 6:33 ` Wei Chen
2022-02-25 0:55 ` Stefano Stabellini
2022-02-25 10:48 ` Wei Chen
2022-02-25 20:12 ` Julien Grall
2022-03-01 6:29 ` Wei Chen
2022-03-01 13:17 ` Julien Grall [this message]
2022-03-02 6:43 ` Wei Chen
2022-03-02 10:24 ` Julien Grall
2022-03-03 1:35 ` Wei Chen
2022-03-03 9:15 ` Julien Grall
2022-03-03 10:43 ` Wei Chen
2022-02-25 23:54 ` Stefano Stabellini
2022-03-01 12:55 ` Wei Chen
2022-03-01 23:38 ` Stefano Stabellini
2022-03-02 7:13 ` Wei Chen
2022-03-02 22:55 ` Stefano Stabellini
2022-03-03 1:05 ` Wei Chen
2022-03-03 2:03 ` Stefano Stabellini
2022-03-03 2:12 ` Wei Chen
2022-03-03 2:15 ` Stefano Stabellini
2022-02-25 20:55 ` Julien Grall
2022-03-01 7:51 ` Wei Chen
2022-03-02 7:21 ` Penny Zheng
2022-03-02 12:06 ` Julien Grall
2022-03-02 12:00 ` Julien Grall
2022-03-03 2:06 ` Wei Chen
2022-03-03 19:51 ` Julien Grall
2022-03-04 5:38 ` Wei Chen
2022-03-07 2:12 ` Wei Chen
2022-03-07 22:58 ` Stefano Stabellini
2022-03-08 7:28 ` Wei Chen
2022-03-08 19:49 ` Stefano Stabellini
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=7260f050-9022-4adf-618b-a8b271aca8c3@xen.org \
--to=julien@xen.org \
--cc=Bertrand.Marquis@arm.com \
--cc=Henry.Wang@arm.com \
--cc=Penny.Zheng@arm.com \
--cc=Wei.Chen@arm.com \
--cc=nd@arm.com \
--cc=sstabellini@kernel.org \
--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 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.