From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Romain Caritey" <Romain.Caritey@microchip.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Michal Orzel" <michal.orzel@amd.com>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Roger Pau Monné" <roger.pau@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 07/11] xen: move domain_use_host_layout() to common code
Date: Wed, 1 Apr 2026 16:38:19 +0200 [thread overview]
Message-ID: <600b1b66-fd85-4b7f-8bdc-793667bccfec@gmail.com> (raw)
In-Reply-To: <cdacc6a8-cd49-4327-a98c-636545e8579b@suse.com>
On 4/1/26 7:58 AM, Jan Beulich wrote:
> On 31.03.2026 18:32, Oleksii Kurochko wrote:
>> On 3/31/26 5:53 PM, Jan Beulich wrote:
>>> On 31.03.2026 17:20, Oleksii Kurochko wrote:
>>>> On 3/30/26 5:13 PM, Jan Beulich wrote:
>>>>> On 23.03.2026 17:29, Oleksii Kurochko wrote:
>>>>>> domain_use_host_layout() is not really architecture-specific, so move it
>>>>>> from the Arm header to the common header xen/domain.h and provide a common
>>>>>> implementation in xen/common/domain.c. domain_use_host_layout() potentially
>>>>>> is needed for x86 [1].
>>>>> No matter that this may indeed be true, ...
>>>>>
>>>>>> Turn the macro into a function to avoid header dependency issues.
>>>>> ... this introduces unreachable code on x86, i.e. a Misra rule 2.1 violation.
>>>> Do we have some deviation tag for such cases when the code temporary
>>>> isn't used?
>>> I'm sorry, but it'll take me about as long as you to find out.
>> Sure, I will take a look. I just thought that maybe you have a solution
>> already just in your head.
> Well, I do: Don't make this an out-of-line function.
>
>> I wonder
>>> about "temporary" though: Do you have a clear understanding as to when
>>> that will change?
>> No, I don't. As Stefano mentioned they will need this function one day.
>> Another option we could use ifndef x86 or ifdef DOM0_LESS and then when
>> someone will really need it on x86, this ifdef will be dropped. I don't
>> know if it is better solution.
>>
>> It seems like the best one solution will still make a try to make
>> declare this function as macro.
> Or an inline function. There's nothing ...
>
>>>>>> @@ -2544,6 +2544,12 @@ void thaw_domains(void)
>>>>>>
>>>>>> #endif /* CONFIG_SYSTEM_SUSPEND */
>>>>>>
>>>>>> +bool domain_use_host_layout(struct domain *d)
>>>>>> +{
>>>>>> + return is_domain_direct_mapped(d) ||
>>>>>> + (paging_mode_translate(d) && is_hardware_domain(d));
>>>>>> +}
>>>>> The placement of paging_mode_translate() doesn't match ...
>>>>>
>>>>>> --- a/xen/include/xen/domain.h
>>>>>> +++ b/xen/include/xen/domain.h
>>>>>> @@ -62,6 +62,22 @@ void domid_free(domid_t domid);
>>>>>> #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
>>>>>> #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
>>>>>>
>>>>>> +/*
>>>>>> + * Is the auto-translated domain using the host memory layout?
>>>>>> + *
>>>>>> + * domain_use_host_layout() is always False for PV guests.
>>>>> ... the description of the function.
>>>> But why the placement should be different?
>>> If you focus on auto-translated, then imo paging_mode_translate()
>>> better would guard everything.
>> Then it make sense to do in the following way:
>> bool domain_use_host_layout(struct domain *d)
>> {
>> - return is_domain_direct_mapped(d) ||
>> - (paging_mode_translate(d) && is_hardware_domain(d));
>> + return paging_mode_translate(d) &&
>> + (is_domain_direct_mapped(d) || is_hardware_domain(d));
>> }
> ... in here which clearly speaks against doing so. And yes, this is what I
> was asking for (with the function parameter also suitably constified).
I expect that with an inline function in xen/domain.h compiler will want
have paging_mode_translate() be explicitly defined, so an inclusion of
xen/paging.h will be needed, but likely I am wrong that it will be
needed it the case of inline function.
~ Oleksii
next prev parent reply other threads:[~2026-04-01 14:38 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 16:29 [PATCH v2 00/11] RISCV: enable DOMAIN_BUILD_HELPERS Oleksii Kurochko
2026-03-23 16:29 ` [PATCH v2 01/11] xen/riscv: implement get_page_from_gfn() Oleksii Kurochko
2026-03-26 13:50 ` Jan Beulich
2026-03-30 13:40 ` Oleksii Kurochko
2026-03-30 14:04 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 02/11] xen: return proper type for guest access functions Oleksii Kurochko
2026-03-26 13:56 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 03/11] xen/riscv: implement copy_to_guest_phys() Oleksii Kurochko
2026-03-30 14:24 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 04/11] xen/dom0less: rename kernel_zimage_probe() to kernel_image_probe() Oleksii Kurochko
2026-03-23 16:29 ` [PATCH v2 05/11] xen/riscv: add kernel loading support Oleksii Kurochko
2026-03-30 14:47 ` Jan Beulich
[not found] ` <05b1bc67-bbed-412e-881e-a3fb2c2d873b@gmail.com>
2026-03-31 15:14 ` Jan Beulich
[not found] ` <a0efb7a6-4854-4fe5-bbf4-2561f25d7133@gmail.com>
2026-03-31 15:56 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 06/11] xen: move declaration of fw_unreserved_regions() to common header Oleksii Kurochko
2026-03-23 16:29 ` [PATCH v2 07/11] xen: move domain_use_host_layout() to common code Oleksii Kurochko
2026-03-30 15:13 ` Jan Beulich
[not found] ` <57581b7d-cb9f-444c-9321-63b2fc3d09f0@gmail.com>
2026-03-31 15:53 ` Jan Beulich
2026-03-31 16:32 ` Oleksii Kurochko
2026-03-31 19:49 ` Oleksii Kurochko
2026-04-01 5:59 ` Jan Beulich
2026-04-01 14:44 ` Oleksii Kurochko
2026-04-01 5:58 ` Jan Beulich
2026-04-01 14:38 ` Oleksii Kurochko [this message]
2026-04-01 14:42 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 08/11] xen: rename p2m_ipa_bits to p2m_gpa_bits Oleksii Kurochko
2026-03-30 15:16 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 09/11] xen/riscv: introduce p2m_gpa_bits Oleksii Kurochko
2026-03-30 15:34 ` Jan Beulich
2026-03-31 16:02 ` Oleksii Kurochko
2026-04-01 6:07 ` Jan Beulich
2026-04-01 13:50 ` Oleksii Kurochko
2026-04-01 13:57 ` Jan Beulich
2026-03-23 16:29 ` [PATCH v2 10/11] xen/riscv: add definition of guest RAM banks Oleksii Kurochko
2026-03-30 15:51 ` Jan Beulich
2026-03-31 16:14 ` Oleksii Kurochko
2026-04-01 6:17 ` Jan Beulich
2026-04-01 13:57 ` Oleksii Kurochko
2026-04-01 14:22 ` Jan Beulich
2026-04-01 14:53 ` Oleksii Kurochko
2026-04-01 15:10 ` Jan Beulich
2026-04-06 15:43 ` Oleksii Kurochko
2026-04-07 6:23 ` Jan Beulich
2026-04-07 8:54 ` Oleksii Kurochko
2026-04-07 9:09 ` Jan Beulich
2026-04-07 9:19 ` Oleksii Kurochko
2026-03-23 16:29 ` [PATCH v2 11/11] xen/riscv: enable DOMAIN_BUILD_HELPERS Oleksii Kurochko
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=600b1b66-fd85-4b7f-8bdc-793667bccfec@gmail.com \
--to=oleksii.kurochko@gmail.com \
--cc=Romain.Caritey@microchip.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bertrand.marquis@arm.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.