boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
member named 'x86', so provide a default page protection mode
for CONFIG_UML.
Mends this build error:
../drivers/gpu/drm/ttm/ttm_module.c: In function ‘ttm_prot_from_caching’:
../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct cpuinfo_um’ has no member named ‘x86’
else if (boot_cpu_data.x86 > 3)
^
Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Christian König <[email protected]>
Cc: Huang Rui <[email protected]>
Cc: [email protected]
Cc: Jeff Dike <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Anton Ivanov <[email protected]>
Cc: [email protected]
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
---
drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
1 file changed, 4 insertions(+)
--- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
+++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
@@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
if (caching == ttm_cached)
return tmp;
+#ifdef CONFIG_UML
+ tmp = pgprot_noncached(tmp);
+#else
#if defined(__i386__) || defined(__x86_64__)
if (caching == ttm_write_combined)
tmp = pgprot_writecombine(tmp);
@@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
#if defined(__sparc__)
tmp = pgprot_noncached(tmp);
#endif
+#endif
return tmp;
}
On 02/09/2021 03:01, Randy Dunlap wrote:
> boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
> member named 'x86', so provide a default page protection mode
> for CONFIG_UML.
>
> Mends this build error:
> ../drivers/gpu/drm/ttm/ttm_module.c: In function ‘ttm_prot_from_caching’:
> ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct cpuinfo_um’ has no member named ‘x86’
> else if (boot_cpu_data.x86 > 3)
> ^
>
> Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Thomas Hellström <[email protected]>
> Cc: Christian König <[email protected]>
> Cc: Huang Rui <[email protected]>
> Cc: [email protected]
> Cc: Jeff Dike <[email protected]>
> Cc: Richard Weinberger <[email protected]>
> Cc: Anton Ivanov <[email protected]>
> Cc: [email protected]
> Cc: David Airlie <[email protected]>
> Cc: Daniel Vetter <[email protected]>
> ---
> drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
> +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
> @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> if (caching == ttm_cached)
> return tmp;
>
> +#ifdef CONFIG_UML
> + tmp = pgprot_noncached(tmp);
> +#else
> #if defined(__i386__) || defined(__x86_64__)
> if (caching == ttm_write_combined)
> tmp = pgprot_writecombine(tmp);
> @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> #if defined(__sparc__)
> tmp = pgprot_noncached(tmp);
> #endif
> +#endif
> return tmp;
> }
>
Patch looks OK.
I have a question though - why all of DRM is not !UML in config. Not
like we can use them.
>
> _______________________________________________
> linux-um mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-um
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
> > >
> > > I have a question though - why all of DRM is not !UML in config. Not
> > > like we can use them.
> >
> > I have no idea about that.
> > Hopefully one of the (other) UML maintainers can answer you.
>
> Touche.
>
> We will discuss that and possibly push a patch to !UML that part of the
> tree. IMHO it is not applicable.
As I just said on the other patch, all of this is fallout from my commit
68f5d3f3b654 ("um: add PCI over virtio emulation driver") which is the
first time that you could have PCI on UML.
Without having checked, in this particular case it's probably something
like
depends on PCI && X86_64
as we've seen in other drivers (idxd, ioat).
The biggest problem is probably that UML internally uses X86_64
(arch/x86/um/Kconfig), which is ... unexpected ... since CONFIG_X86_64
is typically considered the ARCH, and now the ARCH is actually um.
I think we can just fix that and get rid of this entire class of
problems? Something like
https://p.sipsolutions.net/fbac19d86637e286.txt
johannes
On 02/09/2021 08:43, Johannes Berg wrote:
> On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
>>>>
>>>> I have a question though - why all of DRM is not !UML in config. Not
>>>> like we can use them.
>>>
>>> I have no idea about that.
>>> Hopefully one of the (other) UML maintainers can answer you.
>>
>> Touche.
>>
>> We will discuss that and possibly push a patch to !UML that part of the
>> tree. IMHO it is not applicable.
>
> As I just said on the other patch, all of this is fallout from my commit
> 68f5d3f3b654 ("um: add PCI over virtio emulation driver") which is the
> first time that you could have PCI on UML.
>
> Without having checked, in this particular case it's probably something
> like
>
> depends on PCI && X86_64
>
> as we've seen in other drivers (idxd, ioat).
>
> The biggest problem is probably that UML internally uses X86_64
> (arch/x86/um/Kconfig), which is ... unexpected ... since CONFIG_X86_64
> is typically considered the ARCH, and now the ARCH is actually um.
>
> I think we can just fix that and get rid of this entire class of
> problems? Something like
>
> https://p.sipsolutions.net/fbac19d86637e286.txt
Good idea. I suspect that DRM will not be the only thing to pop up out
of this so we might as well fix it "at the top".
A
>
> johannes
>
>
>
> _______________________________________________
> linux-um mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-um
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On 02/09/2021 06:52, Randy Dunlap wrote:
> On 9/1/21 10:48 PM, Anton Ivanov wrote:
>> On 02/09/2021 03:01, Randy Dunlap wrote:
>>> boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
>>> member named 'x86', so provide a default page protection mode
>>> for CONFIG_UML.
>>>
>>> Mends this build error:
>>> ../drivers/gpu/drm/ttm/ttm_module.c: In function
>>> ‘ttm_prot_from_caching’:
>>> ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct cpuinfo_um’
>>> has no member named ‘x86’
>>> else if (boot_cpu_data.x86 > 3)
>>> ^
>>>
>>> Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
>>> page-based iomem")
>>> Signed-off-by: Randy Dunlap <[email protected]>
>>> Cc: Thomas Hellström <[email protected]>
>>> Cc: Christian König <[email protected]>
>>> Cc: Huang Rui <[email protected]>
>>> Cc: [email protected]
>>> Cc: Jeff Dike <[email protected]>
>>> Cc: Richard Weinberger <[email protected]>
>>> Cc: Anton Ivanov <[email protected]>
>>> Cc: [email protected]
>>> Cc: David Airlie <[email protected]>
>>> Cc: Daniel Vetter <[email protected]>
>>> ---
>>> drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
>>> +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
>>> @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
>>> if (caching == ttm_cached)
>>> return tmp;
>>> +#ifdef CONFIG_UML
>>> + tmp = pgprot_noncached(tmp);
>>> +#else
>>> #if defined(__i386__) || defined(__x86_64__)
>>> if (caching == ttm_write_combined)
>>> tmp = pgprot_writecombine(tmp);
>>> @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
>>> #if defined(__sparc__)
>>> tmp = pgprot_noncached(tmp);
>>> #endif
>>> +#endif
>>> return tmp;
>>> }
>>
>> Patch looks OK.
>>
>> I have a question though - why all of DRM is not !UML in config. Not
>> like we can use them.
>
> I have no idea about that.
> Hopefully one of the (other) UML maintainers can answer you.
Touche.
We will discuss that and possibly push a patch to !UML that part of the
tree. IMHO it is not applicable.
A.
>
> thanks.
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
On 9/1/21 10:48 PM, Anton Ivanov wrote:
> On 02/09/2021 03:01, Randy Dunlap wrote:
>> boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
>> member named 'x86', so provide a default page protection mode
>> for CONFIG_UML.
>>
>> Mends this build error:
>> ../drivers/gpu/drm/ttm/ttm_module.c: In function ‘ttm_prot_from_caching’:
>> ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct cpuinfo_um’ has no member named ‘x86’
>> else if (boot_cpu_data.x86 > 3)
>> ^
>>
>> Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
>> Signed-off-by: Randy Dunlap <[email protected]>
>> Cc: Thomas Hellström <[email protected]>
>> Cc: Christian König <[email protected]>
>> Cc: Huang Rui <[email protected]>
>> Cc: [email protected]
>> Cc: Jeff Dike <[email protected]>
>> Cc: Richard Weinberger <[email protected]>
>> Cc: Anton Ivanov <[email protected]>
>> Cc: [email protected]
>> Cc: David Airlie <[email protected]>
>> Cc: Daniel Vetter <[email protected]>
>> ---
>> drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
>> +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
>> @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
>> if (caching == ttm_cached)
>> return tmp;
>> +#ifdef CONFIG_UML
>> + tmp = pgprot_noncached(tmp);
>> +#else
>> #if defined(__i386__) || defined(__x86_64__)
>> if (caching == ttm_write_combined)
>> tmp = pgprot_writecombine(tmp);
>> @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
>> #if defined(__sparc__)
>> tmp = pgprot_noncached(tmp);
>> #endif
>> +#endif
>> return tmp;
>> }
>
> Patch looks OK.
>
> I have a question though - why all of DRM is not !UML in config. Not like we can use them.
I have no idea about that.
Hopefully one of the (other) UML maintainers can answer you.
thanks.
--
~Randy
On Thu, 2021-09-02 at 09:10 +0100, Anton Ivanov wrote:
> On 02/09/2021 08:43, Johannes Berg wrote:
> > On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
> > > > >
> > > > > I have a question though - why all of DRM is not !UML in config. Not
> > > > > like we can use them.
> > > >
> > > > I have no idea about that.
> > > > Hopefully one of the (other) UML maintainers can answer you.
> > >
> > > Touche.
> > >
> > > We will discuss that and possibly push a patch to !UML that part of the
> > > tree. IMHO it is not applicable.
> >
> > As I just said on the other patch, all of this is fallout from my commit
> > 68f5d3f3b654 ("um: add PCI over virtio emulation driver") which is the
> > first time that you could have PCI on UML.
> >
> > Without having checked, in this particular case it's probably something
> > like
> >
> > depends on PCI && X86_64
> >
> > as we've seen in other drivers (idxd, ioat).
> >
> > The biggest problem is probably that UML internally uses X86_64
> > (arch/x86/um/Kconfig), which is ... unexpected ... since CONFIG_X86_64
> > is typically considered the ARCH, and now the ARCH is actually um.
> >
> > I think we can just fix that and get rid of this entire class of
> > problems? Something like
> >
> > https://p.sipsolutions.net/fbac19d86637e286.txt
>
> Good idea. I suspect that DRM will not be the only thing to pop up out
> of this so we might as well fix it "at the top".
Yeah I sent like a handful of similar patches ...
I'll send that patch out in a minute, just writing a reasonable commit
log. Seems to build & work fine for me.
johannes
Am 02.09.21 um 09:43 schrieb Johannes Berg:
> On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
>>>> I have a question though - why all of DRM is not !UML in config. Not
>>>> like we can use them.
>>> I have no idea about that.
>>> Hopefully one of the (other) UML maintainers can answer you.
>> Touche.
>>
>> We will discuss that and possibly push a patch to !UML that part of the
>> tree. IMHO it is not applicable.
> As I just said on the other patch, all of this is fallout from my commit
> 68f5d3f3b654 ("um: add PCI over virtio emulation driver") which is the
> first time that you could have PCI on UML.
>
> Without having checked, in this particular case it's probably something
> like
>
> depends on PCI && X86_64
>
> as we've seen in other drivers (idxd, ioat).
>
> The biggest problem is probably that UML internally uses X86_64
> (arch/x86/um/Kconfig), which is ... unexpected ... since CONFIG_X86_64
> is typically considered the ARCH, and now the ARCH is actually um.
Yeah, as TTM maintainer I was about to NAK that approach here.
Basically you are claiming to be X86_64, but then you don't use the
X86_64 architecture and are surprised that it things break somewhere else.
This is not something you can blame on subsystems or even drivers, but
rather just a broken architectural design and so needs to be fixed there.
Regards,
Christian.
>
> I think we can just fix that and get rid of this entire class of
> problems? Something like
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp.sipsolutions.net%2Ffbac19d86637e286.txt&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd773b1e8b66643874d1308d96de56a86%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637661654674393046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xBT%2Fj%2FbEgltQfvE%2B7%2FGRV7IctGn3sDvy8ycmBvTTSXU%3D&reserved=0
>
> johannes
>
>
On Thu, Sep 02, 2021 at 07:19:01AM +0100, Anton Ivanov wrote:
> On 02/09/2021 06:52, Randy Dunlap wrote:
> > On 9/1/21 10:48 PM, Anton Ivanov wrote:
> > > On 02/09/2021 03:01, Randy Dunlap wrote:
> > > > boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
> > > > member named 'x86', so provide a default page protection mode
> > > > for CONFIG_UML.
> > > >
> > > > Mends this build error:
> > > > ../drivers/gpu/drm/ttm/ttm_module.c: In function
> > > > ‘ttm_prot_from_caching’:
> > > > ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct
> > > > cpuinfo_um’ has no member named ‘x86’
> > > > else if (boot_cpu_data.x86 > 3)
> > > > ^
> > > >
> > > > Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
> > > > page-based iomem")
> > > > Signed-off-by: Randy Dunlap <[email protected]>
> > > > Cc: Thomas Hellström <[email protected]>
> > > > Cc: Christian König <[email protected]>
> > > > Cc: Huang Rui <[email protected]>
> > > > Cc: [email protected]
> > > > Cc: Jeff Dike <[email protected]>
> > > > Cc: Richard Weinberger <[email protected]>
> > > > Cc: Anton Ivanov <[email protected]>
> > > > Cc: [email protected]
> > > > Cc: David Airlie <[email protected]>
> > > > Cc: Daniel Vetter <[email protected]>
> > > > ---
> > > > drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
> > > > +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
> > > > @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> > > > if (caching == ttm_cached)
> > > > return tmp;
> > > > +#ifdef CONFIG_UML
> > > > + tmp = pgprot_noncached(tmp);
> > > > +#else
> > > > #if defined(__i386__) || defined(__x86_64__)
> > > > if (caching == ttm_write_combined)
> > > > tmp = pgprot_writecombine(tmp);
> > > > @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> > > > #if defined(__sparc__)
> > > > tmp = pgprot_noncached(tmp);
> > > > #endif
> > > > +#endif
> > > > return tmp;
> > > > }
> > >
> > > Patch looks OK.
> > >
> > > I have a question though - why all of DRM is not !UML in config. Not
> > > like we can use them.
> >
> > I have no idea about that.
> > Hopefully one of the (other) UML maintainers can answer you.
>
> Touche.
>
> We will discuss that and possibly push a patch to !UML that part of the
> tree. IMHO it is not applicable.
I thought kunit is based on top of uml, and we do want to eventually adopt
that. Especially for helper libraries like ttm.
But also that's quite a bit in the future.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Sep 2, 2021 at 10:46 PM Daniel Vetter <[email protected]> wrote:
>
> On Thu, Sep 02, 2021 at 07:19:01AM +0100, Anton Ivanov wrote:
> > On 02/09/2021 06:52, Randy Dunlap wrote:
> > > On 9/1/21 10:48 PM, Anton Ivanov wrote:
> > > > On 02/09/2021 03:01, Randy Dunlap wrote:
> > > > > boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
> > > > > member named 'x86', so provide a default page protection mode
> > > > > for CONFIG_UML.
> > > > >
> > > > > Mends this build error:
> > > > > ../drivers/gpu/drm/ttm/ttm_module.c: In function
> > > > > ‘ttm_prot_from_caching’:
> > > > > ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct
> > > > > cpuinfo_um’ has no member named ‘x86’
> > > > > else if (boot_cpu_data.x86 > 3)
> > > > > ^
> > > > >
> > > > > Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
> > > > > page-based iomem")
> > > > > Signed-off-by: Randy Dunlap <[email protected]>
> > > > > Cc: Thomas Hellström <[email protected]>
> > > > > Cc: Christian König <[email protected]>
> > > > > Cc: Huang Rui <[email protected]>
> > > > > Cc: [email protected]
> > > > > Cc: Jeff Dike <[email protected]>
> > > > > Cc: Richard Weinberger <[email protected]>
> > > > > Cc: Anton Ivanov <[email protected]>
> > > > > Cc: [email protected]
> > > > > Cc: David Airlie <[email protected]>
> > > > > Cc: Daniel Vetter <[email protected]>
> > > > > ---
> > > > > drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
> > > > > 1 file changed, 4 insertions(+)
> > > > >
> > > > > --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
> > > > > +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
> > > > > @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> > > > > if (caching == ttm_cached)
> > > > > return tmp;
> > > > > +#ifdef CONFIG_UML
> > > > > + tmp = pgprot_noncached(tmp);
> > > > > +#else
> > > > > #if defined(__i386__) || defined(__x86_64__)
> > > > > if (caching == ttm_write_combined)
> > > > > tmp = pgprot_writecombine(tmp);
> > > > > @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> > > > > #if defined(__sparc__)
> > > > > tmp = pgprot_noncached(tmp);
> > > > > #endif
> > > > > +#endif
> > > > > return tmp;
> > > > > }
> > > >
> > > > Patch looks OK.
> > > >
> > > > I have a question though - why all of DRM is not !UML in config. Not
> > > > like we can use them.
> > >
> > > I have no idea about that.
> > > Hopefully one of the (other) UML maintainers can answer you.
> >
> > Touche.
> >
> > We will discuss that and possibly push a patch to !UML that part of the
> > tree. IMHO it is not applicable.
>
> I thought kunit is based on top of uml, and we do want to eventually adopt
> that. Especially for helper libraries like ttm.
UML is not actually a dependency for KUnit, so it's definitely
possible to test things which aren't compatible with UML. (In fact,
there's even now some tooling support to use qemu instead on a number
of architectures.)
That being said, the KUnit tooling does use UML by default, so if it's
not too difficult to keep some level of UML support, it'll make it a
little easier (and faster) for people to run any KUnit tests.
Cheers,
-- David
On Sat, Sep 04, 2021 at 11:50:37AM +0800, David Gow wrote:
> On Thu, Sep 2, 2021 at 10:46 PM Daniel Vetter <[email protected]> wrote:
> >
> > On Thu, Sep 02, 2021 at 07:19:01AM +0100, Anton Ivanov wrote:
> > > On 02/09/2021 06:52, Randy Dunlap wrote:
> > > > On 9/1/21 10:48 PM, Anton Ivanov wrote:
> > > > > On 02/09/2021 03:01, Randy Dunlap wrote:
> > > > > > boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
> > > > > > member named 'x86', so provide a default page protection mode
> > > > > > for CONFIG_UML.
> > > > > >
> > > > > > Mends this build error:
> > > > > > ../drivers/gpu/drm/ttm/ttm_module.c: In function
> > > > > > ‘ttm_prot_from_caching’:
> > > > > > ../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct
> > > > > > cpuinfo_um’ has no member named ‘x86’
> > > > > > else if (boot_cpu_data.x86 > 3)
> > > > > > ^
> > > > > >
> > > > > > Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
> > > > > > page-based iomem")
> > > > > > Signed-off-by: Randy Dunlap <[email protected]>
> > > > > > Cc: Thomas Hellström <[email protected]>
> > > > > > Cc: Christian König <[email protected]>
> > > > > > Cc: Huang Rui <[email protected]>
> > > > > > Cc: [email protected]
> > > > > > Cc: Jeff Dike <[email protected]>
> > > > > > Cc: Richard Weinberger <[email protected]>
> > > > > > Cc: Anton Ivanov <[email protected]>
> > > > > > Cc: [email protected]
> > > > > > Cc: David Airlie <[email protected]>
> > > > > > Cc: Daniel Vetter <[email protected]>
> > > > > > ---
> > > > > > drivers/gpu/drm/ttm/ttm_module.c | 4 ++++
> > > > > > 1 file changed, 4 insertions(+)
> > > > > >
> > > > > > --- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
> > > > > > +++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
> > > > > > @@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> > > > > > if (caching == ttm_cached)
> > > > > > return tmp;
> > > > > > +#ifdef CONFIG_UML
> > > > > > + tmp = pgprot_noncached(tmp);
> > > > > > +#else
> > > > > > #if defined(__i386__) || defined(__x86_64__)
> > > > > > if (caching == ttm_write_combined)
> > > > > > tmp = pgprot_writecombine(tmp);
> > > > > > @@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
> > > > > > #if defined(__sparc__)
> > > > > > tmp = pgprot_noncached(tmp);
> > > > > > #endif
> > > > > > +#endif
> > > > > > return tmp;
> > > > > > }
> > > > >
> > > > > Patch looks OK.
> > > > >
> > > > > I have a question though - why all of DRM is not !UML in config. Not
> > > > > like we can use them.
> > > >
> > > > I have no idea about that.
> > > > Hopefully one of the (other) UML maintainers can answer you.
> > >
> > > Touche.
> > >
> > > We will discuss that and possibly push a patch to !UML that part of the
> > > tree. IMHO it is not applicable.
> >
> > I thought kunit is based on top of uml, and we do want to eventually adopt
> > that. Especially for helper libraries like ttm.
>
> UML is not actually a dependency for KUnit, so it's definitely
> possible to test things which aren't compatible with UML. (In fact,
> there's even now some tooling support to use qemu instead on a number
> of architectures.)
>
> That being said, the KUnit tooling does use UML by default, so if it's
> not too difficult to keep some level of UML support, it'll make it a
> little easier (and faster) for people to run any KUnit tests.
Yeah my understanding is that uml is the quickest way to spawn a new
kernel, which kunit needs to run. And I really do like that idea, because
having virtualization support in cloud CI systems (which use containers
themselves) is a bit a fun exercise. The less we rely on virtual machines
in containers for that, the better.
Hence why I really like the uml approach for kunit.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch