On Wed, Feb 28, 2024 at 3:45 PM Zhu, Lingshan wrote:
> On 2/28/2024 9:18 AM, David Stevens wrote:
> > On Tue, Feb 27, 2024 at 5:52 PM Zhu, Lingshan
> > wrote:
> >> On 2/27/2024 3:59 PM, David Stevens wrote:
> >>> On Tue, Feb 27, 2024 at 11:22 AM Zhu, Lingsha
On Tue, Feb 27, 2024 at 5:52 PM Zhu, Lingshan wrote:
> On 2/27/2024 3:59 PM, David Stevens wrote:
> > On Tue, Feb 27, 2024 at 11:22 AM Zhu, Lingshan
> > wrote:
> >> On 2/27/2024 9:53 AM, David Stevens wrote:
> >>> Add a SUSPEND bit to the device stat
On Tue, Feb 27, 2024 at 11:22 AM Zhu, Lingshan wrote:
> On 2/27/2024 9:53 AM, David Stevens wrote:
> > Add a SUSPEND bit to the device status field to allow drivers to suspend
> > virtio devices. On systems where drivers don't directly manage interrupt
> > routing (e.g
Add a SUSPEND bit to the device status field to allow drivers to suspend
virtio devices. On systems where drivers don't directly manage interrupt
routing (e.g. Linux), this allows the drivers to suspend their devices
and prevent interrupts from being sent when the interrupt routing system
does not
nction with PCI power management.
v2 -> v3:
- Use different words for some concepts to avoid conflicts with other
parts of the spec.
- Rewrite various sentences to improve clarity.
v1 -> v2:
- Define virtio-pci support on top of PCI power management.
- Add more conformance requirements.
D
On Mon, Feb 26, 2024 at 3:42 PM Jason Wang wrote:
>
> On Fri, Feb 16, 2024 at 4:25 PM David Stevens wrote:
> >
> > Add a virtio power management PCI capability to allow drivers to suspend
> > virtio PCI devices. This allows drivers to suspend devices at the virtio
>
On Mon, Feb 26, 2024 at 10:36 AM Zhu, Lingshan wrote:
> On 2/25/2024 4:52 PM, Michael S. Tsirkin wrote:
> > On Fri, Feb 23, 2024 at 03:44:41PM +0800, Zhu, Lingshan wrote:
> >>
> >> On 2/20/2024 1:09 PM, David Stevens wrote:
> >>> On Tue, Feb 20, 2024
On Tue, Feb 20, 2024 at 1:06 PM Zhu, Lingshan wrote:
> On 2/19/2024 2:46 PM, David Stevens wrote:
> > On Sun, Feb 18, 2024 at 11:11 PM Michael S. Tsirkin wrote:
> >> On Sun, Feb 18, 2024 at 09:23:06PM +0800, Zhu Lingshan wrote:
> >>> This commit allows th
On Fri, Feb 16, 2024 at 5:56 PM Michael S. Tsirkin wrote:
>
> On Fri, Feb 16, 2024 at 05:24:32PM +0900, David Stevens wrote:
> > Add a virtio power management PCI capability to allow drivers to suspend
> > virtio PCI devices. This allows drivers to suspend devices at the virti
genio Pérez
>
> Could we get some kind of dscription how this has taken into
> consideration the proposal from David Stevens?
>
> I find it really tiring when there are competing patches with authors
> ignoring each other's work and leaving it up to reviewers to
> figure out how do the patc
Add a virtio power management PCI capability to allow drivers to suspend
virtio PCI devices. This allows drivers to suspend devices at the virtio
level before suspending them at the PCI transport layer. This allows
drivers to do a two phase suspend, which prevents notifications from
being ignored
- Use different words for some concepts to avoid conflicts with other
parts of the spec.
- Rewrite various sentences to improve clarity.
v1 -> v2:
- Define virtio-pci support on top of PCI power management.
- Add more conformance requirements.
David Stevens (1):
Add suspend support for v
On Thu, Dec 7, 2023 at 1:16 PM Jason Wang wrote:
>
> On Wed, Dec 6, 2023 at 6:17 PM Michael S. Tsirkin wrote:
> >
> > On Wed, Dec 06, 2023 at 05:16:04PM +0800, Jason Wang wrote:
> > > On Tue, Dec 5, 2023 at 6:58 PM David Stevens
> > > wrote:
> > > &
On Tue, Dec 5, 2023 at 1:18 PM Jason Wang wrote:
>
> On Mon, Dec 4, 2023 at 5:41 PM David Stevens wrote:
> >
> > Define a low power mode for virtio devices where the devices are
> > expected to maintain their state. This gives drivers an option for power
> > manag
Define a low power mode for virtio devices where the devices are
expected to maintain their state. This gives drivers an option for power
management besides simply resetting their device. In the virtualization
use case, this allows the guest to be suspended even with stateful
virtio devices like
cts with other
parts of the spec.
- Rewrite various sentences to improve clarity.
v1 -> v2:
- Define virtio-pci support on top of PCI power management.
- Add more conformance requirements.
David Stevens (1):
Define a low power mode for devices
content.tex
On Mon, Nov 13, 2023 at 3:20 PM David Stevens wrote:
>
> The virtio spec currently does not include the concept of device power
> management. The lack means that there is no good action drivers can take
> when they are requested to put the device into a low power state (e.g.
&g
ent.
- Add more conformance requirements.
David Stevens (1):
Define a low power mode for devices
content.tex | 45 +
transport-pci.tex | 7 +++
2 files changed, 52 insertions(+)
--
2.42.0.869.gea05f2083d-g
Define a low power mode for virtio devices where the devices are
expected to maintain their state. This gives drivers an option for power
management besides simply resetting their device. In the virtualization
use case, this allows the guest to be suspended even with stateful
virtio devices like
Reported-by: kernel test robot
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/Kconfig | 1 +
drivers/virtio/Kconfig | 7 +++
drivers/virtio/Makefile | 3 ++-
drivers/virtio/virtio_dma_buf.c | 3 +++
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 21
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v6 -> v7 changes:
- Fix most strict checkpatch comments
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
> Hmm, checkpatch still complains, full log below.
>
> IIRC "dim checkpatch" runs scripts/checkpatch.pl with --strict
> so it is a bit more picky ...
Ah, I didn't know --strict was being used. I'll send an update
momentarily. Sorry for the churn.
> -:250: CHECK:PREFER_KERNEL_TYPES: Prefer kernel
On Mon, Aug 17, 2020 at 4:12 AM Gerd Hoffmann wrote:
>
> On Mon, Aug 17, 2020 at 12:50:08PM +0200, Gerd Hoffmann wrote:
> > On Tue, Jun 23, 2020 at 10:31:28AM +0900, David Stevens wrote:
> > > Unless there are any remaining objections to these patches, what are
> &g
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v5 -> v6 changes:
- Fix >80 character comment
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virtgpu ex
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 20
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
10:25:15AM +0900, David Stevens wrote:
> > This patchset implements the current proposal for virtio cross-device
> > resource sharing [1]. It will be used to import virtio resources into
> > the virtio-video driver currently under discussion [2]. The patch
> > unde
On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski
wrote:
>
> Hi Michael,
>
> On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > This change adds a new flavor of dma-bufs
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 20
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v4 -> v5 changes:
- Remove virtio_dma_buf_export_info.
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin wrote:
>
> On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote:
> > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > > > + vgdev
On Mon, Jun 8, 2020 at 6:05 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 08, 2020 at 05:32:26PM +0900, David Stevens wrote:
> > On Mon, Jun 8, 2020 at 3:00 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
>
On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
>
> On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> > On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
> > >
> > > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
>
> On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 20
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
ted
requirement that get_uuid only be called on attached virtio
dma-bufs is also removed.
- Rebase and add call to virtio_gpu_notify for ASSIGN_UUID.
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
> > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > + vgdev->has_resource_assign_uuid = true;
> > + }
>
>
> Just a question: this relies on DMA bufs so I assume it is
> not really assumed to work when DMA API is bypassed, right?
> Rather than worry what
On Thu, May 14, 2020 at 9:30 PM Daniel Vetter wrote:
> On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> > Sorry for the duplicate reply, didn't notice this until now.
> >
> > > Just storing
> > > the uuid should be doable (assuming this doesn't
Sorry for the duplicate reply, didn't notice this until now.
> Just storing
> the uuid should be doable (assuming this doesn't change during the
> lifetime of the buffer), so no need for a callback.
Directly storing the uuid doesn't work that well because of
synchronization issues. The uuid
On Thu, May 14, 2020 at 12:45 AM Daniel Vetter wrote:
> On Wed, Mar 11, 2020 at 12:20 PM David Stevens wrote:
> >
> > This change adds a new dma-buf operation that allows dma-bufs to be used
> > by virtio drivers to share exported objects. The new operation allows
>
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 23 +++
include/drm/drm_drv.h | 10 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h | 18
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
ify virtgpu_gem_prime_export as it can only be called once.
- Use virtio_gpu_vbuffer's objs field instead of abusing data_buf.
David Stevens (4):
dma-buf: add support for virtio exported objects
drm/prime: add support for virtio exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feat
On Wed, Mar 4, 2020 at 5:01 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > + if (vgdev->has_resource_assign_uuid) {
> > + spin_lock(>resource_export_lock);
> > + if (bo->uuid_state == UUID_NOT_INITIALIZED) {
> > + bo->uuid_state = UUID_INITIALIZING;
> > +
> cmd_p->hdr.ctx_id =
>
> Before this completion of this hypercall, this resource can be
> considered context local, while afterward it can be considered
> "exported".
Maybe I'm misunderstanding render contexts, but exporting a resource
doesn't seem related to render contexts. The other resource
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h | 19
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 27 +++
include/drm/drm_drv.h | 15 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b
ack into main dma-buf ops (instead of placing it
in a new flavor of dma-buf).
- Rename new virtio commands and feature flag, and pull uapi changes
into their own patch.
David Stevens (4):
dma-buf: add support for virtio exported objects
drm/prime: add support for virtio exported objects
virtio-
On Fri, Feb 28, 2020 at 7:30 PM Gerd Hoffmann wrote:
>
> On Fri, Feb 28, 2020 at 07:11:40PM +0900, David Stevens wrote:
> > > But there also is "unix socket", or maybe a somewhat broader "stream",
> > > which would be another feature flag I gues
> > > Yes, sure, we need to exactly specify the different kinds of file
> > > handles / resources. I think it makes sense to have a virtio feature
> > > flag for each of them, so guest+host can easily negotiate what they are
> > > able to handle and what not.
> >
> > I was expecting that to be a
On Thu, Feb 27, 2020 at 6:09 PM Boris Brezillon
wrote:
>
> On Thu, 27 Feb 2020 13:20:51 +0900
> David Stevens wrote:
>
> > > * manage a central UUID <-> 'struct file' map that allows virtio-pipe
> > > to convert FDs to UUIDs, pass UUIDs through a pipe
> * manage a central UUID <-> 'struct file' map that allows virtio-pipe
> to convert FDs to UUIDs, pass UUIDs through a pipe and convert those
> UUIDs back to FDs on the other end
> - we need to expose an API to let each subsystem register/unregister
> their UUID <-> FD mapping
On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann wrote:
>
> On Wed, Feb 19, 2020 at 05:06:36PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
> >
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
/p5d3k566srtdtute
David Stevens (2):
virtio: add dma-buf support for exported objects
drm/virtio: Support virtgpu exported resources
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 21 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 4 +
drivers/gpu/drm/virtio
Add support for exported resources to virtgpu. This includes adding
support for the new virtgpu command as well as well as switching from
regular prime dma-bufs to virtio dma-bufs.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio
> > > FD <-> VFD mappings would have to be created
> > > by the subsystem in charge of the object backing the FD (virtio-gpu for
> > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix
> > > sockets if we decide to bridge unix and vsock sockets to make it
> > > transparent, ...).
> FD <-> VFD mappings would have to be created
> by the subsystem in charge of the object backing the FD (virtio-gpu for
> exported GEM buffers, virtio-vdec for video buffers, vsock for unix
> sockets if we decide to bridge unix and vsock sockets to make it
> transparent, ...). The FD <-> VFD
> ok but how is this then used? will there be more commands to pass
> this uuid to another device?
This is intended to be used with the virtio video device being
discussed here https://markmail.org/thread/ingyqlps4rbcuazh. I don't
have a specific patch for how that will work, but it will likely
> > +When an object created by one virtio device needs to be
> > +shared with a seperate virtio device, the first device can
> > +export the object by generating a \field{uuid}
>
> This is a field where?
It's a property of the exported object, but I guess it doesn't really
correspond to any
to memcpy decoded frames through the
guest.
[1] https://markmail.org/thread/jeh5xjjxvylyrbur
[2] https://markmail.org/thread/yb25fim2dqfuktgf
Changes v1 -> v2:
Rename exported resource to exported object
Rename the virtio-gpu export command
David Stevens (2):
content: define what an expor
Signed-off-by: David Stevens
---
virtio-gpu.tex | 30 ++
1 file changed, 30 insertions(+)
diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index af4ca61..a1f0210 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -186,12 +186,16 @@ \subsubsection{Device Operation
Define a mechanism for sharing objects between different virtio
devices.
Signed-off-by: David Stevens
---
content.tex | 18 ++
1 file changed, 18 insertions(+)
diff --git a/content.tex b/content.tex
index b1ea9b9..6c6dd59 100644
--- a/content.tex
+++ b/content.tex
@@ -373,6
> > that isn't just a leaf node of the spec. I think it's better to define
> > 'resource' as a top level concept for virtio devices, even if the specifics
> > of what a 'resource' is are defined by individual device types.
>
> Your patch doesn't define what a resource is though. It only refers to
> Is there a specific reason why you want the host pick the uuid? I would
> let the guest define the uuid, i.e. move the uuid fields to
> virtio_gpu_export_resource and scratch virtio_gpu_resp_export_resource.
Sending the uuid in the original request doesn't really buy us
anything, at least in
>
> Hmm, I'd suggest to move the whole thing into the virtio-gpu section.
> There is no such thing as a "resource" in general virtio context ...
>
If this is moved into the virtio-gpu section, then any device type that
imports resources will have to refer to something defined by the GPU device
Define a mechanism for sharing resources between different virtio
devices.
Signed-off-by: David Stevens
---
content.tex | 18 ++
1 file changed, 18 insertions(+)
diff --git a/content.tex b/content.tex
index b1ea9b9..73bd28e 100644
--- a/content.tex
+++ b/content.tex
@@ -373,6
Signed-off-by: David Stevens
---
virtio-gpu.tex | 29 +
1 file changed, 29 insertions(+)
diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index af4ca61..522f478 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -186,12 +186,16 @@ \subsubsection{Device Operation
This RFC comes from the recent discussion on buffer sharing [1],
specifically about the need to share resources between different
virtio devices. For a concrete use case, this can be used to share
virtio-gpu allocated buffers with the recently proposed virtio video
device [2], without the need to
> > > Of course only virtio drivers would try step (2), other drivers (when
> > > sharing buffers between intel gvt device and virtio-gpu for example)
> > > would go straight to (3).
> >
> > For virtio-gpu as it is today, it's not clear to me that they're
> > equivalent. As I read it, the
> > > Without buffer sharing support the driver importing a virtio-gpu dma-buf
> > > can send the buffer scatter list to the host. So both virtio-gpu and
> > > the other device would actually access the same guest pages, but they
> > > are not aware that the buffer is shared between devices.
> >
> > > Second I think it is a bad idea
> > > from the security point of view. When explicitly exporting buffers it
> > > is easy to restrict access to the actual exports.
> >
> > Restricting access to actual exports could perhaps help catch bugs.
> > However, I don't think it provides any security
> First the addressing is non-trivial, especially with the "transport
> specific device address" in the tuple.
There is complexity here, but I think it would also be present in the
buffer sharing device case. With a buffer sharing device, the same
identifying information would need to be provided
> > On 2019-11-20 23:13, Tomasz Figa wrote:
> > > > Hi Geoffrey,
> > > >
> > > > On Thu, Nov 7, 2019 at 7:28 AM Geoffrey McRae
> > > > wrote:
> > > >>
> > > >>
> > > >>
> &g
> My question would be "what is the actual problem you are trying to
> solve?".
One problem that needs to be solved is sharing buffers between
devices. With the out-of-tree Wayland device, to share virtio-gpu
buffers we've been using the virtio resource id. However, that
approach isn't
> (1) The virtio device
> =
>
> Has a single virtio queue, so the guest can send commands to register
> and unregister buffers. Buffers are allocated in guest ram. Each buffer
> has a list of memory ranges for the data. Each buffer also has some
Allocating from guest ram
races between the virtio-gpu device registering the buffer
with the guest dma address (which happens with the ATTACH_BACKING
command) and other virtio devices using the guest dma address as a
buffer identifier. I've included a patch that adds this
synchronization.
Signed-off-by: David Stevens
---
drive
89 matches
Mail list logo
