two xenfb bugs for sale ;)

two xenfb bugs for sale ;)

[Gerd Hoffmann]

  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.

Oh, and it also doesn't unmap the framebuffer memory once the frontend
enteres the "Closing" state.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: two xenfb bugs for sale ;)

[Markus Armbruster]

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.

> 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?  Note that we must not unmap the framebuffer
while it's still being used by LibVNCServer or SDL.

Re: two xenfb bugs for sale ;)

[Gerd Hoffmann]

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>