On Sat, Sep 04, 2021 at 11:50:37AM +0800, David Gow wrote:
On Thu, Sep 2, 2021 at 10:46 PM Daniel Vetter daniel@ffwll.ch 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 rdunlap@infradead.org Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: Christian König christian.koenig@amd.com Cc: Huang Rui ray.huang@amd.com Cc: dri-devel@lists.freedesktop.org Cc: Jeff Dike jdike@addtoit.com Cc: Richard Weinberger richard@nod.at Cc: Anton Ivanov anton.ivanov@cambridgegreys.com Cc: linux-um@lists.infradead.org Cc: David Airlie airlied@linux.ie Cc: Daniel Vetter daniel@ffwll.ch
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