Re: [Xen-devel] [PATCH] patch to buffer write ioreq

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 22 Jun 2006, at 02:01, Dong, Eddie wrote:

> > I wonder if putting the VGA emulation in Xen itself would make sense?
> > The 'backend protocol' is just a simple linear framebuffer after all:
> Mmmm, not quit this. For standard VGA graphic mode 0x12, the frame
> buffer
> is splited into 4 pixel plane. Guest can mask each plan
> individually. For example, when guest write color 0x1010 and the plane
> mask is plane 0/1,
> then only plane 2 get 0 and plane 3 get 1 for that pixel. So the
> eventually pixel color is
>  depending on old color in plane 0/1. Also there are 4 write sub-mode.
I'm suggesting move *all* VGA emulation into Xen. So all this VGA 
weirdness would get turned into a linear framebuffer within Xen.
> > nothing very complicated (much simpler and easier to put in Xen than
> > xenbus/blk/net). VGA MMIO access would then be about as "fast" as a
> > vmenter/vmexit roundtrip. The main downside is that it might limit
> > what tricks we can do with the backend video protocol in future.
> Usually a VGA mode 0x12 pixel write will be accompanied by port IO
> write, a lot of logic need to be moved together if we want to do
> standard VGA emulation in Xen.
Yes, we'd just move the whole lot of the logic. I'm not sure it's a 
good idea, but thought it worth suggesting.
For example -- I know that qemu 'updates graphics' on a polling timer 
loop. Would we need to have that in Xen to produce the final linear 
frame buffer, or could the VGA device model easily keep the framebuffer 
up to date as it goes (ie., on every mmio or port write)? If the 
former, it's not very attractive to put in Xen, but equally it would be 
nice to get rid of the polling loop whatever we end up doing. I'm 
unclear whether the polling is just for SDL/VNC updates.
 -- Keir


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