From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Cc: linux-kernel@vger.kernel.org, Zach Reizner <zachr@google.com>,
kernel@collabora.com, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
David Airlie <airlied@linux.ie>, Jason Wang <jasowang@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support
Date: Wed, 7 Feb 2018 08:41:47 +0100 [thread overview]
Message-ID: <1b7ff044-23c8-1bf7-004e-dd6ea1a7006e@collabora.com> (raw)
In-Reply-To: <20180207030636-mutt-send-email-mst@kernel.org>
On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote:
> On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
>>> Creation of shareable buffer by guest
>>> -------------------------------------------------
>>>
>>> 1. Client requests virtio driver to create a buffer suitable for sharing
>>> with host (DRM_VIRTGPU_RESOURCE_CREATE)
>>
>> client or guest proxy?
>>
>>> 4. QEMU maps that buffer to the guest's address space
>>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
>>
>> That part is problematic. The host can't simply allocate something in
>> the physical address space, because most physical address space
>> management is done by the guest. All pci bars are mapped by the guest
>> firmware for example (or by the guest OS in case of hotplug).
>>
>>> 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
>>> resource, sends data + FDs to the compositor with SCM_RIGHTS
>
> If you squint hard, this sounds a bit like a use-case for vhost-user-gpu, does it not?
Can you extend on what makes you think that?
As an aside, crosvm runs the virtio-gpu device in a separate, jailed
process, among other virtual devices.
https://chromium.googlesource.com/chromiumos/platform/crosvm/
Regards,
Tomeu
WARNING: multiple messages have this Message-ID (diff)
From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Cc: David Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
Zach Reizner <zachr@google.com>,
kernel@collabora.com
Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support
Date: Wed, 7 Feb 2018 08:41:47 +0100 [thread overview]
Message-ID: <1b7ff044-23c8-1bf7-004e-dd6ea1a7006e@collabora.com> (raw)
In-Reply-To: <20180207030636-mutt-send-email-mst@kernel.org>
On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote:
> On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
>>> Creation of shareable buffer by guest
>>> -------------------------------------------------
>>>
>>> 1. Client requests virtio driver to create a buffer suitable for sharing
>>> with host (DRM_VIRTGPU_RESOURCE_CREATE)
>>
>> client or guest proxy?
>>
>>> 4. QEMU maps that buffer to the guest's address space
>>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
>>
>> That part is problematic. The host can't simply allocate something in
>> the physical address space, because most physical address space
>> management is done by the guest. All pci bars are mapped by the guest
>> firmware for example (or by the guest OS in case of hotplug).
>>
>>> 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
>>> resource, sends data + FDs to the compositor with SCM_RIGHTS
>
> If you squint hard, this sounds a bit like a use-case for vhost-user-gpu, does it not?
Can you extend on what makes you think that?
As an aside, crosvm runs the virtio-gpu device in a separate, jailed
process, among other virtual devices.
https://chromium.googlesource.com/chromiumos/platform/crosvm/
Regards,
Tomeu
next prev parent reply other threads:[~2018-02-07 7:41 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 13:58 [PATCH v3 0/2] drm/virtio: Add window server support Tomeu Vizoso
2018-01-26 13:58 ` Tomeu Vizoso
2018-01-26 13:58 ` [PATCH v3 1/2] " Tomeu Vizoso
2018-01-26 13:58 ` Tomeu Vizoso
2018-02-01 16:36 ` Gerd Hoffmann
2018-02-01 16:36 ` Gerd Hoffmann
2018-02-05 8:19 ` Tomeu Vizoso
2018-02-05 8:19 ` Tomeu Vizoso
2018-02-05 8:19 ` Tomeu Vizoso
2018-02-05 12:20 ` Gerd Hoffmann
2018-02-05 14:46 ` Tomeu Vizoso
2018-02-05 14:46 ` Tomeu Vizoso
2018-02-05 16:03 ` Gerd Hoffmann
2018-02-05 16:03 ` Gerd Hoffmann
2018-02-06 12:41 ` Tomeu Vizoso
2018-02-06 12:41 ` Tomeu Vizoso
2018-02-06 14:23 ` Gerd Hoffmann
2018-02-06 14:23 ` Gerd Hoffmann
2018-02-07 1:09 ` Michael S. Tsirkin
2018-02-07 7:41 ` Tomeu Vizoso [this message]
2018-02-07 7:41 ` Tomeu Vizoso
2018-02-07 1:09 ` Michael S. Tsirkin
2018-02-07 9:49 ` Tomeu Vizoso
2018-02-07 9:49 ` Tomeu Vizoso
2018-02-09 11:14 ` Tomeu Vizoso
2018-02-09 11:14 ` Tomeu Vizoso
2018-02-12 11:52 ` Gerd Hoffmann
2018-02-12 11:52 ` Gerd Hoffmann
2018-02-12 14:00 ` Tomeu Vizoso
2018-02-12 14:00 ` Tomeu Vizoso
2018-02-12 14:00 ` Tomeu Vizoso
2018-02-12 14:27 ` Gerd Hoffmann
2018-02-12 14:27 ` Gerd Hoffmann
2018-02-12 14:42 ` Tomeu Vizoso
2018-02-12 14:42 ` Tomeu Vizoso
2018-02-12 15:29 ` Gerd Hoffmann
2018-02-12 15:29 ` Gerd Hoffmann
2018-02-12 15:29 ` Gerd Hoffmann
2018-02-12 14:42 ` Tomeu Vizoso
2018-02-12 11:45 ` Gerd Hoffmann
2018-02-12 11:45 ` Gerd Hoffmann
2018-02-12 11:45 ` Gerd Hoffmann
2018-02-13 7:41 ` Pekka Paalanen
2018-02-13 7:41 ` Pekka Paalanen
2018-02-13 7:41 ` Pekka Paalanen
2018-02-13 14:27 ` Tomeu Vizoso
2018-02-13 14:27 ` Tomeu Vizoso
2018-02-16 10:48 ` Gerd Hoffmann
2018-02-16 10:48 ` Gerd Hoffmann
2018-02-16 10:48 ` Gerd Hoffmann
2018-02-13 14:27 ` Tomeu Vizoso
2018-02-15 15:28 ` Tomeu Vizoso
2018-02-15 15:28 ` Tomeu Vizoso
2018-02-15 15:28 ` Tomeu Vizoso
2018-02-06 14:23 ` Gerd Hoffmann
2018-02-06 12:41 ` Tomeu Vizoso
2018-02-06 15:00 ` Pekka Paalanen
2018-02-06 15:00 ` Pekka Paalanen
2018-02-06 15:00 ` Pekka Paalanen
2018-02-05 16:03 ` Gerd Hoffmann
2018-02-05 14:46 ` Tomeu Vizoso
2018-02-05 12:20 ` Gerd Hoffmann
2019-03-18 12:47 ` Tomeu Vizoso
2019-03-18 12:47 ` Tomeu Vizoso
2019-03-18 12:47 ` Tomeu Vizoso
2018-01-26 13:58 ` [PATCH v3 2/2] drm/virtio: Handle buffers from the compositor Tomeu Vizoso
2018-01-26 13:58 ` Tomeu Vizoso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b7ff044-23c8-1bf7-004e-dd6ea1a7006e@collabora.com \
--to=tomeu.vizoso@collabora.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=jasowang@redhat.com \
--cc=kernel@collabora.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=stefanha@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=zachr@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.