From: "Andreas Färber" <afaerber@suse.de>
To: Sriram Murthy <sriramsm@yahoo.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Stefan Hajnoczi <stefanha@gmail.com>,
qemu list <qemu-devel@nongnu.org>,
Gerd Hoffmann <kraxel@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] Virtualbox svga card in KVM
Date: Tue, 09 Apr 2013 19:04:13 +0200 [thread overview]
Message-ID: <51644A0D.5070307@suse.de> (raw)
In-Reply-To: <1365437119.34077.YahooMailNeo@web125305.mail.ne1.yahoo.com>
Hi,
Am 08.04.2013 18:05, schrieb Sriram Murthy:
> The Virtualbox SVGA card was derived out of the KVM VGA card, so there are quite a few similarities (I am deliberately being vague here as I am still in the process of discovering the features of both these cards completely). Having said that, the APIs and the data structures themselves have been modified to add new features (like displaying a custom bmp as the VGA bootup logo) and it has a custom vga bios as well.
> Also, it is better that it be its own separate device model, so that maintenance of the vbox code becomes easier later. Further, I am thinking on the lines of retaining the VIrtualbox SVGA card code as is, and write a small KVM abstraction layer, so that it will be easy to port the bug fixes into the vbox SVGA card later on.
> Any comments/suggestions welcome here.
Personally, I think that the connection between VirtualBox and QEMU is
very unidirectional if there is any... So code-wise our focus should
rather be to avoid code copies/divergence within our tree and to share
code with existing in-tree devices, especially if you are not paid to
continuously take care of this device once accepted into QEMU - that's
how I interpret PMM's question below.
There is nothing generally wrong with using KVM for guest driver
development or to make existing stripped-down guest images work at all
by adding such a special device.
However, proposing to adopt a random vendor's paravirtual graphics card
just because it has a few more resolutions and drivers on a particular
platform does not strike me as a big advantage over SPICE, VMware VGA or
past virtio-vga/-fb standardization attempts.
Regards,
Andreas
>
> -Sriram
>
>
>
> ----- Original Message -----
> From: Peter Maydell <peter.maydell@linaro.org>
> To: Sriram Murthy <sriramsm@yahoo.com>
> Cc: Stefan Hajnoczi <stefanha@gmail.com>; qemu list <qemu-devel@nongnu.org>; "kvm@vger.kernel.org" <kvm@vger.kernel.org>
> Sent: Monday, April 8, 2013 8:11 AM
> Subject: Re: [Qemu-devel] Virtualbox svga card in KVM
>
> On 6 April 2013 00:52, Sriram Murthy <sriramsm@yahoo.com> wrote:
>> (actually, the virtualbox SVGA card is based off of the KVM VGA card)
>
> Is it possible to implement it as an extension to the VGA
> card device, or has it diverged incompatibly such that it
> has to be its own separate device model?
>
> thanks
> -- PMM
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-04-09 17:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1363816855.57243.YahooMailNeo@web125304.mail.ne1.yahoo.com>
2013-03-21 14:53 ` [Qemu-devel] Virtualbox svga card in KVM Alon Levy
2013-04-02 1:13 ` Sriram Murthy
2013-04-03 2:48 ` Sriram Murthy
2013-04-05 7:06 ` Stefan Hajnoczi
2013-04-05 23:52 ` Sriram Murthy
2013-04-08 10:46 ` Stefan Hajnoczi
2013-04-08 15:08 ` Sriram Murthy
2013-04-08 15:11 ` Peter Maydell
2013-04-08 16:05 ` Sriram Murthy
2013-04-09 17:04 ` Andreas Färber [this message]
2013-04-09 18:25 ` Sriram Murthy
2013-04-11 9:06 ` Stefan Hajnoczi
2013-04-15 12:26 ` Gerd Hoffmann
2013-04-18 16:58 ` Sriram Murthy
2013-04-22 8:00 ` Gerd Hoffmann
2013-04-24 14:36 ` Veruca Salt
2013-04-09 16:04 ` Yan Vugenfirer
2013-04-09 16:19 ` Sriram Murthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51644A0D.5070307@suse.de \
--to=afaerber@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sriramsm@yahoo.com \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).