Markus Armbruster, le Tue 04 Mar 2008 16:48:20 +0100, a écrit :
> Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
> > Markus Armbruster, le Tue 04 Mar 2008 15:32:57 +0100, a écrit :
> >> > In my case, I'm using PVFB to expose the stubdomain qemu display. The
> >> > problem is that every 30ms, qemu wakes up to memcmp() the whole video
> >> > memory with a shadow buffer so as to track changes. If it knew that the
> >>
> >> Wait a second! You're talking about *your* frontend here, aren't you?
> >>
> >> Maintaining a shadow copy in the frontend (which requires compare and
> >> copy) to minimize copying in the backend sounds pretty self-defeating
> >> to me. Why is this a good idea?
> >
> > Because in my case the domain is HVM, and I don't want to trap the
> > writes to the video RAM since that's awfully slow.
> >
> >> Why not refrain from sending update messages and have the backend
> >> simply redisplay everything?
> >
> > Because as explained above, I can't avoid a shadow copy.
>
> I imagine (perhaps naively):
>
> * The domU writes to a framebuffer provided by the frontend.
>
> * The framebuffer (not a copy of it) can be shared with the backend,
> which only reads.
Well, that's not always the case, when the guest is in text mode for
instance, the PV shared buffer is converted from the guest text buffer.
> * If the frontend can track changes efficiently, it sends update
> messages to the backend, which can use them to only redisplay
> changed areas.
>
> Else the backend needs to assume the worst and periodically
> redisplay everything. It is free to maintain a shadow copy to track
> changes and minimize redisplay, if that turns out to be faster.
>
> What's wrong with that?
Well, that was actually my next target :)
(but for that we badly need the resize/redepth support).
However, that doesn't solve something that still bugs me, which is
that the VGA emulation layer wakes up every 30ms to just notice that
the width/height/depth registers didn't change etc. even if the actual
window is not shown.
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel