[Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest

[Tvrtko Ursulin]

On 22/03/2022 14:49, Jani Nikula wrote:
> On Tue, 22 Mar 2022, Lucas De Marchi <lucas.demarchi at intel.com> wrote:
>> On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
>>> On Mon, 21 Mar 2022, Lucas De Marchi <lucas.demarchi at intel.com> 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.)

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