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

["Andres Lagar-Cavilla" <andres@lagarcavilla.org>]

> 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.

>
>> I'll refresh and add your signed-off-by to cover the portions of the
>> work
>> that originate from your end, is that ok?
>
> I havent finish the review yet, have to check how it may work with wait
> queues in gfn_to_mfn*.

Another case of "the two separate things" :) We definitely look forward to
wait queue support for gfn_to_mfn*. But that's a separate consumer of the
wait queue feature. Are you worried that this patch might break your
gfn_to_mfn* strategy? We did base it on your work.

Thanks,
Andres
>
> Olaf
>