On Thu, Sep 24, 2026 at 01:51:10PM +0000, Anirudh Rayabharam wrote:
> On Thu, Sep 17, 2026 at 10:10:52PM +0200, Magnus Kulke wrote:
> > +
> > + for (i = 0; i < count; ++i) {
> > + page = pfn_to_page(pfns[i]);
> > + ret = set_direct_map_valid_noflush(page, 1, true);
>
> Should we batch this? (i.e. collect a batch of contiguous PFNs and restore
> them
> at once)
yeah, seems conceivable. let me check.
>
> > + /*
> > + * HV_DEPOSIT_MAX is capped at 511, so a deposit range cannot
> > cover
> > + * a 2MiB page, so deposited pages are of 4k granularity and
> > cannot
> > + * be collapses into a 2MiB page, which would require an
> > allocation
>
> 511 is the limit for one deposit call. But after multiple deposit calls,
> a deposited range can cover a 2 MiB page.
>
> > + * and can potentially fail.
>
> It is unclear to me what requires an allocation and can potentially
> fail. Could you please clarify?
>
yeah, admittedly this is properly an overly defensive comment. the point
was: set_direct_map_valid_noflush() is fallible. I understand one of the
reasons for it to fail would be reoganization of the direct map,
which would imply allocations, which in turn could fail.
but this is contrived and should not happen for the deposit case. Also,
with Mukesh's proposed rework, this comment would not be accurate anymore.
So, I'd remove the reasoning from the comment (but keep the logic), ack?
> > + *
> > + * Should it fail anyway we leak the page, if we would hand it
> > + * back to the allocator we would introduce faults into random
> > other
> > + * parts.
>
> I agree this is what we should do. I just don't understand what the
> first part of this comment block is talking about.
>
> Thanks,
> Anirudh.
