On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote:
On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote:
On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote:
On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini sylphrenadin@gmail.com wrote:
Add a virtual hardware or vblank-less mode as a module to enable VKMS to emulate virtual graphic drivers. This mode can be enabled by setting enable_virtual_hw=1 at the time of loading VKMS.
A new function vkms_crtc_composer() has been added to bypass the vblank mode and is called directly in the atomic hook in vkms_atomic_begin(). However, some crc captures still use vblanks which causes the crc-based igt tests to crash. Currently, I am unsure about how to approach one-shot implementation of crc reads so I am still working on that.
Gerd, Zack: For virtual hw like virtio-gpu or vmwgfx that does one-shot upload and damage tracking, what do you think is the best way to capture crc for validation? Assuming that's even on the plans anywhere ...
Ideally it'd be a crc that the host side captures, so that we really have end-to-end validation, including the damage uploads and all that.
Disclaimer: Not knowing much about the crc thing beside having noticed it exists and seems to be used for display content checking.
For vkms we're going for now with one-shot crc generation after each atomic flip (or DIRTYFB ioctl call). Will need a pile of igt changes, but seems like the most fitting model. Other option would be that we'd wire up something on the kernel side that generates a crc on-demand every time igt reads a new crc value (maybe with some rate limiting). But that's not really how virtual hw works when everything is pushed explicitly to the host side.
igt runs inside the guest, right?
Yup. There's some debugfs files for capture crc on a specific CRTC. So supporting this would mean some virtio-gpu revision so you could ask the host side for a crc when you do a screen update, and the host side would send that back to you on a virtio channel as some kind of message.
Waded through the source code a bit. So, the vkms crc code merges all planes (specifically the cursor plane) before calculating the crc. Which is a bit of a problem, we try to avoid that and rarely actually merge the planes anywhere in the virtualization stack. Instead we prefer to pass through the cursor plane separately, so we can -- for example -- use that to simply set the cursor sprite of the qemu gtk window. It's much more snappy because moving+rendering the pointer doesn't need a round-trip to the guest then.
So, it would be quite some effort on the host side, we would have to merge planes just for crc calculation.
You can ask qemu to write out a screen dump.
Hmm, the (hardware) cursor is not in the screen dump either.
A software cursor (when using for example cirrus which has no cursor plane) would be there.
Another option to access the screen would be vnc.
vnc clients can get the cursor sprite. They can't get the position though, only set it (it's a one-way ticket in the vnc protocol). Typically not a problem because desktops set the position in response to the pointer events so guest + host position match nevertheless. But for test cases which don't look at input events and set the cursor to a fixed place this is a problem ...
On-demand crc via debugfs or ioctl would work too, but yes that wouldn't verify the host-side. At least not without virtio protocol extensions. We could add a new command asking the host to crc the display and return the result for on-demand crc. Or add a crc request flag to an existing command (VIRTIO_GPU_CMD_RESOURCE_FLUSH probably).
Yup, I think that's what would be needed. The question here is, what do you think would be the most natural way for virtio host side stack to support this?
virtio has feature flags, so we can easily introduce an extension in a backward compatible way. Each command sends a reply, with optional payload, so it would make sense to send the crc with the VIRTIO_GPU_CMD_RESOURCE_FLUSH reply.
Alternatively introduce a communication channel independent of the gpu, using for example virtio-serial or vsock, let the guest send crc requests to qemu that way. Which would work with all qemu display devices, not only virtio-gpu.
take care, Gerd