Ping: [PATCH] radeon: avoid boot hang in Xen Dom0
On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich wrote:
On 13.09.16 at 17:54, wrote:
>> While a hard hang in atom_asic_init() likely points at a deeper problem
>> in the driver, restore the capability to boot a Xen Dom0 by simply
>> avoiding the call there: Other than for Xen DomU, Dom0 owning a device
>> does not really mean is has got passed through to it.
>>
>> In case it is of interest for further investigation, lspci for the
>> offending device says:
>>
>> ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
>>
>> Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized
>> environments"
>
> I may have overlooked a different fix dealing with the problem; if
> so, I'd appreciate that fix being pointed out.
Already fixed:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=884031f0aacf57dad1575f96714efc80de9b19cc
Alex
>
> Thanks, Jan
>
>> Signed-off-by: Jan Beulich
>> ---
>> drivers/gpu/drm/radeon/radeon_device.c |3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> --- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c
>> +++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -34,6 +34,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "radeon_reg.h"
>> #include "radeon.h"
>> #include "atom.h"
>> @@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d
>> static bool radeon_device_is_virtual(void)
>> {
>> #ifdef CONFIG_X86
>> - return boot_cpu_has(X86_FEATURE_HYPERVISOR);
>> + return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain();
>> #else
>> return false;
>> #endif
>>
>>
>>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Ping: [PATCH] radeon: avoid boot hang in Xen Dom0
>>> On 04.11.16 at 15:32, wrote: > On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich wrote: > On 13.09.16 at 17:54, wrote: >>> While a hard hang in atom_asic_init() likely points at a deeper problem >>> in the driver, restore the capability to boot a Xen Dom0 by simply >>> avoiding the call there: Other than for Xen DomU, Dom0 owning a device >>> does not really mean is has got passed through to it. >>> >>> In case it is of interest for further investigation, lspci for the >>> offending device says: >>> >>> ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954] >>> >>> Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized >>> environments" >> >> I may have overlooked a different fix dealing with the problem; if >> so, I'd appreciate that fix being pointed out. > > Already fixed: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=88 > 4031f0aacf57dad1575f96714efc80de9b19cc Hmm, that indeed should make the immediate problem go away. Nevertheless I do think that Xen Dom0 should be treated just like native here. Only DomU should be forced through that extra path. I did also notice that the equivalent function under amdgpu/ has gone away again during the 4.9 merge window... Jan
Ping: [PATCH] radeon: avoid boot hang in Xen Dom0
>>> On 13.09.16 at 17:54, wrote:
> While a hard hang in atom_asic_init() likely points at a deeper problem
> in the driver, restore the capability to boot a Xen Dom0 by simply
> avoiding the call there: Other than for Xen DomU, Dom0 owning a device
> does not really mean is has got passed through to it.
>
> In case it is of interest for further investigation, lspci for the
> offending device says:
>
> ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
>
> Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized
> environments"
I may have overlooked a different fix dealing with the problem; if
so, I'd appreciate that fix being pointed out.
Thanks, Jan
> Signed-off-by: Jan Beulich
> ---
> drivers/gpu/drm/radeon/radeon_device.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c
> +++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
> #include "radeon_reg.h"
> #include "radeon.h"
> #include "atom.h"
> @@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d
> static bool radeon_device_is_virtual(void)
> {
> #ifdef CONFIG_X86
> - return boot_cpu_has(X86_FEATURE_HYPERVISOR);
> + return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain();
> #else
> return false;
> #endif
>
>
>
[PATCH] radeon: avoid boot hang in Xen Dom0
While a hard hang in atom_asic_init() likely points at a deeper problem
in the driver, restore the capability to boot a Xen Dom0 by simply
avoiding the call there: Other than for Xen DomU, Dom0 owning a device
does not really mean is has got passed through to it.
In case it is of interest for further investigation, lspci for the
offending device says:
ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954]
Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized
environments"
Signed-off-by: Jan Beulich
---
drivers/gpu/drm/radeon/radeon_device.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 4.8-rc6/drivers/gpu/drm/radeon/radeon_device.c
+++ 4.8-rc6-radeon-Xen-boot/drivers/gpu/drm/radeon/radeon_device.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "radeon_reg.h"
#include "radeon.h"
#include "atom.h"
@@ -642,7 +643,7 @@ void radeon_gtt_location(struct radeon_d
static bool radeon_device_is_virtual(void)
{
#ifdef CONFIG_X86
- return boot_cpu_has(X86_FEATURE_HYPERVISOR);
+ return boot_cpu_has(X86_FEATURE_HYPERVISOR) && !xen_initial_domain();
#else
return false;
#endif
