Re: [virtio-dev] [PATCH] virtio-gpu: add shared resource feature

2019-11-28 Thread Gerd Hoffmann
On Thu, Nov 28, 2019 at 07:04:23PM +0100, Matti Moell wrote:
> Hi Gerd,
> 
> I really like this!
> 
> On 28.11.19 14:19, Gerd Hoffmann wrote:
> > @@ -186,6 +211,7 @@ \subsubsection{Device Operation: Request 
> > header}\label{sec:Device Types / GPU De
> >   VIRTIO_GPU_CMD_GET_CAPSET_INFO,
> >   VIRTIO_GPU_CMD_GET_CAPSET,
> >   VIRTIO_GPU_CMD_GET_EDID,
> > +VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED,
> Shouldn't there also the RESOURCE_CREATE_3D_SHARED? I know that 3D isn't
> speced here but it looks awkward not to reserve it.

Yep, none of the 3D commands is in the specs, thats why
RESOURCE_CREATE_3D_SHARED isn't there too (but, yes, it exists).

Guess it might be a good idea to at least list the commands,
but that is something for a separate patch ...

cheers,
  Gerd


-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org



Re: [virtio-dev] [PATCH] virtio-gpu: add shared resource feature

2019-11-28 Thread Laszlo Ersek
On 11/28/19 14:19, Gerd Hoffmann wrote:

> +resources.  Normal resources have both a guest buffer and host buffer
> +buffer for the resource and the VIRTIO_GPU_CMD_TRANSFER_* commands are

typo: "buffer\nbuffer"

Thanks
Laszlo


-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org



[virtio-dev] Re: [virtio] [PATCH v2] virtio_pci_cap64: bar/BAR cleanups

2019-11-28 Thread Cornelia Huck
On Wed, 27 Nov 2019 16:33:07 -0500
"Michael S. Tsirkin"  wrote:

> When we mean PCI register we should say BAR.
> When we mean a virtio config register we should say \field{cap.bar}.
> 
> Finally, offset_hi/length_hi are not within the cap structure.
> 
> Tweak wording slightly: "A,B,C" are fields, there's no need
> to say that.
> 
> Reported-by: Christophe de Dinechin 
> Signed-off-by: Michael S. Tsirkin 
> ---
> 
> changes from v1:
>   minor wording tweak
> 
>  content.tex | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Cornelia Huck 


-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org



[virtio-dev] [PATCH] virtio-gpu: add shared resource feature

2019-11-28 Thread Gerd Hoffmann
This patch adds a new virtio feature for shared resources.

Shared resources are allocated by the guest from normal ram, like
traditional resources.  They can be used by the guest almost like
traditional resources, the only exception is that shared resources can
only be used with backing storage attached (the linux driver does that
anyway so the workflow doesn't change).  The host can map these
resources and use them directly (using udmabuf), so any guest changes to
these resources can be visible on the host without explicit transfer
request.  Transfer requests are still needed though as the host might
still have syncronize the resource, for example in case importing the
udmabuf failed for some reason.

guest/host interface: Two new commands are added to create 2D and 3D
shared resources.  They work exactly like the non-shared counterparts.

qemu patches:
  https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-gpu-feature-shared

linux patches:
  https://git.kraxel.org/cgit/linux/log/?h=drm-virtio-feature-shared

Signed-off-by: Gerd Hoffmann 
---
 virtio-gpu.tex | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index 15dbf9f2ec82..ca27b3d5fa45 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -35,6 +35,7 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device 
/ Feature bits}
 \begin{description}
 \item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
 \item[VIRTIO_GPU_F_EDID  (1)] EDID is supported.
+\item[VIRTIO_GPU_F_RESOURCE_SHARED  2)] shared resources are supported.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / 
Device configuration layout}
@@ -103,6 +104,8 @@ \subsubsection{Device Operation: Create a framebuffer and 
configure scanout}
 
 \begin{itemize*}
 \item Create a host resource using VIRTIO_GPU_CMD_RESOURCE_CREATE_2D.
+  In case VIRTIO_GPU_F_RESOURCE_SHARED is negotiated the driver can
+  also use VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED.
 \item Allocate a framebuffer from guest ram, and attach it as backing
   storage to the resource just created, using
   VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING.  Scatter lists are
@@ -166,6 +169,28 @@ \subsubsection{Device Operation: Configure mouse cursor}
 the pointer shape and position.  To move the pointer without updating
 the shape use VIRTIO_GPU_CMD_MOVE_CURSOR instead.
 
+\subsubsection{Device Operation: Shared resources}
+
+In case VIRTIO_GPU_F_RESOURCE_SHARED is negotiated the driver can use
+the VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED command to create shared
+resources.  Normal resources have both a guest buffer and host buffer
+buffer for the resource and the VIRTIO_GPU_CMD_TRANSFER_* commands are
+used to transfer data between host and guest.  Shared (guest
+allocated) buffers CAN be used directly by the host, to remove or
+reduce the data copies needed.
+
+The driver MUST attach backing storage to a shared resource before
+using it.  Any changes on the shared resource MAY be instantly visible
+on the host.
+
+Otherwise the shared resources are used like normal resources.
+Especially the driver must send explicit VIRTIO_GPU_CMD_TRANSFER_*
+commands to the device for both normal and shared resources.  Reason:
+The device might have to flush caches.  The device MAY also choose to
+not create mapping for the shared resource.  Especially for small
+resources it might be more efficient to just copy the data instead of
+establishing a shared mapping.
+
 \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU 
Device / Device Operation / Device Operation: Request header}
 
 All requests and responses on the virt queues have a fixed header
@@ -186,6 +211,7 @@ \subsubsection{Device Operation: Request 
header}\label{sec:Device Types / GPU De
 VIRTIO_GPU_CMD_GET_CAPSET_INFO,
 VIRTIO_GPU_CMD_GET_CAPSET,
 VIRTIO_GPU_CMD_GET_EDID,
+VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED,
 
 /* cursor commands */
 VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
@@ -205,6 +231,7 @@ \subsubsection{Device Operation: Request 
header}\label{sec:Device Types / GPU De
 VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID,
 VIRTIO_GPU_RESP_ERR_INVALID_CONTEXT_ID,
 VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER,
+VIRTIO_GPU_RESP_ERR_NO_BACKING_STORAGE,
 };
 
 #define VIRTIO_GPU_FLAG_FENCE (1 << 0)
-- 
2.18.1


-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org



[virtio-dev] [PATCH] virtio-gpu: some edid clarifications

2019-11-28 Thread Gerd Hoffmann
Add some notes about fetching the EDID information.

Signed-off-by: Gerd Hoffmann 
---
 virtio-gpu.tex | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index af4ca610d235..15dbf9f2ec82 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -70,16 +70,21 @@ \subsubsection{Events}
 \begin{description}
 \item[VIRTIO_GPU_EVENT_DISPLAY] Display configuration has changed.
   The driver SHOULD use the VIRTIO_GPU_CMD_GET_DISPLAY_INFO command to
-  fetch the information from the device.
+  fetch the information from the device.  In case EDID support is
+  negotiated (VIRTIO_GPU_F_EDID feature flag) the device SHOULD also
+  fetch the updated EDID blobs using the VIRTIO_GPU_CMD_GET_EDID
+  command.
 \end{description}
 
 \devicenormative{\subsection}{Device Initialization}{Device Types / GPU Device 
/ Device Initialization}
 
 The driver SHOULD query the display information from the device using
 the VIRTIO_GPU_CMD_GET_DISPLAY_INFO command and use that information
-for the initial scanout setup.  In case no information is available or
-all displays are disabled the driver MAY choose to use a fallback,
-such as 1024x768 at display 0.
+for the initial scanout setup.  In case EDID support is negotiated
+(VIRTIO_GPU_F_EDID feature flag) the device SHOULD also fetch the EDID
+information using the VIRTIO_GPU_CMD_GET_EDID command.  If no
+information is available or all displays are disabled the driver MAY
+choose to use a fallback, such as 1024x768 at display 0.
 
 \subsection{Device Operation}\label{sec:Device Types / GPU Device / Device 
Operation}
 
-- 
2.18.1


-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org



Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification

2019-11-28 Thread Gerd Hoffmann
  Hi,

> Is the intent that any virtio device has to support all the same formats?

No.

> So it looks to me like all the formats should be part of the spec, and some
> device capabilities should indicate which ones the device accepts.

There is a per-stream bitmask in device config indicating which formats
are supported.

cheers,
  Gerd


-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org