[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/2] xen/pdx: account for frametable_base_pdx in generic pdx_to_page/page_to_pdx
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Orzel, Michal" <michal.orzel@xxxxxxx>
- Date: Tue, 5 May 2026 16:52:48 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bRjDYUCgD/tOtGW6rkMYl+B7O9PGHUlDXdxoFIK/BI8=; b=yVR4Hxa7xal0FP5+vdj+GlSDutjTdF2u32QNazs99llhwGo0QEPYilUozc53Ru5RX0WnVsfcgcbnuCtFeUDHFFh9jagd6+clbj/KalkT08Ukkmj2iDKkKz1RGf2dPzTjYwjTxThYD1CBzWN7uI8Glt8RXW187c9TZn5hmngiWvnl5qvyaSeHnFbeFdp5/r1UQ/tH+WKHirEPy96pC9cm8VPVQ8UOvsynN5saq8N+8j1eiFMkse+XLOT5zrmTVg8CBH045pZLvU5SpY8lJlIB8fPsn5yldUwW5hPj8SuJaSFmSosH0mN39jgVVX+15Iy2r4fL5Mh2/TQT7lsR9vDqgw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qfm7Trj3IP1qAiIIETHMWLi7tu66EzFvJkSG6Wgc+CwmH03trdJUU+1UzAdLm7sUVeTKzDDZuCO8HceHL741aKgsJM7wvdqQlYPorWJYFMtZ9bFucAzFBw15eoNJv5M1KNZq+hQF9MCHCrELMhJWLUSf81emMLrUcsTYPRnAoeg4zV6+Cgt1vKEgfYpneNAfiKxTGg9fkApP5lNXK2UWMy6JiM49zZ+xibPQB75w+8lL1pHZGEJ8ElW390QvNSOIpdiP1+rYjmUPfged2KZK8wZ65QLTrJvcXdAxz125ZUPX22Cf71Rl1wQLAmbKwuK3cCCivnyU54plfRxGlAJ40g==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Timothy Pearson <tpearson@xxxxxxxxxxxxxxxxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 05 May 2026 14:53:08 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 05-May-26 15:05, Jan Beulich wrote:
> On 30.04.2026 14:51, Michal Orzel wrote:
>> --- a/xen/include/xen/pdx.h
>> +++ b/xen/include/xen/pdx.h
>> @@ -132,8 +132,9 @@ void set_pdx_range(unsigned long smfn, unsigned long
>> emfn);
>> */
>> bool __mfn_valid(unsigned long mfn);
>>
>> -#define page_to_pdx(pg) ((pg) - frame_table)
>> -#define pdx_to_page(pdx) gcc11_wrap(frame_table + (pdx))
>> +#define page_to_pdx(pg) \
>> + ((unsigned long)((pg) - frame_table) + frametable_base_pdx)
>> +#define pdx_to_page(pdx) gcc11_wrap(frame_table + ((pdx) -
>> frametable_base_pdx))
>
> If you alter these, ...
>
>> #define mfn_to_pdx(mfn) pfn_to_pdx(mfn_x(mfn))
>> #define pdx_to_mfn(pdx) _mfn(pdx_to_pfn(pdx))
>
> ... how come these can remain unaltered? Maybe you have some special
> arrangements in Arm code, but surely in generic code transformations done
> should be uniform. After all
>
> ASSERT(page_to_pdx(pg) == mfn_to_pdx(page_to_mfn(pg)));
>
> (and alike) ought to be universally true for valid inputs.
The invariant holds. There are two transformations on different
boundaries:
- PFN <-> PDX: the compression scheme — lives in mfn_to_pdx /
pdx_to_mfn.
- PDX <-> frame-table index: +/- frametable_base_pdx — lives in
page_to_pdx / pdx_to_page (and Arm's page_to_mfn / mfn_to_page).
On x86 the second is the identity (frametable_base_pdx == 0), so it's
invisible. On Arm it isn't, so it has to appear in the macros that
cross that boundary. Pushing it into mfn_to_pdx as well would mix the
two boundaries and double-apply on Arm (page_to_mfn already adds it).
~Michal
|
