[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 4/7] x86/xen: support nested lazy_mmu sections (again)
On 05/09/2025 17:48, Alexander Gordeev wrote: > On Thu, Sep 04, 2025 at 01:57:33PM +0100, Kevin Brodsky wrote: > ... >> -static void xen_enter_lazy_mmu(void) >> +static lazy_mmu_state_t xen_enter_lazy_mmu(void) >> { >> + if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) >> + return LAZY_MMU_NESTED; >> + >> enter_lazy(XEN_LAZY_MMU); >> + return LAZY_MMU_DEFAULT; >> } >> >> static void xen_flush_lazy_mmu(void) >> @@ -2167,11 +2171,12 @@ static void __init xen_post_allocator_init(void) >> pv_ops.mmu.write_cr3 = &xen_write_cr3; >> } >> >> -static void xen_leave_lazy_mmu(void) >> +static void xen_leave_lazy_mmu(lazy_mmu_state_t state) >> { >> preempt_disable(); >> xen_mc_flush(); >> - leave_lazy(XEN_LAZY_MMU); >> + if (state != LAZY_MMU_NESTED) >> + leave_lazy(XEN_LAZY_MMU); > Based on xen_enter_lazy_mmu(), whether this condition needs to be > executed with the preemption disabled? AFAIU xen_mc_flush() needs preemption to be disabled. I don't think {enter,leave}_lazy() do, but this patch doesn't introduce any change from that perspective. I suppose it doesn't hurt that xen_leave_lazy_mmu() calls leave_lazy() with preemption disabled. > Or may be this_cpu_read(xen_lazy_mode) + enter_lazy(XEN_LAZY_MMU) > should be executed with the preemption disabled? Adding another this_cpu_read(xen_lazy_mode) in xen_enter_lazy_mmu() shouldn't change the situation, i.e. preemption should still be safe. If preemption occurs in the middle of that function, xen_{start,end}_context_switch() will do the right thing to save/restore xen_lazy_mode. - Kevin
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |