Xen devel - Mar 2005 - Framebuffer (was Xen port of ReactOS)

Fwiw, I think a ReactOS port would be very useful to both projects.

One thing I think xen could do with (if it isn''t there already) is some
sort of virtual framebuffer like with disk and network. Dom0 could provide the
backend of the virtual framebuffer (on virtual consoles or inside X windows or
whatever), and the other domains could make use of the exported framebuffers. It
wouldn''t be great for performance, but would provide a simple interface
to the other domains, and be reasonably migratable.

James
> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net [mailto:xen-devel-
> admin@lists.sourceforge.net] On Behalf Of Ge van Geldorp
> Sent: Friday, 25 March 2005 02:52
> To: ''ReactOS Development List'';
xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] Xen port of ReactOS
> 
> Hello,
> 
> After doing some research, I''ve decided to go ahead and start a
port of
> ReactOS to Xen. For those in the Xen community not familiar with ReactOS:
> it''s an open-source (GPL) re-implementation of the Microsoft
Windows
> NT-based line of operating systems, aiming to provide binary compatibility
> for both applications and drivers
> (http://www.reactos.com). For those in the ReactOS community not familiar
> with Xen: it''s an open-source (GPL) virtual machine monitor that
supports
> execution of multiple guest operating systems with unprecedented levels of
> performance and resource isolation
> (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html).
> 
> Initially I''ll focus on getting ReactOS running as a guest OS.
This should
> benefit ReactOS primarily, since this will make it possible to develop
> large
> parts of ReactOS (everything except for hardware drivers and some low-
> level
> memory management) inside Xen. It will also give ReactOS access to some
> hardware not natively supported yet (by using the Linux driver). The
> benefit
> for Xen at this stage would be the development of ReactOS device drivers
> for
> interfacing
> with Xen, which could also be used for a Windows XP port. On the longer
> term, I see no reason why ReactOS couldn''t function as a driver
domain. As
> driver compatibility improves in ReactOS, this could provide Xen guests
> access to hardware for which the manufacturer provides only Windows
> drivers
> (due to Xens nature, not every driver
> could be used this way, but I bet a large percentage of the drivers depend
> on the kernel to do the really low-level stuff).
> All in all, it seems a win-win proposition for both projects. And even
> more
> importantly, I think it''s a cool project :-)
> 
> I''ve made a branch in ReactOS svn,
svn://svn.reactos.com/branches/xen, for
> this port. Of course, the goal is to merge the changes into trunk
> eventually. I expect the port to take at least a few months, my initial
> feeling is that it should be done by the end of the year (there''s
lots of
> other stuff in ReactOS I want to work on too). The wiki page at
> http://wiki.reactos.com/Xen_port will be used to keep track of progress.
> The
> game plan is just start working from the boot code, until a problem is
> hit.
> Fix that problem and continue until the next problem.
> 
> Any support and help from the Xen and ReactOS communities are of course
> greatly appreciated.
> 
> Gé van Geldorp.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> Register
> by 3/29 & save $300
http://ads.osdn.com/?ad_idh83&alloc_id149&op=ick
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> One thing I think xen could do with (if it isn''t there 
> already) is some sort of virtual framebuffer like with disk 
> and network. Dom0 could provide the backend of the virtual 
> framebuffer (on virtual consoles or inside X windows or 
> whatever), and the other domains could make use of the 
> exported framebuffers. It wouldn''t be great for performance, 
> but would provide a simple interface to the other domains, 
> and be reasonably migratable.
There''s a plan for this: 

The intention is to have a shared memory bitmap frame buffer, with a
''side channel'' into which information about which rectangles
of the screen have been blited, filled, copied etc can optionally be sent.

In dom0 we can use vnclib to export the disaply over the network (over SSL) if
required, or render it on the local X server.

Any volunteers?

Ian 
> > -----Original Message-----
> > From: xen-devel-admin@lists.sourceforge.net [mailto:xen-devel-
> > admin@lists.sourceforge.net] On Behalf Of Ge van Geldorp
> > Sent: Friday, 25 March 2005 02:52
> > To: ''ReactOS Development List'';
xen-devel@lists.sourceforge.net
> > Subject: [Xen-devel] Xen port of ReactOS
> > 
> > Hello,
> > 
> > After doing some research, I''ve decided to go ahead and 
> start a port of
> > ReactOS to Xen. For those in the Xen community not familiar 
> with ReactOS:
> > it''s an open-source (GPL) re-implementation of the Microsoft
Windows
> > NT-based line of operating systems, aiming to provide 
> binary compatibility
> > for both applications and drivers
> > (http://www.reactos.com). For those in the ReactOS 
> community not familiar
> > with Xen: it''s an open-source (GPL) virtual machine monitor 
> that supports
> > execution of multiple guest operating systems with 
> unprecedented levels of
> > performance and resource isolation
> > (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html).
> > 
> > Initially I''ll focus on getting ReactOS running as a guest 
> OS. This should
> > benefit ReactOS primarily, since this will make it possible 
> to develop
> > large
> > parts of ReactOS (everything except for hardware drivers 
> and some low-
> > level
> > memory management) inside Xen. It will also give ReactOS 
> access to some
> > hardware not natively supported yet (by using the Linux driver). The
> > benefit
> > for Xen at this stage would be the development of ReactOS 
> device drivers
> > for
> > interfacing
> > with Xen, which could also be used for a Windows XP port. 
> On the longer
> > term, I see no reason why ReactOS couldn''t function as a 
> driver domain. As
> > driver compatibility improves in ReactOS, this could 
> provide Xen guests
> > access to hardware for which the manufacturer provides only Windows
> > drivers
> > (due to Xens nature, not every driver
> > could be used this way, but I bet a large percentage of the 
> drivers depend
> > on the kernel to do the really low-level stuff).
> > All in all, it seems a win-win proposition for both 
> projects. And even
> > more
> > importantly, I think it''s a cool project :-)
> > 
> > I''ve made a branch in ReactOS svn, 
> svn://svn.reactos.com/branches/xen, for
> > this port. Of course, the goal is to merge the changes into trunk
> > eventually. I expect the port to take at least a few 
> months, my initial
> > feeling is that it should be done by the end of the year 
> (there''s lots of
> > other stuff in ReactOS I want to work on too). The wiki page at
> > http://wiki.reactos.com/Xen_port will be used to keep track 
> of progress.
> > The
> > game plan is just start working from the boot code, until a 
> problem is
> > hit.
> > Fix that problem and continue until the next problem.
> > 
> > Any support and help from the Xen and ReactOS communities 
> are of course
> > greatly appreciated.
> > 
> > Gé van Geldorp.
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by Microsoft Mobile & 
> Embedded DevCon 2005
> > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the 
> latest Windows
> > Embedded(r) & Windows Mobile(tm) platforms, applications &
content.
> > Register
> > by 3/29 & save $300 
> http://ads.osdn.com/?ad_idh83&alloc_id149&op=ick
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> From: Ian Pratt
> 
> The intention is to have a shared memory bitmap frame buffer, 
> with a ''side channel'' into which information about which 
> rectangles of the screen have been blited, filled, copied etc 
> can optionally be sent.
> 
> In dom0 we can use vnclib to export the disaply over the 
> network (over SSL) if required, or render it on the local X server.
Being new to Xen, I might be missing something obvious, but what''s the
advantage of doing this VNC stuff in dom0? Why not do it in domU?

Would it be feasible to have dom0 manage the VBE framebuffer (just about any
graphics card is VBE-compliant these days)? Dom0 would map the frame buffer
into the "foreground" domain, so the guest could write directly to the
hardware frame buffer. When another domain is brought to the foreground,
dom0 would copy the bits from the frame buffer to a shadow memory area, map
that memory area in place of the frame buffer in the domain which was
previously foreground and give access to the hardware frame buffer to the
new foreground domain (after copying the bits from its shadow frame buffer).
> Any volunteers?
ReactOS/Windows without GUI is, uhhhm, icky, so I''m definitely
interested in
this. Just not right now, need to get ReactOS up and running first.

Gé van Geldorp.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> > The intention is to have a shared memory bitmap frame buffer, 
> > with a ''side channel'' into which information about
which
> > rectangles of the screen have been blited, filled, copied etc 
> > can optionally be sent.
> > 
> > In dom0 we can use vnclib to export the disaply over the 
> > network (over SSL) if required, or render it on the local X server.
> 
> Being new to Xen, I might be missing something obvious, but what''s
the
> advantage of doing this VNC stuff in dom0? Why not do it in domU?
Doing it in domU works fine, but isn''t tranparent to the guest.
 
> Would it be feasible to have dom0 manage the VBE framebuffer 
> (just about any
> graphics card is VBE-compliant these days)? Dom0 would map 
> the frame buffer
> into the "foreground" domain, so the guest could write directly
to the
> hardware frame buffer. When another domain is brought to the 
> foreground,
> dom0 would copy the bits from the frame buffer to a shadow 
> memory area, map
> that memory area in place of the frame buffer in the domain which was
> previously foreground and give access to the hardware frame 
> buffer to the
> new foreground domain (after copying the bits from its shadow 
> frame buffer).
This works fine for full-screen desktop use, but you do have to
''swizzle'' the framebuffer for normal ram when another domain
owns the
display. If all the heads are running X, you can probably just use the
SIGUSR1 support that''s used for virutal consoles and let X take care of
it.

If you want to share a framebuffer in anything other than full screen
(and care about protection), you need some proper virtualization.

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel