From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Alistair Francis" <alistair.francis@wdc.com>,
"Bob Eshleman" <bobbyeshleman@gmail.com>,
"Connor Davis" <connojdavis@gmail.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1] xen/riscv: Increase XEN_VIRT_SIZE
Date: Fri, 4 Apr 2025 10:43:02 +0200 [thread overview]
Message-ID: <d954c167-8243-43ab-9bfb-2e47c8ea171a@gmail.com> (raw)
In-Reply-To: <14ac3e72-d21d-4b45-a434-d123152c0113@suse.com>
[-- Attachment #1: Type: text/plain, Size: 3487 bytes --]
On 4/4/25 9:52 AM, Jan Beulich wrote:
> On 04.04.2025 09:31, Oleksii Kurochko wrote:
>> On 4/4/25 8:56 AM, Jan Beulich wrote:
>>> On 03.04.2025 18:20, Oleksii Kurochko wrote:
>>>> On 4/1/25 6:04 PM, Jan Beulich wrote:
>>>>> On 01.04.2025 17:58, Oleksii Kurochko wrote:
>>>>>> On 3/31/25 6:14 PM, Jan Beulich wrote:
>>>>>>> On 31.03.2025 17:20, Oleksii Kurochko wrote:
>>>>>>>> + _AC(XEN_VIRT_START, UL) >> vpn1_shift;
>>>>>>>> + const unsigned long xen_virt_end_vpn =
>>>>>>>> + xen_virt_starn_vpn + ((XEN_VIRT_SIZE >> vpn1_shift) - 1);
>>>>>>>> +
>>>>>>>> if ((va >= DIRECTMAP_VIRT_START) &&
>>>>>>>> (va <= DIRECTMAP_VIRT_END))
>>>>>>>> return directmapoff_to_maddr(va - directmap_virt_start);
>>>>>>>>
>>>>>>>> - BUILD_BUG_ON(XEN_VIRT_SIZE != MB(2));
>>>>>>>> - ASSERT((va >> (PAGETABLE_ORDER + PAGE_SHIFT)) ==
>>>>>>>> - (_AC(XEN_VIRT_START, UL) >> (PAGETABLE_ORDER + PAGE_SHIFT)));
>>>>>>>> + BUILD_BUG_ON(XEN_VIRT_SIZE != MB(8));
>>>>>>> Is it necessary to be != ? Won't > suffice?
>>>>>> It could be just > MB(2). Or perphaps >=.
>>>>>> = would make the build fail, wouldn't it?
>>>> I just realized that BUILD_BUG_ON() condition is compared to zero so actually everything what
>>>> will make the condition true will cause a build fail as inside it used !(condition).
>>> ???
>> |BUILD_BUG_ON()| forces a compilation error if the given condition is true. Therefore, if the condition
>> |XEN_VIRT_SIZE != MB(2)| is changed to|XEN_VIRT_SIZE > MB(2)|, the condition will always evaluate to true
>> (assuming|XEN_VIRT_SIZE| is greater than 2 MB), which will result in a compilation error.
> Well, it was you who used MB(2) in a reply, when previously talk was of MB(8),
> and that to grow to MB(16). The BUILD_BUG_ON() is - aiui - about you having set
> aside enough page table space. Quite possibly the need for this BUILD_BUG_ON()
> then disappears altogether when XEN_VIRT_SIZE is properly taken into account
> for the number-of-page-tables calculation. In no event do I see why the MB(2)
> boundary would be relevant for anything going forward.
Also, doesn’t|BUILD_BUG_ON()| affect how the|ASSERT()| that follows it is written?
The changes, at the moment, look like:
+ const unsigned int vpn1_shift = PAGETABLE_ORDER + PAGE_SHIFT;
+ const unsigned long va_vpn = va >> vpn1_shift;
+ const unsigned long xen_virt_start_vpn =
+ _AC(XEN_VIRT_START, UL) >> vpn1_shift;
+ const unsigned long xen_virt_end_vpn =
+ xen_virt_start_vpn + ((XEN_VIRT_SIZE >> vpn1_shift) - 1);
+
if ((va >= DIRECTMAP_VIRT_START) &&
(va <= DIRECTMAP_VIRT_END))
return directmapoff_to_maddr(va - directmap_virt_start);
- BUILD_BUG_ON(XEN_VIRT_SIZE != MB(2));
- ASSERT((va >> (PAGETABLE_ORDER + PAGE_SHIFT)) ==
- (_AC(XEN_VIRT_START, UL) >> (PAGETABLE_ORDER + PAGE_SHIFT)));
+ BUILD_BUG_ON(XEN_VIRT_SIZE != MB(16));
+ ASSERT((va_vpn >= xen_virt_start_vpn) && (va_vpn <= xen_virt_end_vpn));
If|XEN_VIRT_SIZE| is greater than|GB(1)|, then|xen_virt_end_vpn| may be calculated
incorrectly.
For example, if|XEN_VIRT_START| is|0xFFFFFFFF80000000| and|XEN_VIRT_SIZE| is|0x40200000|,
then|(XEN_VIRT_SIZE >> vpn1_shift)| equals 513, whereas|va_vpn| is always in the range [0, 511],
but xen_virt_end_vpn will be greater then 511.
So shouldn't it be checked before ASSERT() that XEN_VIRT_SIZE is <= GB(1):
BUILD_BUG_ON(XEN_VIRT_SIZE <= GB(1))?
~ Oleksii
[-- Attachment #2: Type: text/html, Size: 5497 bytes --]
next prev parent reply other threads:[~2025-04-04 8:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-31 15:20 [PATCH v1] xen/riscv: Increase XEN_VIRT_SIZE Oleksii Kurochko
2025-03-31 16:14 ` Jan Beulich
2025-03-31 16:17 ` Julien Grall
2025-04-01 6:24 ` Jan Beulich
2025-04-01 11:59 ` Julien Grall
2025-04-01 15:46 ` Oleksii Kurochko
2025-04-01 15:58 ` Oleksii Kurochko
2025-04-01 16:04 ` Jan Beulich
2025-04-03 16:20 ` Oleksii Kurochko
2025-04-04 6:56 ` Jan Beulich
2025-04-04 7:31 ` Oleksii Kurochko
2025-04-04 7:52 ` Jan Beulich
2025-04-04 8:43 ` Oleksii Kurochko [this message]
2025-04-04 10:00 ` Jan Beulich
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=d954c167-8243-43ab-9bfb-2e47c8ea171a@gmail.com \
--to=oleksii.kurochko@gmail.com \
--cc=alistair.francis@wdc.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bobbyeshleman@gmail.com \
--cc=connojdavis@gmail.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.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.