On Wed, Sep 10 2025, Matthew Wilcox wrote:

> On Wed, Sep 10, 2025 at 05:34:40PM +0200, Pratyush Yadav wrote:
>> +#define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
>> +
>> +/*
>> + * KHO uses page->private, which is an unsigned long, to store page 
>> metadata.
>> + * Use it to store both the magic and the order.
>> + */
>> +union kho_page_info {
>> +    unsigned long page_private;
>> +    struct {
>> +            unsigned int order;
>> +            unsigned int magic;
>> +    };
>
> KHO is only supported on 64-bit?

Yes. Currently only x86_64 and ARM64. It is mainly for hypervisor live
update so there isn't much reason to support it on 32-bit platforms.

>
>> @@ -210,16 +226,16 @@ static void kho_restore_page(struct page *page, 
>> unsigned int order)
>>  struct folio *kho_restore_folio(phys_addr_t phys)
>>  {
>>      struct page *page = pfn_to_online_page(PHYS_PFN(phys));
>> -    unsigned long order;
>> +    union kho_page_info info;
>>  
>>      if (!page)
>>              return NULL;
>>  
>> -    order = page->private;
>> -    if (order > MAX_PAGE_ORDER)
>> +    info.page_private = page->private;
>> +    if (info.magic != KHO_PAGE_MAGIC || info.order > MAX_PAGE_ORDER)
>>              return NULL;
>>  
>> -    kho_restore_page(page, order);
>> +    kho_restore_page(page, info.order);
>>      return page_folio(page);
>
> This all looks very confused.  Before your patch as well as after it.
> I don't see anything in the current KHO code that requires the
> phys_addr_t to be order-aligned.

Right, good point. I can send that as a follow up patch. But I think
this patch stands on its own without that fix too.

-- 
Regards,
Pratyush Yadav

Reply via email to