[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n and CONFIG_COVERAGE=y [and 1 more messages]
Julien Grall writes ("[PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n and CONFIG_COVERAGE=y"): > Xen is heavily relying on the DCE stage to remove unused code so the > linker doesn't throw an error because a function is not implemented > yet we defined a prototype for it. Thanks for the clear explanation. > It is not entirely clear why the compiler DCE is not detecting the > unused code. However, moving the permission check from do_memory_op() > to xenmem_add_to_physmap_batch() does the trick. How unfortunate. > Fixes: d4f699a0df6c ("x86/mm: p2m_add_foreign() is HVM-only") > Reported-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx> > Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> I have reviewed the diff, but not the code in context. > The gitlab CI is used to provide basic testing on a per-series basis. So > I would like to request this patch to be merged in Xen 4.15 in order to > reduce the number of failure not related to the series tested. Quite so. Jan Beulich writes ("Re: [PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n and CONFIG_COVERAGE=y"): > On 30.01.2021 16:22, Julien Grall wrote: > > @@ -1442,13 +1447,6 @@ long do_memory_op(unsigned long cmd, > > XEN_GUEST_HANDLE_PARAM(void) arg) > > if ( d == NULL ) > > return -ESRCH; > > > > - rc = xatp_permission_check(d, xatpb.space); > > - if ( rc ) > > - { > > - rcu_unlock_domain(d); > > - return rc; > > - } > > - > > rc = xenmem_add_to_physmap_batch(d, &xatpb, start_extent); > > > > rcu_unlock_domain(d); > > I'd be okay with the code movement if you did so consistently, > i.e. also for the other invocation. I realize this would have > an effect on the dm-op call of the function, but I wonder > whether this wouldn't even be a good thing. If not, I think > duplicating xenmem_add_to_physmap()'s early ASSERT() into > xenmem_add_to_physmap_batch() would be the better course of > action. Jan, can you confirm whether in your opinion this patch as originally posted by Julien is *correct* as is ? In particular, Julien did not intend a functional change. Have you satisfied yourself that there is no functional change here ? I understand your objectiion above to relate to style or neatness, rather than function. Is that correct ? And that your proposed additional change would have some impact whilch would have to be assessed. In which case I think it would be better to defer the style improvement until after the release. IOW, the original patch Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx> assuming a favourable functional code review from a relevant maintainer. Thanks, Ian.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |