Re: [PATCH v3] drivers/hv: remove deposited pages from direct map

[Anirudh Rayabharam <anirudh@anirudhrb.com>]

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.