From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43893)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1XTTJE-00033A-2e
	for qemu-devel@nongnu.org; Mon, 15 Sep 2014 06:15:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1XTTJ7-0005yS-Q5
	for qemu-devel@nongnu.org; Mon, 15 Sep 2014 06:15:00 -0400
Received: from mx1.redhat.com ([209.132.183.28]:7723)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1XTTJ7-0005yM-J2
	for qemu-devel@nongnu.org; Mon, 15 Sep 2014 06:14:53 -0400
Message-ID: <1410776085.30598.1.camel@nilsson.home.kraxel.org>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 15 Sep 2014 12:14:45 +0200
In-Reply-To: <CAPM=9ty=xhETM++JebrkKoSoPQHGdvNcC_wU2jytZVo_wqETQA@mail.gmail.com>
References: <1410448173-12960-1-git-send-email-kraxel@redhat.com>
	<1410448173-12960-3-git-send-email-kraxel@redhat.com>
	<20140912091011.GC1614@stefanha-thinkpad.redhat.com>
	<1410521887.30411.13.camel@nilsson.home.kraxel.org>
	<CAPM=9ty=xhETM++JebrkKoSoPQHGdvNcC_wU2jytZVo_wqETQA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add
 docs/specs/virtio-gpu.txt
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Dave Airlie <airlied@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>, virtualization@lists.linux-foundation.org, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>, virtio-dev@lists.oasis-open.org

On Sa, 2014-09-13 at 07:14 +1000, Dave Airlie wrote:
> >> 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 probably need to work out some sort of accounting system, it can
> probably reliably only be a total value of resources, since we've no
> idea if the host driver will store them in VRAM or main memory. Quite
> how to fail gracefully is a question, probably need to report to the
> guest what context did the allocation and see if we can destroy it.

Best would be if virgilrenderer.so just fails
virgl_renderer_resource_create() calls.

> Not reason I can remember, I think I was thinking of having separate
> inval and detach at one point, but it didn't really make any sense, so
> renaming to detach is fine with me.

Done.

cheers,
  Gerd