[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 答复: [Xen-devel] [RFC] Xen Virtual Framebuffer



苗枫 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@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] 代表 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@xxxxxxxxxx> 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@xxxxxxxxx
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>
>
>
>
>  
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.