Markus Armbruster wrote:> Gerd Hoffmann <kraxel@suse.de> writes:
>
>> Hi,
>>
>> Wondered where some xen-vncfb processes handing around on my machine
>> came from. After some Investigation I''ve figured that
xen-vncfb never
>> ever exits if you boot a virtual machine with a virtual framebuffer
>> configured, but boot a kernel without framebuffer support. It sits
>> waiting for the frontend device come up and doesn''t exit when
the domain
>> goes away.
>
> Patch to be posted shortly.
Great.
>> Oh, and it also doesn''t unmap the framebuffer memory once the
frontend
>> enteres the "Closing" state.
>
> You''re right, it only unmaps the two shared pages. The
framebuffer is
> normally unmapped in xenfb_detach_dom(), called from xenfb_delete().
> What''s wrong with that?
I''ve played around with guest kexec and the virtual framebuffer. To be
exact with a kexec-based bootloader, which then can (unlike pygrub)
present the boot menu on the framebuffer.
The new kernel booted will of course use another set of pages for the
virtual framebuffer. The frontend keeping the old pages mapped doesn''t
work. In the best case you just get a funny looking screen with random
junk in there. It can also happen that the new kernel wants to use
pages as page tables which used to be framebuffer pages for the old
kernel. In that case the kernel simply crashes because the page type
verification fails due to the pages still being mapped by the backend.
> Note that we must not unmap the framebuffer
> while it''s still being used by LibVNCServer or SDL.
Map a dummy black screen, maybe with "frontend not (re-)connected yet"
rendered on it?
I think it would be very useful for the virtual framebuffer to be able
to go through a disconnect-reconnect cycle, including unmapping and
remapping the virtual framebuffer memory. Not only for kexec, it could
also be used to switch the framebuffer resolution at runtime using fbset
within the guest.
cheers,
Gerd
--
Gerd Hoffmann <kraxel@suse.de>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel