On Fri, Sep 6, 2024 at 12:56 AM Stefan Hajnoczi wrote:
>
> On Tue, Jul 16, 2024 at 10:21:35AM +0900, David Stevens wrote:
> > On Fri, Jul 12, 2024 at 2:47 PM Michael S. Tsirkin wrote:
> > >
> > > On Fri, Jul 12, 2024 at 11:06:49AM +0900, David Stevens wrote:
>
On Fri, Jul 12, 2024 at 2:47 PM Michael S. Tsirkin wrote:
>
> On Fri, Jul 12, 2024 at 11:06:49AM +0900, David Stevens wrote:
> > On Thu, Jul 11, 2024 at 7:56 PM Alyssa Ross wrote:
> > >
> > > Adding David Stevens, who implemented SHMEM_MAP and SHMEM_UNMAP in
>
On Thu, Jul 11, 2024 at 7:56 PM Alyssa Ross wrote:
>
> Adding David Stevens, who implemented SHMEM_MAP and SHMEM_UNMAP in
> crosvm a couple of years ago.
>
> David, I'd be particularly interested for your thoughts on the MEM_READ
> and MEM_WRITE commands, since as far a
Request for a vote.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/76
Thanks,
David
On Fri, Mar 20, 2020 at 3:41 PM Gerd Hoffmann wrote:
>
> On Thu, Mar 19, 2020 at 11:18:21AM +0900, David Stevens wrote:
> > Hi all,
> >
> > This is the next iteration of patche
Thanks for taking a look at this. I've opened a github issue.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/76
Thanks,
David
On Fri, Mar 20, 2020 at 3:41 PM Gerd Hoffmann wrote:
>
> On Thu, Mar 19, 2020 at 11:18:21AM +0900, David Stevens wrote:
> > Hi all,
> &g
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..e75aafa 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -35,6 +35,8 @@ \subsection{Feature bits}\label{sec:Device
Define a mechanism for sharing objects between different virtio
devices.
Signed-off-by: David Stevens
---
content.tex | 12
introduction.tex | 4
2 files changed, 16 insertions(+)
diff --git a/content.tex b/content.tex
index b1ea9b9..c8a367b 100644
--- a/content.tex
].
[1] https://markmail.org/thread/bfy6uk4q4v4cus7h
[2] https://markmail.org/message/wxdne5re7aaugbjg
Changes v3 -> v4:
- Add virtio-gpu feature bit
- Move virtio-gpu assign uuid command into 2d command group
- Rename virtio-gpu uuid response
David Stevens (2):
content: define what an expor
/wxdne5re7aaugbjg
Changes v2 -> v3:
* Replace references to guest/host
* Remove unnecessary paragraph and field in exported object section
* Recommend RFC4122 version 4 UUIDs
* Represent UUID as u8[16] instead of le64 pair
David Stevens (2):
content: define what an exported object is
virtio-gpu: add
Define a mechanism for sharing objects between different virtio
devices.
Signed-off-by: David Stevens
---
content.tex | 12
introduction.tex | 4
2 files changed, 16 insertions(+)
diff --git a/content.tex b/content.tex
index b1ea9b9..ad3723c 100644
--- a/content.tex
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..e950ad3 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -186,12 +186,16 @@ \subsubsection{Device Operation
> 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 be
> > +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 concre
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
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
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
>
> 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
typ
> 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 te
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
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 m
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
> > > 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 virtio-gp
> > > 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:
> > > >>
> > >
> 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 necessarily
> (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 woul
"Michael S. Tsirkin" wrote on 05/09/2010 09:42:09 AM:
> After migration, vhost was not getting features
> acked because set_features callback was never invoked.
> The fix is just to invoke that callback.
>
> Reported-by: David L Stevens
> Signed-off-by: Michael S. Tsirkin
> ---
>
> David, a t
30 matches
Mail list logo
