KVM Support?

Mon Aug 27 17:09:03 AEST 2018

Hi Eddie & Ed:

Do you have any plan to support non-jpeg video stream in obmc-iKVM?
It is possible some platforms don't have hardware JPEG engine, instead have the RGB video stream.
If possible to support RGB video stream, I think it would be better if you can add the video frame differentiation in obmc-iKVM because we don't need to send the full screen to VNC client on every request, it can reduce the buffer size at least. (libvncserver already has the video frame differentiation)

Also, I have implemented a KVM application for our platform(nuvoton evb-npcm750) which has hardware video frame differentiation and hardware hextile engine.
https://github.com/Nuvoton-Israel/obmc-ikvm
https://github.com/Nuvoton-Israel/linux/commit/7e90f572323e56e9425b85aafe86dfa5a35c4e7d

I also enabled ED's KVM webui and added kvmws proxy in python web server.
https://github.com/Nuvoton-Israel/meta-openbmc-nuvoton-addon/commit/140771b7e898dd5ca8f0364290cce669609088ac

If you can spare a few minutes to review my implementation is my pleasure.

Currently, my video driver is not v4l2, so I am going to redesign it to fit v4l2 and your obmc-iKVM, then I will try to add the RGB format support in your obmc-ikvm.

Regarding the larger binary size, I think we need to review all configurations of libvncserver and check which functions should be disabled.

Thanks,
Joseph Liu.
-----Original Message-----
From: openbmc [mailto:openbmc-bounces+kwliu=nuvoton.com at lists.ozlabs.org] On Behalf Of Tanous, Ed
Sent: Saturday, August 25, 2018 3:04 AM
To: Eddie James; xiuzhi; Alexander A. Filippov; openbmc
Subject: RE: KVM Support?

>
> Well, the VNC server (and Video Engine driver) integration is targeted
> for the OpenBMC release in February 2019. Hopefully in master before
> then. There is currently no plan or work being done to integrate a
> viewer into the BMC webui. But patches are certainly welcome in this
> area! It could be as simple as dropping in a noVNC html file... not sure.
>

Not to disagree with you, but there's some work here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_-23_c_openbmc_phosphor-2Dwebui_-2B_10268_&d=DwIFAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=7g2D1XDc1ET3CnY1ySnaWQXPxPxfpLww1MiDbLW4v8Q&m=uAK69sfPRejBDLMlDDz55S4bZYC4CDdn36duJicj1Ng&s=D17B6-0jST399fiaUbHLhWtx-Igita5vNYzRA-bGBmA&e=

The webui side of it was just a matter of dropping novnc into the webui and routing the websocket back to the BMC.  The BMC side of it, implementing appropriate security on the websocket, and some other cleanup is on my back burner.  I'm at a bit of a crossroads, and I have two thoughts on how to proceed.

1. Rejigger the existing VNC kvm websocket implementation here to update to the new driver API, and delete all the JPEG to bitmap decoding code.  This solution essentially runs a websocket-only VNC server inside bmcweb. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openbmc_bmcweb_blob_master_include_web-5Fkvm.hpp&d=DwIFAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=7g2D1XDc1ET3CnY1ySnaWQXPxPxfpLww1MiDbLW4v8Q&m=uAK69sfPRejBDLMlDDz55S4bZYC4CDdn36duJicj1Ng&s=xlRipubKg7lXeC_KC_BlSZlCzxEljFoG1AL8mGRzQig&e=
Pros:
A. Smaller overall binary size.  Libvncserver supports a lot of things that I suspect openbmc will never need to.  For example, the password authentication mechanisms for VNC/RFB protocol are woefully out of date by modern standards, so I suspect there's no sense in having that code at all.
B. Better security.  There is no VNC port that could be abused/ported to get access to the KVM session.  The websocket authentication and authorization infrastructure uses the same mechanisms as the rest of the webserver, so it reduces the attack surface.  Said another way, it's unlikely an attack on bmcweb would be able to target the VNC server specifically.
C. Fewer framebuffer copies compared to a websocket proxy (at least in theory).  It is one fewer trip of the large framebuffers through userspace, which should save us some copies.  At some point in the future if we got the Linux TLS subsystem going, we could likely build a no-copy, or single copy framebuffer solution, which should net us some performance by essentially keeping the buffers in the kernel.

Cons:
A. It needs to be written.  Hopefully the changes should be mostly deletes, and regiggering to pull framebuffers from the driver.  Keyboard and mouse would need to be hooked up to the gadget driver using the example from obmc-kvm.
B. It is a specific solution for openbmc, so it's unlikely to have much utility outside of the project.  Contributing to libvncserver "gives back" more to the open source community.

2. Use bmcweb as a websocket proxy to obmc-kvm server in a very similar way to how we proxy to obmc-console.
Pros:
A. Gives us full compatibility with standard socket VNC, which could be useful for debugging purposes.  I wouldn't recommend enabling it in practice without some other kind of authentication and encryption pipeline ahead of it.
B. The work to do this should be relatively minimal.  It should be essentially a copy-paste of the obmc-console socket code, a little debugging, and it should be mostly good to go.

Cons:
A. Larger binary size.  I need to get more exact numbers here, but adding a relatively large library (libvncserver) and another application (obmc-kvm) seems unlikely to be good for our flash usage.  As is, we're already pushing the limits of a 32MB flash.
b. Extra framebuffer copies.  Driver -> obmc-kvm -> bmcweb(with TLS)  -> browser  in theory is at least one extra copy.  It would be interesting to set up both in practice.

3. Some other option that I'm missing?

I'm very interested in what the community thinks here.  Is there a use case for having the standalone vncserver?

-Ed

===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.