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 jbeulich@suse.com
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 <linux/vgaarb.h> #include <linux/vga_switcheroo.h> #include <linux/efi.h> +#include <xen/xen.h> #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
On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich JBeulich@suse.com 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...
Alex
Thanks, Jan
Signed-off-by: Jan Beulich jbeulich@suse.com
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 <linux/vgaarb.h> #include <linux/vga_switcheroo.h> #include <linux/efi.h> +#include <xen/xen.h> #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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 04.11.16 at 15:32, alexdeucher@gmail.com wrote:
On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich JBeulich@suse.com 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
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Jan Beulich