Re: BUG_ON in virtio-ring.c

correct. If I have an indirect ring and I'm adding sgs to it and the host is delayed (say I've got a thread consuming things from the vring and its off doing something interesting), I'd really like to get ENOSPC back from virtqueue_add. However if the indirect addition fails due to free_sg

Re: [PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use

We have almost 1000 more uses of the non-macro version than the macro version in the kernel today: $ git grep -w DEFINE_PCI_DEVICE_TABLE | wc -l 262 $ git grep const struct pci_device_id | wc -l 1254 did you check for non-const ones? just to see if we have any of the broken case in the

Re: [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

Can the host refuse due to lack of resources? Yes. virtgpu_ctrl_hdr.type in the response will be set to VIRTGPU_RESP_ERR_* then. Current implementation does that only on malloc() failure, there is no accounting (yet) to limit the amout of memory the guest is allowed to allocate. We do

Re: [virtio-dev] [PATCH 0/2] virtio-gpu: hardware specification

-wip https://www.kraxel.org/cgit/linux/log/?h=virtio-gpu-rebase The qemu patches are in a reasonable state. The linux kernel patches are not cleaned up yet, you probably want to look at the final tree only. Work has been done by Dave Airlie airl...@redhat.com and me. The authorship info

Re: [virtio-dev] Re: [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

On 14 September 2014 19:16, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- docs/specs/virtio-gpu.txt | 165 ++ 1 file changed, 165

Re: [PATCH] Add virtio gpu driver.

On 25 March 2015 at 08:50, Daniel Stone dan...@fooishbar.org wrote: Hi, On 24 March 2015 at 16:07, Gerd Hoffmann kra...@redhat.com wrote: +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc, +struct drm_framebuffer *fb, +

Re: [RFCv3 0/5] enable migration of driver pages

Can the various in-kernel GPU drivers benefit from this? If so, wiring up one or more of those would be helpful? I'm sure that other in-kernel GPU drivers can have benefit. It must be helpful. If I was familiar with other in-kernel GPU drivers code, I tried to patch them. It's too

Re: [PATCH 3/5] update virtio gpu driver: add 3d/virgl support

> > --- /dev/null > > +++ b/include/uapi/drm/virtgpu_drm.h > > @@ -0,0 +1,163 @@ > > > + > > +struct drm_virtgpu_3d_box { > > + uint32_t x, y, z; > > + uint32_t w, h, d; > > +}; > > + > There was a similar case (multiple variables declared on a single > line) in drm core that caused

Re: [PATCH 5/5] virtgpu: mark as a render gpu

On 11 September 2015 at 01:04, Emil Velikov wrote: > On 10 September 2015 at 15:52, Gerd Hoffmann wrote: >> Hi, >> >>> > Dave? Looking at the ioctls they are all fine for render nodes, there >>> > isn't anything modesetting related in the

Re: [PATCH 2/2] drm: virtio: fix virtio_gpu_mode_dumb_create

On 3 April 2017 at 17:08, Gerd Hoffmann <kra...@redhat.com> wrote: > Lookup format using virtio_gpu_translate_format() > instead of hardcoding it. Fixes xorg display on > bigendian guests (i.e. ppc64). > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> For the series

Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

On 9 August 2017 at 09:42, Joe Kniss wrote: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle()

Re: [PATCH v2 00/14] improve the fb_setcmap helper

> > I'm traveling and cannot make progress this week. The merge window is > also real close so this series will therefore probably miss it unless > something unexpected happens... Don't worry you missed the merge window for drm already, we don't merge things after -rc6. Please remember the Linus

Re: v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")

On 17 June 2018 at 21:02, Greg KH wrote: > On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: >> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: >> > >> > And if you revert that patch, does everything work again? >> >> Yes. > > Great, Dave, care to revert this in 4.18 so I can

Re: [PATCH] drm/virtio: Add window server support

> > this work is based on the virtio_wl driver in the ChromeOS kernel by > Zach Reizner, currently at: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c > > There's two features missing in this patch when compared with virtio_wl: > > *

Re: [PATCH] drm/virtio: fix vq wait_event condition

Reviewed-by: Dave Airlie <airl...@redhat.com> On Fri., 20 Apr. 2018, 17:23 Gerd Hoffmann, <kra...@redhat.com> wrote: > On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote: > > Wait until we have enough space in the virt queue to actually queue up > > our

Re: [PATCH] drm/virtio: fix vq wait_event condition

ero >> amount of free entries but not enough for the request. > > Ping airlied, can you please either pick it up or review so I can commit > myself? Just in case it got lost from my phone, Reviewed-by: Dave Airlie <airl...@redhat.com> > > thanks, > Gerd > >&g

Re: [PATCH 7/8] drm/virtio: move virtio_gpu_object_{attach, detach} calls.

On Thu, 18 Oct 2018 at 17:00, Gerd Hoffmann wrote: > > > > > This to me feels more like a bind/unbind operation rather than a > > > > populate/unpopulate operation, > > > > > > > > bind is " Bind the backend pages into the aperture in the location" > > > > > > > > whereas populate is > > > > > >

Re: [PATCH 7/8] drm/virtio: move virtio_gpu_object_{attach, detach} calls.

On Thu, 18 Oct 2018 at 16:11, Gerd Hoffmann wrote: > > On Thu, Oct 18, 2018 at 11:41:52AM +1000, Dave Airlie wrote: > > On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote: > > > > > > Remove the virtio_gpu_object_{attach,detach} calls from move_notify() > >

Re: [PATCH v2] virtio-gpu: add VIRTIO_GPU_F_EDID feature

Reviewed-by: Dave Airlie On Fri, 5 Oct 2018 at 22:52, Gerd Hoffmann wrote: > > The feature allows the guest request an EDID blob (describing monitor > capabilities) for a given scanout (aka virtual monitor connector). > > It brings a new command message, which has just a scanou

Re: [PATCH v2] drm/bochs: add edid support.

On Fri, 5 Oct 2018 at 22:10, Gerd Hoffmann wrote: > > Recent qemu (latest master branch, upcoming 3.1 release) got support > for EDID data. This patch adds guest driver support. > > EDID support in qemu is not (yet) enabled by default, so please use > 'qemu -device VGA,edid=on' for testing. The

Re: [PATCH 5/8] drm/virtio: track created object state

On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote: > > Track whenever the virtio_gpu_object is already created (i.e. host knows > about it) in a new variable. Add checks to virtio_gpu_object_attach() > to do nothing on objects not created yet. > > Make virtio_gpu_ttm_bo_destroy() use the new

Re: [PATCH 7/8] drm/virtio: move virtio_gpu_object_{attach, detach} calls.

On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote: > > Remove the virtio_gpu_object_{attach,detach} calls from move_notify() > callback. Add them to the ttm_tt_{populate,unpopulate} callbacks, which > is the correct place to handle this. > > The new ttm_tt_{populate,unpopulate} callbacks call the

Re: [PATCH] drm/virtio: track virtual output state

off-by: Gerd Hoffmann Reviewed-by: Dave Airlie > --- > drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + > drivers/gpu/drm/virtio/virtgpu_display.c | 4 > drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +- > 3 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu

Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.

For the series, Reviewed-by: Dave Airlie On Wed, 29 Aug 2018 at 22:20, Gerd Hoffmann wrote: > > Use the dma mapping api and properly add iommu mappings for > objects, unless virtio is in iommu quirk mode. > > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/virt

Re: [PATCH] drm/qxl: drop prime import/export callbacks

On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote: > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > userspace. > > Signed-off-by: Gerd Hoffmann Reviewed-by: Dave Airlie > --- > drivers/gpu/

Re: [PATCH] drm/virtio: drop prime import/export callbacks

On Thu, 10 Jan 2019 at 21:16, Gerd Hoffmann wrote: > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > userspace. Reviewed-by: Dave Airlie > > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/

Re: [PATCH] drm/virtio: switch to generic fbdev emulation

On Thu, 13 Dec 2018 at 23:49, Gerd Hoffmann wrote: > > Signed-off-by: Gerd Hoffmann Seems correct to me, Reviewed-by: Dave Airlie ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/m

Re: [PATCH] drm/qxl: drop prime import/export callbacks

On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote: > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote: > > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > > userspace. It's been p

Re: [PATCH 00/15] Share TTM code among framebuffer drivers

On Tue, 9 Apr 2019 at 17:12, kra...@redhat.com wrote: > > Hi, > > > If not for TTM, what would be the alternative? One VMA manager per > > memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there.

Re: [PATCH] drm/qxl: Fix build errors

On Tue, 18 Aug 2020 at 15:32, Gerd Hoffmann wrote: > > Hi, > > > I guess things are never quite so easy :-). It looks like Daniel's > > patch is in drm-misc-fixes and Sidong's patch is in drm-misc-next. On > > their own they're fine, but once they are merged in drm-tip the build > > error shows