[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call
>>> On 10.05.19 at 16:04, <julien.grall@xxxxxxx> wrote: > On 10/05/2019 14:45, Jan Beulich wrote: >>>>> On 10.05.19 at 15:41, <julien.grall@xxxxxxx> wrote: >>> The point here, we keep within the hypervisor the idea of what's valid or >>> invalid. This allows us more flexibility on the value here (imagine we >>> decide to >>> change the value of GFN_INVALID in the future...). >> >> Exactly, and hence INVALID_GFN should not become visible to the >> outside. Hence my request to use an all-ones value here. > It is only visible if you put an exact value in the documentation. Your > suggestion is to put a exactly value and I would rather not see that. I did specifically suggest to _not_ store INVALID_GFN here, but to store 64-bit bits of ones. Note the difference between the two on 32-bit Arm. >>>>> Well, it at least tell you the function can't work. So I think it is >>>>> still makes >>>>> sense to have it. >>>> >>>> I disagree. >>> You disagree because...? >> >> Because of what I've said in my initial reply (still quoted above). > > I still don't see the problem of unconditional log message. It is not really > the > first place we have that. > >> >>> I hope you are aware, this is unlikely going to be printed as the code >>> should >>> not be called. >> >> ASSERT_UNREACHABLE() then? > > And still avoiding the printk? Preferably yes; depends on how exactly you code the assertion. If you follow the if()-ASSERT_UNREACHABLE()-return style we've been using elsewhere, then no matter how you place the #else or #endif the printk() will be compiled out. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |