Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

Hello Aneesh,

The Nemo board boots with your patch but unfortunately I don't see any 
boot messages anymore.

Please find attached the kernel config.

Thanks,
Christian


On 09 August 2020 at 5:49 pm, Christian Zigotzky wrote:

Hello Aneesh,

Many thanks for your fast response and thanks a lot for your patch!
I will patch and compile a new git kernel tomorrow. I am looking forward to the result.

Have a nice day!

Cheers,
Christian

quoted

On 9. Aug 2020, at 17:11, Aneesh Kumar K.V [off-list ref] wrote:

"Aneesh Kumar K.V" [off-list ref] writes:

quoted

quoted

On 8/9/20 8:04 PM, Aneesh Kumar K.V wrote:
On 8/9/20 7:42 PM, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the
latest Git kernel anymore after the commit "powerpc/book3s64/pkeys:
Simplify pkey disable branch" [2].

I bisected today [3].

Result: powerpc/book3s64/pkeys: Simplify pkey disable branch
(a4678d4b477c3d2901f101986ca01406f3b7eaea) [2] is the first bad commit.

Unfortunately I wasn't able to revert the first bad commit. The first
bad commit depends on many other commits, which unfortunately I don't
know. I tried to remove the modifications of the files from the first
bad commit but without any success. There are just too many dependencies.

Additionally I reverted the commit "selftests/powerpc: Fix pkey
syscall redefinitions" [4] and compiled a new kernel but without any
success.

Could you please check the first bad commit?

Thanks,
Christian

Can you share a successful boot log of the system so that i can double
check the cpu_feature and mmu_feature reported ? I am looking for
details similar to below.

[    0.000000] cpu_features      = 0x0001c07f8f5f91a7
[    0.000000]   possible        = 0x0001fbffcf5fb1a7
[    0.000000]   always          = 0x00000003800081a1
[    0.000000] cpu_user_features = 0xdc0065c2 0xefe00000
[    0.000000] mmu_features      = 0x7c006001
[    0.000000] firmware_features = 0x0000001fc45bfc57
[    0.000000] vmalloc start     = 0xc008000000000000
[    0.000000] IO start          = 0xc00a000000000000
[    0.000000] vmemmap start     = 0xc00c000000000000


IIUC this is P5+? (ISA 2.04). On that pkey should be marked disabled via

static int scan_pkey_feature(void)
{
     int ret;
     int pkeys_total = 0;

     ....

     /*
      * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
      */
     if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
         return 0;


}

Can you boot with CONFIG_PPC_MEM_KEYS=n ?

Can you try this change on top of master?


modified   arch/powerpc/mm/book3s64/pkeys.c

@@ -215,10 +215,6 @@ void __init pkey_early_init_devtree(void)

      pr_info("Enabling pkeys with max key count %d\n", num_pkey);
  out:
-    /*
-     * Setup uamor on boot cpu
-     */
-    mtspr(SPRN_UAMOR, default_uamor);

      return;
  }

Full patch with better description.

commit 919a177bcdaf1eaeaeecc0d0f50a688629d7b5df
Author: Aneesh Kumar K.V [off-list ref]
Date:   Sun Aug 9 20:37:38 2020 +0530

    powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)

    On p6 and before we should avoid updating UAMOR SPRN. This resulted
    in boot failure on Nemo board.

    Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on POWER6 and before")
    Reported-by: Christian Zigotzky [off-list ref]
    Signed-off-by: Aneesh Kumar K.V [off-list ref]

diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
index 69a6b87f2bb4..b1d091a97611 100644
--- a/arch/powerpc/mm/book3s64/pkeys.c
+++ b/arch/powerpc/mm/book3s64/pkeys.c

@@ -73,12 +73,6 @@ static int scan_pkey_feature(void)
    if (early_radix_enabled())
        return 0;

-    /*
-     * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
-     */
-    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
-        return 0;
-
    ret = of_scan_flat_dt(dt_scan_storage_keys, &pkeys_total);
    if (ret == 0) {
        /*

@@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)
             __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
                != (sizeof(u64) * BITS_PER_BYTE));

+    /*
+     * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
+     */
+    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
+        return;
+
    /* scan the device tree for pkey feature */
    pkeys_total = scan_pkey_feature();
    if (!pkeys_total)

Hello Aneesh,

I tested the new kernel today and unfortunately it doesn't run very well.

I have only one core (1 physical processor; 1 core; 2 threads) instead 
of two cores (1 physical processor; 2 cores; 2 threads) so the system is 
slower.

Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt

Could you please check the updates?

Thanks,
Christian


On 10 August 2020 at 09:56 am, Christian Zigotzky wrote:

Hello Aneesh,

The Nemo board boots with your patch but unfortunately I don't see any 
boot messages anymore.

Please find attached the kernel config.

Thanks,
Christian


On 09 August 2020 at 5:49 pm, Christian Zigotzky wrote:

quoted

Hello Aneesh,

Many thanks for your fast response and thanks a lot for your patch!
I will patch and compile a new git kernel tomorrow. I am looking 
forward to the result.

Have a nice day!

Cheers,
Christian

quoted

On 9. Aug 2020, at 17:11, Aneesh Kumar K.V 
[off-list ref] wrote:

"Aneesh Kumar K.V" [off-list ref] writes:

quoted

quoted

On 8/9/20 8:04 PM, Aneesh Kumar K.V wrote:
On 8/9/20 7:42 PM, Christian Zigotzky wrote:

quoted

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the
latest Git kernel anymore after the commit "powerpc/book3s64/pkeys:
Simplify pkey disable branch" [2].

I bisected today [3].

Result: powerpc/book3s64/pkeys: Simplify pkey disable branch
(a4678d4b477c3d2901f101986ca01406f3b7eaea) [2] is the first bad 
commit.

Unfortunately I wasn't able to revert the first bad commit. The 
first
bad commit depends on many other commits, which unfortunately I 
don't
know. I tried to remove the modifications of the files from the 
first
bad commit but without any success. There are just too many 
dependencies.

Additionally I reverted the commit "selftests/powerpc: Fix pkey
syscall redefinitions" [4] and compiled a new kernel but without any
success.

Could you please check the first bad commit?

Thanks,
Christian

Can you share a successful boot log of the system so that i can 
double
check the cpu_feature and mmu_feature reported ? I am looking for
details similar to below.

[    0.000000] cpu_features      = 0x0001c07f8f5f91a7
[    0.000000]   possible        = 0x0001fbffcf5fb1a7
[    0.000000]   always          = 0x00000003800081a1
[    0.000000] cpu_user_features = 0xdc0065c2 0xefe00000
[    0.000000] mmu_features      = 0x7c006001
[    0.000000] firmware_features = 0x0000001fc45bfc57
[    0.000000] vmalloc start     = 0xc008000000000000
[    0.000000] IO start          = 0xc00a000000000000
[    0.000000] vmemmap start     = 0xc00c000000000000


IIUC this is P5+? (ISA 2.04). On that pkey should be marked 
disabled via

static int scan_pkey_feature(void)
{
     int ret;
     int pkeys_total = 0;

     ....

     /*
      * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
      */
     if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
         return 0;


}

Can you boot with CONFIG_PPC_MEM_KEYS=n ?

Can you try this change on top of master?


modified   arch/powerpc/mm/book3s64/pkeys.c

@@ -215,10 +215,6 @@ void __init pkey_early_init_devtree(void)

      pr_info("Enabling pkeys with max key count %d\n", num_pkey);
  out:
-    /*
-     * Setup uamor on boot cpu
-     */
-    mtspr(SPRN_UAMOR, default_uamor);

      return;
  }

Full patch with better description.

commit 919a177bcdaf1eaeaeecc0d0f50a688629d7b5df
Author: Aneesh Kumar K.V [off-list ref]
Date:   Sun Aug 9 20:37:38 2020 +0530

    powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne 
X1000)

    On p6 and before we should avoid updating UAMOR SPRN. This resulted
    in boot failure on Nemo board.

    Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on 
POWER6 and before")
    Reported-by: Christian Zigotzky [off-list ref]
    Signed-off-by: Aneesh Kumar K.V [off-list ref]

diff --git a/arch/powerpc/mm/book3s64/pkeys.c 

b/arch/powerpc/mm/book3s64/pkeys.c
index 69a6b87f2bb4..b1d091a97611 100644

--- a/arch/powerpc/mm/book3s64/pkeys.c
+++ b/arch/powerpc/mm/book3s64/pkeys.c

@@ -73,12 +73,6 @@ static int scan_pkey_feature(void)

    if (early_radix_enabled())
        return 0;

-    /*
-     * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
-     */
-    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
-        return 0;
-
    ret = of_scan_flat_dt(dt_scan_storage_keys, &pkeys_total);
    if (ret == 0) {
        /*

@@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)

             __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
                != (sizeof(u64) * BITS_PER_BYTE));

+    /*
+     * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
+     */
+    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
+        return;
+
    /* scan the device tree for pkey feature */
    pkeys_total = scan_pkey_feature();
    if (!pkeys_total)

On 8/10/20 2:15 PM, Christian Zigotzky wrote:

Hello Aneesh,

I tested the new kernel today and unfortunately it doesn't run very well.

I have only one core (1 physical processor; 1 core; 2 threads) instead 
of two cores (1 physical processor; 2 cores; 2 threads) so the system is 
slower.

Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt

Could you please check the updates?

modified   arch/powerpc/mm/book3s64/hash_utils.c

@@ -1116,7 +1116,8 @@ void hash__early_init_mmu_secondary(void)
  		tlbiel_all();

  #ifdef CONFIG_PPC_MEM_KEYS
-	mtspr(SPRN_UAMOR, default_uamor);
+	if (mmu_has_feature(MMU_FTR_PKEY))
+		mtspr(SPRN_UAMOR, default_uamor);
  #endif
  }
  #endif /* CONFIG_SMP */



-aneesh

Am 10.08.20 um 10:58 schrieb Aneesh Kumar K.V:

Hello Aneesh,

Your modifications work! I have 2 cores again and I can see the boot 
messages.

Thanks a lot!

Cheers,
Christian

Hello,

Just for info. The latest git kernel doesn't work with a virtio_gpu anymore.

QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 
1024 -kernel uImage -drive 
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device 
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb 
-device usb-audio,bus=newusb.0 -smp 4

Error messages:

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc0000000000c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted 
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1
Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP:  c0000000000c7324 LR: c0000000000c72e4 CTR: c000000000462930
REGS: c00000003dba75e0 TRAP: 0300   Not tainted 
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)
MSR:  0000000090029000 <CE,EE,ME>  CR: 24002288  XER: 00000000
DEAR: 0000000000000010 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000000c6188 c00000003dba7870 c0000000017f2300 c00000003d893010
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 7f7f7f7f7f7f7f7f
GPR12: 0000000024002284 c00000003fff9200 c00000000008c3a0 c0000000061566c0
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000001 0000000000110000 0000000000000000 0000000000000000
GPR28: c00000003d893010 0000000000000000 0000000000000000 c00000003d893010
NIP [c0000000000c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c0000000000c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c00000003dba7870] [c00000003dba7950] 0xc00000003dba7950 (unreliable)
[c00000003dba7920] [c0000000000c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c00000003dba79d0] [c0000000005cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c00000003dba7a50] [c0000000006af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c00000003dba7ad0] [c0000000006ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c00000003dba7b40] [c0000000006adab8] 
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c
[c00000003dba7c10] [c000000000086b70] .process_one_work+0x1a4/0x258
[c00000003dba7cb0] [c0000000000870f4] .worker_thread+0x214/0x284
[c00000003dba7d70] [c00000000008c4f0] .kthread+0x150/0x158
[c00000003dba7e20] [c00000000000082c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e000000 7cfa3b78 3bc00000 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8 <e93d0010> ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 
(slots), used 0 (slots)

----

The kernel 5.8 works without any problems in this virtual machine.

Could you please check the latest updates?

Thanks,
Christian

Hello Daniel,

The VirtIO-GPU doesn't work anymore with the latest Git kernel in a 
virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio: 
Call the right shmem helpers". [3]
The kernel 5.8 works with the VirtIO-GPU in this virtual machine.

I bisected today [4].

Result: drm/virtio: Call the right shmem helpers ( 
d323bb44e4d23802eb25d13de1f93f2335bd60d0) [3] is the first bad commit.

I was able to revert the first bad commit. [5] After that I compiled a 
new kernel again. Then I was able to boot Linux with this kernel in a 
virtual e5500 PPC64 QEMU machine with the VirtIO-GPU.

I created a patch. [6] With this patch I can use the VirtIO-GPU again.

Could you please check the first bad commit?

Thanks,
Christian

[1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 
1024 -kernel uImage -drive 
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device 
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb 
-device usb-audio,bus=newusb.0 -smp 4

[2] Error messages:

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc0000000000c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted 
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1
Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP:  c0000000000c7324 LR: c0000000000c72e4 CTR: c000000000462930
REGS: c00000003dba75e0 TRAP: 0300   Not tainted 
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)
MSR:  0000000090029000 <CE,EE,ME>  CR: 24002288  XER: 00000000
DEAR: 0000000000000010 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000000c6188 c00000003dba7870 c0000000017f2300 c00000003d893010
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 7f7f7f7f7f7f7f7f
GPR12: 0000000024002284 c00000003fff9200 c00000000008c3a0 c0000000061566c0
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000001 0000000000110000 0000000000000000 0000000000000000
GPR28: c00000003d893010 0000000000000000 0000000000000000 c00000003d893010
NIP [c0000000000c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c0000000000c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c00000003dba7870] [c00000003dba7950] 0xc00000003dba7950 (unreliable)
[c00000003dba7920] [c0000000000c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c00000003dba79d0] [c0000000005cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c00000003dba7a50] [c0000000006af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c00000003dba7ad0] [c0000000006ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c00000003dba7b40] [c0000000006adab8] 
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c
[c00000003dba7c10] [c000000000086b70] .process_one_work+0x1a4/0x258
[c00000003dba7cb0] [c0000000000870f4] .worker_thread+0x214/0x284
[c00000003dba7d70] [c00000000008c4f0] .kthread+0x150/0x158
[c00000003dba7e20] [c00000000000082c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e000000 7cfa3b78 3bc00000 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8 <e93d0010> ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 
(slots), used 0 (slots)

---

[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d323bb44e4d23802eb25d13de1f93f2335bd60d0

[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=51377#p51377

[5] git revert d323bb44e4d23802eb25d13de1f93f2335bd60d0 //Output: 
[master 966950f724e4] Revert "drm/virtio: Call the right shmem helpers" 
1 file changed, 1 insertion(+), 1 deletion(-)

[6]

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 

b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01cd888..346cef5ce251 100644

--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c

@@ -150,7 +150,7 @@ static int virtio_gpu_object_shmem_init(struct 

virtio_gpu_device *vgdev,
      if (ret < 0)
          return -EINVAL;

-    shmem->pages = drm_gem_shmem_get_pages_sgt(&bo->base.base);
+    shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base);
      if (!shmem->pages) {
          drm_gem_shmem_unpin(&bo->base.base);
          return -EINVAL;
---

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the 
VirtIO-GPU (see below) still exists. Therefore we still need the patch 
(see below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.

Could you please check the first bad commit?

Thanks
Christian


On 12 August 2020 at 3:09 pm, Christian Zigotzky wrote:

On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.

It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).

Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
in turn should bring it to 5.9-rc2 or -rc3.

take care,
  Gerd

On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote:

Hello Gerd,

I compiled a new kernel with the latest DRM misc updates today. The patch is
included in these updates.

This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine
on my X5000.

Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with
a resolution of 640x480. If I set a higher resolution then the guest
disables the monitor.
I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.

Please check the latest DRM updates.

https://patchwork.freedesktop.org/patch/385980/

(tests & reviews & acks are welcome)

HTH,
  Gerd

On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote:

On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:

quoted

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.

It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).

Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
in turn should bring it to 5.9-rc2 or -rc3.

take care,
   Gerd

Hello Gerd,

I compiled a new kernel with the latest DRM misc updates today. The 
patch is included in these updates.

This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV 
machine on my X5000.

Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") 
with a resolution of 640x480. If I set a higher resolution then the 
guest disables the monitor.
I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.

Please check the latest DRM updates.

Thanks,
Christian

On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote:

On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:

quoted

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.

It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).

Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
in turn should bring it to 5.9-rc2 or -rc3.

take care,
   Gerd

Thank you!

On 19 August 2020 at 06:35 am, Gerd Hoffmann wrote:

On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote:

quoted

Hello Gerd,

I compiled a new kernel with the latest DRM misc updates today. The patch is
included in these updates.

This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine
on my X5000.

Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with
a resolution of 640x480. If I set a higher resolution then the guest
disables the monitor.
I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.

Please check the latest DRM updates.

https://patchwork.freedesktop.org/patch/385980/

(tests & reviews & acks are welcome)

HTH,
   Gerd

Hello Gerd,

I compiled a new RC1 with our patches today. With these patches, the 
VirtIO-GPU works without any problems. I can use higher resolutions again.

Screenshot of the RC1-3 with the VirtIO-GPU in a virtual e5500 QEMU/KVM 
HV machine on my X5000: 
https://i.pinimg.com/originals/4f/b0/14/4fb01476edd7abe6be1e1203a8e7e152.png

Thanks a lot for your help!

Cheers,
Christian