On Tue, 22 Mar 2022, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > On 22/03/2022 14:49, Jani Nikula wrote: >> On Tue, 22 Mar 2022, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote: >>> On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote: >>>> On Mon, 21 Mar 2022, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote: >>>>> On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote: >>>>>> Wanted to ping this older thread to find out where we stand with this patch, >>>>>> Are we OK with the current state of these changes? >>>>>> >>>>>> With more recent information gathered from feedback on other patches, would >>>>>> we prefer changing this to a more arch-neutral control flow? >>>>>> >>>>>> e.g. >>>>>> #if IS_ENABLED(CONFIG_X86) >>>>>> ... >>>>>> #else >>>>>> ... >>>>>> #endif >>>>>> >>>>>> Would we also prefer this RFC series be merged or would it be preferred to >>>>>> create a new series instead? >>>>> >>>>> for this specific function, that is used in only 2 places I think it's >>>>> ok to do: >>>>> >>>>> static inline bool run_as_guest(void) >>>>> { >>>>> #if IS_ENABLED(CONFIG_X86) >>>>> return !hypervisor_is_type(X86_HYPER_NATIVE); >>>>> #else >>>>> /* Not supported yet */ >>>>> return false; >>>>> #endif >>>>> } >>>>> >>>>> For PCH it doesn't really matter as we don't execute that function >>>>> for discrete. For intel_vtd_active() I figure anything other than >>>>> x86 would be fine with false here. >>>>> >>>>> Jani, that this look good to you? >>>> >>>> It's more important to me to get this out of i915_drv.h, which is not >>>> supposed to be a collection of random stuff anymore. I've sent patches >>>> to this effect but they've stalled a bit. >>> >>> do you have a patch moving this particular one? got a link? >> >> Yeah, but it was basically shot down by Tvrtko [1], and I stalled there. >> >> I'd just like to get all this cruft out of i915_drv.h. Whenever we have >> a file where the name isn't super specific, we seem to have a tendency >> of turning it into a dumping ground for random crap. So I'd really like >> to move this out of there *before* expanding on it. > > Sounds like we had agreement on what tweaks to make and I conceded to > live for now with the IMO wrongly named intel_vtd_run_as_guest. > > (I mean I really disagree with file name being trumps, which I think > this example illustrates - this is i915 asking whether the kernel is > running as guest so intel_vtd_ prefix is just wrong. Intel VT-d is the > iommu thingy so it makes no sense when called from PCH detection. But I > have no better ideas at the moment. We can call it i915_run_as_guest, to > signify function belongs to i915, but then we lose the first parameter > names the function rule.) I think the "first parameter names the function" rule has backfired in gem/gt land, because it's pretty difficult to figure out *where* you'd expect to find or place functions. BR, Jani. > > But in any case I don't see that I created any blockers in this thread. > AFAICS just a respin with intel_vtd_active taking struct device is > needed and job done. > > Regards, > > Tvrtko -- Jani Nikula, Intel Open Source Graphics Center