From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kraxel@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ml01.01.org (Postfix) with ESMTPS id 56BF91A1E2B
 for <edk2-devel@ml01.01.org>; Mon,  5 Sep 2016 07:17:25 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
 (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 8A80F15561;
 Mon,  5 Sep 2016 14:17:24 +0000 (UTC)
Received: from nilsson.home.kraxel.org (ovpn-116-48.ams2.redhat.com
 [10.36.116.48])
 by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 u85EHN8X025366; Mon, 5 Sep 2016 10:17:24 -0400
Received: by nilsson.home.kraxel.org (Postfix, from userid 500)
 id 16AF080BD2; Mon,  5 Sep 2016 16:17:23 +0200 (CEST)
Message-ID: <1473085042.9260.43.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>, edk2-devel-01 <edk2-devel@ml01.01.org>,
 Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Mon, 05 Sep 2016 16:17:22 +0200
In-Reply-To: <147275957055.21562.7750188759462698423@jljusten-ivb>
References: <20160819124932.29711-1-lersek@redhat.com>
 <CAKv+Gu-FsmNzv2DSze-6G2HPhTjWGAC4cEJKq9fkDGmTDRT6+w@mail.gmail.com>
 <e9aa80f7-202f-5444-16b5-53e2521dbd03@redhat.com>
 <147267618723.12178.11385591212119668150@jljusten-ivb>
 <2c5b6038-a51a-9206-392b-d391c0aabf51@redhat.com>
 <147275300806.20661.4606850370467291385@jljusten-ivb>
 <0500cc50-86f9-ab97-f22d-012ac1857ad0@redhat.com>
 <147275957055.21562.7750188759462698423@jljusten-ivb>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.29]); Mon, 05 Sep 2016 14:17:24 +0000 (UTC)
Subject: Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)
X-BeenThere: edk2-devel@lists.01.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: EDK II Development  <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2016 14:17:25 -0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

  Hi,

> Is there no chance that ARM KVM might someday also be able to support
> a framebuffer?

Problem on arm is that you can't expose something as pci memory to the
guest which in reality isn't pci memory but normal ram (like the
emulated vga memory pci bar).

Storing a framebuffer in normal ram is (as far I know) no problem.  But
updates are a problem then, you have to:

  (a) notify the host about updates (which is what virtio-gpu does), or
  (b) turn on dirty tracking for *all* guest ram so you can detect
      display updates automatically (lot of overhead, vga needs dirty
      tracking only for the 16M pci bar), or
  (c) update whole framebuffer unconditionally in regular intervals
      (doesn't look great too).

cheers,
  Gerd