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

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

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
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



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