Re: [Qemu-devel] qvm86, kqemu and video speed

[Struan Bartlett]

Fabrice Bellard wrote:

> Alex Beregszaszi wrote:
>
> > > Struan Bartlett wrote:
> > >
> > > I understand qvm86 and kqemu provide some virtualisation of the host 
> > > machine, including allowing the guest some direct memory access. Is 
> > > it conceivable for these modules to be extended to allow the guest 
> > > machine to directly write to host video memory, or else to a host 
> > > memory buffer that is copied into the Qemu window?
> >
> > I'm working on such a Direct Host Graphics custom "videocard".
>
> You can do that, but there is also a lot of optimisation opportunities 
> in the existing Cirrus driver. My feeling is that using a driver for a 
> virtual card will add only marginal gains (except in 3d) for a bigger 
> amount of work (you need specific drivers in the guest OSes).
>
> For example, in the Cirrus driver, it could be possible for the 
> virtual CPU to access the virtual frame buffer (currently a callback 
> is always used). A specific virtual CPU support is needed to change 
> dynamically the type of a physical memory mapping - that's why I did 
> not implement it when I enhanced the Cirrus driver. It will be even 
> more critical soon with a more optimized version of kqemu.

Thanks Fabrice for Qemu and for your input to this question. What you 
describe sounds like the sort of thing I was imagining. Are you 
suggesting your next version of kqemu will provide the "specific virtual 
CPU support" needed to do this? If so, please keep us posted.

> Moreover, it could be possible to suppress one memcpy from the virtual 
> frame buffer to the SDL/X11 frame buffer, and another memcpy if full 
> screen mode is used (in this case, the virtual CPU accesses directly 
> the host frame buffer).
>
> Finally, the Cirrus bitblt operations could be redirected to the 
> corresponding X11 DGA operations in full screen mode.

Or, do you think, as James Mastros suggested, the corresponding SDL 
operations in non-full-screen mode?

Struan