From: Anthony Liguori <aliguori@us.ibm.com>
To: miaofeng@starsoftcomm.com
Cc: 'xen-devel' <xen-devel@lists.xensource.com>,
'Jon Smirl' <jonsmirl@gmail.com>,
"'Antonino A. Daplas'" <adaplas@gmail.com>
Subject: Re: 答复: [Xen-devel] [RFC] Xen Virtual Framebuffer
Date: Mon, 05 Dec 2005 23:08:46 -0600 [thread overview]
Message-ID: <43951CDE.8000502@us.ibm.com> (raw)
In-Reply-To: <000601c5fa1f$ecb98ac0$0100a8c0@MiaoFengPC>
苗枫 wrote:
>I think this topic must be subject to Para-Virtualized Guest Linux (or some
>other os), for unmodified guest os on a VTx box, do you have any suggestion
>for graphic acceleration?
>
>
You're right, this is PV guest framebuffer virtualization.
There was a discussion recently on #qemu about acceleration. There are
few possibilities. The first would be to use 2d acceleration instead of
emulating in software (the cirrus card has all the standard fill, copy,
etc 2d ops). Then there's the topic of 3d acceleration.
This is a pretty big task and probably something you want to do with a
paravirtual driver. If we had our own X driver, we could implement the
appropriate pass-thru stuff. I don't know enough about Windows internals
to comment intelligently on it.
>And, what if we adjust the qemu-dm to accommodate both Para-dom and VTx-dom?
>
>
This is something I'm very interested in. Unifying VT/PV management will
definitely be an important usability feature for future versions of Xen.
Haven't though much about it myself though.
Regards,
Anthony Liguori
>
>
>Miao Feng
>
>Star SoftComm(China) Ltd
>
>
>-----邮件原件-----
>发件人: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] 代表 Jon Smirl
>发送时间: 2005年12月6日 11:13
>收件人: Anthony Liguori
>抄送: xen-devel; Antonino A. Daplas
>主题: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
>
>On 12/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote:
>
>
>>Jon Smirl wrote:
>>
>>
>>
>>>After thinking about this for a while, wouldn't Xen be better off with
>>>a virtual VGA device instead of a virtual fbdev? The virtual VGA
>>>device will work for other operating systems as well as Linux.
>>>Implementing a VESA BIOS may be better than emulating VGA.
>>>http://www.vesa.org/public/VBE/vbecore3.pdf
>>>
>>>
>>>
>>>
>>This is how Qemu does it so it's what we do for VT. The VMI spec
>>(VMware paravirtual spec) assumes that you'll be doing device emulation
>>and calls for an emulated PCI bus. Xen achieves really good performance
>>though by avoiding device emulation. Native speed device emulation is
>>an active area of research though so this might not always be the case :-)
>>
>>We don't currently do that in Xen though so it would be a considerable
>>amount of work to emulate a PCI bus and a VGA device (not to mention an
>>emu86 to be able to run the BIOS).
>>
>>
>
>VGA devices don't live on the PCI bus, they are ISA legacy devices at
>fixed IO ports/RAM address. But VESA is a better solution than the VGA
>device.
>
>Does Xen supply a BIOS into the virtual machine? If so, just implement
>the VESA entry points. Most of the Xen-based VESA entry points will do
>nothing, but they can't return the not-implemented error. This is very
>similar to what you are doing with a virtual fbdev, but the VESA
>scheme will work for Windows too. Linux already has a vesafb driver
>that will use the entry points you provide.
>
>However, I am assuming that Windows/Linux will fallback to using VESA
>calls if they don't find a physical VGA device. There isn't a simple
>way to test this since every video card that implements VESA also
>implements VGA. If you want to get errors from Linux while it is still
>in real mode you need to implement the BIOS INT 10 interface.
>
>--
>Jon Smirl
>jonsmirl@gmail.com
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>
>
>
>
>
next prev parent reply other threads:[~2005-12-06 5:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-05 23:00 [RFC] Xen Virtual Framebuffer Anthony Liguori
2005-12-06 0:17 ` Anthony Liguori
2005-12-06 0:35 ` Jon Smirl
2005-12-06 1:09 ` Anthony Liguori
2005-12-06 1:19 ` Jon Smirl
2005-12-06 1:25 ` Anthony Liguori
2005-12-06 1:31 ` Jon Smirl
2005-12-06 2:13 ` Anthony Liguori
2005-12-06 2:35 ` Jon Smirl
2005-12-06 2:55 ` Anthony Liguori
2005-12-06 3:13 ` Jon Smirl
2005-12-06 4:45 ` 答复: [Xen-devel] " 苗枫
2005-12-06 5:08 ` Anthony Liguori [this message]
2005-12-09 21:54 ` Tracy R Reed
2005-12-11 2:27 ` Jon Smirl
2005-12-16 12:14 ` Jacob Gorm Hansen
2005-12-16 15:48 ` Jon Smirl
2005-12-19 10:32 ` Jacob Gorm Hansen
2005-12-19 15:01 ` Jon Smirl
2005-12-06 0:50 ` M.A. Williamson
2005-12-06 1:19 ` Anthony Liguori
2005-12-06 10:50 ` Gerd Knorr
2005-12-06 11:06 ` Jacob Gorm Hansen
2005-12-06 14:54 ` Jon Smirl
2005-12-11 2:38 ` Jon Smirl
2005-12-16 11:20 ` Gerd Knorr
2005-12-16 16:16 ` Jon Smirl
2005-12-16 17:01 ` Gerd Knorr
2005-12-16 17:28 ` Anthony Liguori
2005-12-16 17:23 ` Anthony Liguori
2005-12-19 10:57 ` Gerd Knorr
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=43951CDE.8000502@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=adaplas@gmail.com \
--cc=jonsmirl@gmail.com \
--cc=miaofeng@starsoftcomm.com \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.