[Qemu-devel] vexpress: Framebuffer broken with KVM enabled

[Qemu-devel] vexpress: Framebuffer broken with KVM enabled

[Jan Kiszka]

Hi,

next issue related to KVM/QEMU on the TK1: The guest image I'm running
gives proper framebuffer output when in emulation mode. Once KVM is
enabled, the screen is - at best - only initially updated. Sometimes I
see the famous tux images and a bit of the console texts, but usually it
stays black. Explanations?

Jan

Re: [Qemu-devel] vexpress: Framebuffer broken with KVM enabled

[Anup Patel]

On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> Hi,
>
> next issue related to KVM/QEMU on the TK1: The guest image I'm running
> gives proper framebuffer output when in emulation mode. Once KVM is
> enabled, the screen is - at best - only initially updated. Sometimes I
> see the famous tux images and a bit of the console texts, but usually it
> stays black. Explanations?

The QEMU accesses Guest Video RAM (or any portion of Guest RAM) as
cacheable user space memory. The Guest Kernel might access Guest Video
RAM as non-cacheable to maintain coherency with video device. If this is
the case then all updates by Guest kernel to Guest Video RAM will not
be visible to QEMU.

--
Anup

>
> Jan
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [Qemu-devel] vexpress: Framebuffer broken with KVM enabled

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On 2015-02-16 10:20, Anup Patel wrote:
> On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Hi,
>>
>> next issue related to KVM/QEMU on the TK1: The guest image I'm running
>> gives proper framebuffer output when in emulation mode. Once KVM is
>> enabled, the screen is - at best - only initially updated. Sometimes I
>> see the famous tux images and a bit of the console texts, but usually it
>> stays black. Explanations?
> 
> The QEMU accesses Guest Video RAM (or any portion of Guest RAM) as
> cacheable user space memory. The Guest Kernel might access Guest Video
> RAM as non-cacheable to maintain coherency with video device. If this is
> the case then all updates by Guest kernel to Guest Video RAM will not
> be visible to QEMU.

On x86, we manage such RAM as coalesced MMIO region, sync'ing it
periodically or on specific register accesses into the video card model.
I suppose there is nothing like this for the pl111 yet, right?

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Qemu-devel] vexpress: Framebuffer broken with KVM enabled

[Alexander Spyridakis]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> Hi,
>
> next issue related to KVM/QEMU on the TK1: The guest image I'm running
> gives proper framebuffer output when in emulation mode. Once KVM is
> enabled, the screen is - at best - only initially updated. Sometimes I
> see the famous tux images and a bit of the console texts, but usually it
> stays black. Explanations?

Hello Jan,

If you want to force rendering, you can do something similar with the
following hack:
https://github.com/virtualopensystems/qemu/commit/64dd1b3e3a2353433edb9c63d00271f515bd06fb

Of course expect performance to not be up to par.

Best regards.

[-- Attachment #2: Type: text/html, Size: 1139 bytes --]

Re: [Qemu-devel] vexpress: Framebuffer broken with KVM enabled

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On 2015-02-16 10:34, Alexander Spyridakis wrote:
> On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Hi,
>>
>> next issue related to KVM/QEMU on the TK1: The guest image I'm running
>> gives proper framebuffer output when in emulation mode. Once KVM is
>> enabled, the screen is - at best - only initially updated. Sometimes I
>> see the famous tux images and a bit of the console texts, but usually it
>> stays black. Explanations?
> 
> Hello Jan,
> 
> If you want to force rendering, you can do something similar with the
> following hack:
> https://github.com/virtualopensystems/qemu/commit/64dd1b3e3a2353433edb9c63d00271f515bd06fb
> 
> Of course expect performance to not be up to par.

Yep, confirmed - both that it works and that it's slow (better not try
this with SDL, exported via X...).

Thanks,
Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]