Re: [PATCH] x86/mm: Improve ring management for memory events. Do not lose guest events

[Olaf Hering <olaf@aepfle.de>]

On Fri, Jan 13, Andres Lagar-Cavilla wrote:

> > On Fri, Jan 13, Andres Lagar-Cavilla wrote:
> >
> >> > p2m_mem_paging_drop_page() should remain void because the caller has
> >> > already done its work, making it not restartable. Also it is only
> >> called
> >> > when a gfn is in paging state, which I'm sure can not happen without a
> >> > ring.
> >>
> >> Well, the rationale is that returning an error code can only help,
> >> should
> >> new error conditions arise. Keep in mind that the pager and the ring can
> >> disappear at any time, so ENOSYS can still happen.
> >
> > The ring should rather not disappear at all until ->paged_pages drops to
> > zero. Unless the goal is a restartable pager,
> > XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
> > ->pages_pages is not zero. Then the checks in drop_page and populate can
> > be relaxed.
> 
> Well, there are two separate things here. Should drop return an error
> code? No harm in that. Then there is your point about the ring not going
> away if ->paged_pages is nonzero. Which I like, but is currently not
> implemented, afaict. Separate patch I guess.

Since there is no consumer of the added return codes from
p2m_mem_paging_drop_page() and p2m_mem_paging_populate() I dont see the
point to change the function prototypes.

I will prepare a patch to improve the check wether the ring is
available. As you said, it can disappear any time.

Olaf