Hi,
As Pekka mentionned, I'd also like to have a conversation of how far we want to push virtualized driver features. I think KMS support is a good feature to have to spin up a VM and have all of the basics working. However I don't think it's a good idea to try to plumb an ever-growing list of fancy features (seamless integration of guest windows into the host, HiDPI, multi-monitor, etc) into KMS. You'd just end up re-inventing Wayland or RDP on top of KMS. Instead of re-inventing these, just use RDP or waypipe or X11 forwarding directly.
So I think we need to draw a line somewhere, and decide e.g. that virtualized cursors are fine to add in KMS, but HiDPI is not.
What is the problem with HiDPI? qemu generates standard edid blobs, there should be no need to special-case virtualized drivers in any way.
What is the problem with multi-monitor? That isn't much different than physical multi-monitor either.
One little thing though: On physical hardware you just don't know which monitor is left and which is right until the user tells you. In case of a virtual multi-monitor setup we know how the two windows for the two virtual monitors are arranged on the host and can pass that as hint to the guest (not sure whenever *that* is the purpose of the suggested_{x,y} properties).
It's getting a bit far off-topic, but google cros team has an out-of-tree (at least I think it's not merged yet) wayland-virtio driver for exactly this use-case. Trying to move towards something like that for fancy virtualized setups sounds like the better approach indeed, with kms just as the bare-bones fallback option.
virtio-gpu got the ability to attach uuids to objects, to allow them being identified on the host side. So it could be that wayland-virtio still uses kms for framebuffers (disclaimer: don't know how wayland-virtio works in detail). But, yes, all the scanout + cursor handling would be out of the way, virtio-gpu would "only" handle fast buffer sharing.
take care, Gerd