similar to: [virtio-dev] Re: [PATCH v5 0/3] Support virtio cross-device resources

On Tue, Jun 09, 2020 at 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 > under consideration to add support in the virtio-video driver is [3]. > It uses the APIs from v3 of this

On Tue, Aug 18, 2020 at 10:37:41AM +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 > under consideration to add support in the virtio-video driver is [3]. > It uses the APIs from v3 of this

On Fri, Sep 12, 2014 at 12:44:56PM +0200, Gerd Hoffmann wrote: > Hi, > > > > @@ -0,0 +1,158 @@ > > > +#ifndef VIRTGPU_HW_H > > > +#define VIRTGPU_HW_H > > > > Non-trivial file, deserves a copyright and license notice. > > Added. Pls remember to make it consistent with other virtio headers, which are 3-clause BSD, prefixed with this reminder:

On Fri, Sep 12, 2014 at 12:44:56PM +0200, Gerd Hoffmann wrote: > Hi, > > > > @@ -0,0 +1,158 @@ > > > +#ifndef VIRTGPU_HW_H > > > +#define VIRTGPU_HW_H > > > > Non-trivial file, deserves a copyright and license notice. > > Added. Pls remember to make it consistent with other virtio headers, which are 3-clause BSD, prefixed with this reminder:

On Tue, May 26, 2020 at 07:58:08PM +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 > under consideration to add support in the virtio-video driver is [3]. > It uses the APIs from v3 of this

On Wed, May 15, 2019 at 09:05:54AM +0200, Thomas Zimmermann wrote: > Hi, > > most of this patch set still needs reviews. > > If it's too large for merging or reviewing at once, I could move the > driver changes into separate patch sets. The vbox driver's changes have > been accepted by Hans already. So only keeping the core changes plus > vbox would be an option.

On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote: > On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst at redhat.com> 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)) { > > > > > +

virtio-input is basically evdev-events-over-virtio, so this driver isn't much more than reading configuration from config space and forwarding incoming events to the linux input layer. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- MAINTAINERS | 6 + drivers/virtio/Kconfig | 10 + drivers/virtio/Makefile | 1 +

virtio-input is basically evdev-events-over-virtio, so this driver isn't much more than reading configuration from config space and forwarding incoming events to the linux input layer. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- MAINTAINERS | 6 + drivers/virtio/Kconfig | 10 + drivers/virtio/Makefile | 1 +

> > +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj, > > + struct vm_area_struct *area) > > +{ > > + WARN_ONCE(1, "not implemented"); > > + return ENOSYS; > > This can get called by userspace, so please don't WARN here. Also missing > negate sign: > > return -ENOSYS; Hmm now checkpatch throws a warning at me:

> > +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj, > > + struct vm_area_struct *area) > > +{ > > + WARN_ONCE(1, "not implemented"); > > + return ENOSYS; > > This can get called by userspace, so please don't WARN here. Also missing > negate sign: > > return -ENOSYS; Hmm now checkpatch throws a warning at me:

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init, so we can also drop the tricky fence logic which checks whenever the command is in flight still. We can simply fence our object before submitting the virtio command and be done

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>

On Tue, Mar 03, 2020 at 11:42:22AM +0900, David Stevens wrote: > > 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

This series is based on v4.4-rc2 and the "virtio: make find_vqs() checkpatch.pl-friendly" patch I recently submitted. v4: * Addressed code review comments from Alex Bennee * MAINTAINERS file entries for new files * Trace events instead of pr_debug() * RST packet is sent when there is no listen socket * Allow guest->host connections again (began discussing netfilter support with

This series is based on v4.4-rc2 and the "virtio: make find_vqs() checkpatch.pl-friendly" patch I recently submitted. v4: * Addressed code review comments from Alex Bennee * MAINTAINERS file entries for new files * Trace events instead of pr_debug() * RST packet is sent when there is no listen socket * Allow guest->host connections again (began discussing netfilter support with

On Wed, Jul 03, 2019 at 01:05:12PM -0700, Chia-I Wu wrote: > On Tue, Jul 2, 2019 at 7:19 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Switch to the virtio_gpu_array_* helper workflow. > (just repeating my question on patch 6) > > Does this fix the obj refcount issue? When was the issue introduced? obj refcount should be fine in both old and new code. old

On Wed, Jul 03, 2019 at 01:05:12PM -0700, Chia-I Wu wrote: > On Tue, Jul 2, 2019 at 7:19 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Switch to the virtio_gpu_array_* helper workflow. > (just repeating my question on patch 6) > > Does this fix the obj refcount issue? When was the issue introduced? obj refcount should be fine in both old and new code. old

Hi, > > +static struct resource *request_capability(struct pci_dev *dev, int off, > > + const char *name) > > +{ > > + u8 bar; > > + u32 offset, length; > > + > > + pci_read_config_byte(dev, off + offsetof(struct virtio_pci_cap, > > + bar), > > + &bar); > > + pci_read_config_dword(dev, off + offsetof(struct