On Fri, Sep 25, 2026 at 01:57:29PM +0200, Magnus Kulke wrote:
> 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?
Yeah, sounds good!
Thanks,
Anirudh.
>
> > > + *
> > > + * 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.
