[coreboot] [GSoC] Coreboot Spice Payload
ldorileo at gmail.com
Sun Mar 27 03:39:07 CEST 2011
On Sat, Mar 26, 2011 at 1:03 PM, xdrudis <xdrudis at tinet.cat> wrote:
> On Mon, Mar 21, 2011 at 01:49:49PM -0400, Leandro Dorileo wrote:
> Excuse my ignorace, but you say :
>>  - http://vps.dorilex.net/~dorileo/coreboot-spice-payload.txt
>> 3. Coreboot Spice Payload
>> Spice building blocks are Spice protocol, Spice server and spice client,
>> the Coreboot Spice Payload fits on client component. The component will
>> be an interface between the current devices(Video, keyboard, mouse, etc.)
>> and the virtualized guest OS.
> Do you mean some kind of SerialICE? (which accesses hardware registers and
> sends the information to the serial port and applies I/O commands it gets from
> the serial port to the hardware, so that you can put a modified emulator
> at the other side and run the firmware/software that you would run on
> the machine SerialICE is ). If so, SerialICE isn't a payload, it's a "replacement
> for coreboot" who can proxy what a remote coreboot does. The remote side
> has a coreboot, payload and OS. I mean coreboot does not load serialICE,
> it is SerialICE who boots up and starts listening for commands.
I don`t mean SerialICE, it`s a payload which will handle the devices
inputs, send the remote messages and wait for its responses.
> In any case, if you write some sort of network backed SerialICE, it won't
> allow you to have a desktop experience in a low end machine, because
> it will still be the low end machine executing the instructions it gets
> from somewhere. Those instructions might be a lightweight OS and a remote
> desktop client of some kind, but it won't run any faster (only slower) than
> if you directly installed the OS and client in the low end machine.
>> 4. Payload Main Tasks
>> The Coreboot Spice Payload main tasks involve hardware interruption handling,
>> spice commands dispatching and response rendering.
>> Beyond the hardware and command handling the payload will provide a basic
>> configuration interface so host address and SSL can be set.
>> 4.1 Libpayload
>> CSPLD will rely on libpayload drivers for keyboard, serial and video.
> Which drivers ? Are there drivers for video in libpayload ? For which
> VGAs ?
Yes, initially I don`t intend to support any further robust device, so
I intend to use the vga, serial and usb drivers present in libpayload.
> I think there's going to be a similar effort as to that of building
> an OS and its drivers if you don't want to load an OS on the client. My understanding
> is that coreboot/payloads only initialize the CPU, chipset, memory, buses and the
> minimum devices they need for debug and loading and OS. It is the OS
> who recognizes the different possible mouses, vgas, network cards, etc., the OS loads
> the appropiate drivers and applications (such as sshd, rdp, vnc, X or whatever)
> can then use them. If you want to get rid of the OS and applications you will
> have to rewrite their functionality, which isn't a summer job.
The real operating system is not running in the local machine but in a
remote hypervisor. All we need to implement is some very minimal OS
premises. Input handling, an tcp/ip stack and naturally some queues
for sending and receiving the remote messages. I don`t see we`ll need
any full and proper operating system just the payload, that`s the
> Let's suppose the user want to move a window and the processing that calculates
> the next image (which other windows parts are shown or hidden, any animation, etc.)
> is done in a remote computer. The image still has to be sent (however compressed
> or optimized) and the client has to show it on screen. So you need a video driver,
> a mouse driver, knowledge of the monitor, mouse, their resolutions and protocols...
> I don't think there's such a thing in coreboot or libpayload.
libpayload has vga, usb and serial drivers, the necessary for the
project. In the future we may think about writing other drivers being
it in libpayload or not.
> But maybe I just haven't understood the idea. In fact I know nothing about virtualization,
> but my notion is that with vitualization you get more than one OS in a physical machine,
> I don't see how you can get 0 OSes. With coreboot you can certainly avoid loading an OS,
> but then the payload will have to do all the useful functionality.
Once we`re not running the virtual machine in the local machine but in
a remote hypervisor we`ll need - like I said - we need just to
implement the spice protocol and handle the client`s inputs. I have
drawn a chart to describe the general idea.
 - http://vps.dorilex.net/~dorileo/coreboot-spice-payload.png
More information about the coreboot