qemu discuss - Jan 2007 - Hi: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin

²Š'

Martin Bochnig wrote:
>soon
>
>  
>
(Sorry for cross-posting, but too many people are waiting for one or
another thing.)

Merging several small and bigger diffs into the CVS was not so much of a
problem.
But they at qemu (i.e. Thiemo Seufer) have professionally reimplemented
DMA support into hw/ide.c and hw/dma.c , rather than just using the
working solution Juergen Keil has written.
Using the default dma.c and ide.c breaks DMA support for Solaris guests
once again.

One gets the best results for Solaris-guest dma-support, when simpliy
using the old Solaris-patched ide.c and dma.c from
http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2__default_FabriceB__versus__qemu-0.8.2-solaris__20061013fri__MB.gdiff
or
http://opensolaris.org/os/project/qemu/downloads/qemu-0.8.2-solaris_src_20061013fri.tar.bz2

However: cdrom support is currently completely broken for Win9x guests,
no matter whether I use Oct14''s patched ide.c/dma.c, unpatched
cvs20070102tue ones, or patched cvs20070102tue ones with the old
JuergenKeil-written code merged into as best as now possible.
Unfortunately doesn''t it core dump - it just doesn''t work.

Ben Taylor is also "unimpressed" by the current cvs.

Problem: I cannot exclusively offer something that broken as SUNWqemu
packages.
I will therefore have to offer experimental cvs20070102tue packages for
sparc and x86/x64 *plus* mature and 99% stable updated (i.e. Juergen
Keil''s Info patch, Sittichai''s Tunnel patches etc. etc.)
packages built
from the old cvs20061014.

Damn, next homework is due Wednesday and still no Xorg patch created.
That homework is a biggie and I should already have started.


Martin

> Martin Bochnig wrote:
> 
> 
> Merging several small and bigger diffs into the CVS
> was not so much of a
> problem.
> But they at qemu (i.e. Thiemo Seufer) have
> professionally reimplemented
> DMA support into hw/ide.c and hw/dma.c , rather than
> just using the
> working solution Juergen Keil has written.
I hacked around with this today, and have been unable to boot a Solaris Express
B54 ISO image with DMA enabled, even with some of the hacks that Juergen
had orginally written.  I will go back to my 0.8.0 hacks to see if
there''s something
in the ide_atapi registered that I messed around with, but it looks like the
changes
that happened in the IO subsystem is causing some big problems for Solaris
(and other OS''s requiring DMA from a CDROM).
> Using the default dma.c and ide.c breaks DMA support
> for Solaris guests
> once again.
yep.
> One gets the best results for Solaris-guest
> dma-support, when simpliy
> using the old Solaris-patched ide.c and dma.c from
> http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2__
> default_FabriceB__versus__qemu-0.8.2-solaris__20061013
> fri__MB.gdiff
> or
> http://opensolaris.org/os/project/qemu/downloads/qemu-
> 0.8.2-solaris_src_20061013fri.tar.bz2
> 
> However: cdrom support is currently completely broken for Win9x guests,
> no matter whether I use Oct14''s patched ide.c/dma.c,  unpatched
> cvs20070102tue ones, or patched cvs20070102tue ones
> with the old JuergenKeil-written code merged into as best as now
> possible.  Unfortunately doesn''t it core dump - it just
doesn''t  work.
Yep.
> Ben Taylor is also "unimpressed" by the current cvs.
Actually, the latest CVS code is showing release 0.8.3,
and since they integrated the patch for block-raw.c the
current code base compiles fine with Solaris now.
--
This message posted from opensolaris.org

Hi,
> Actually, the latest CVS code is showing release 0.8.3,
> and since they integrated the patch for block-raw.c the
> current code base compiles fine with Solaris now.
>   
And the dma issue mentioned by Martin and you is not there anymore in 
this release?

regards

Bernd
> --
> This message posted from opensolaris.org
> _______________________________________________
> qemu-discuss mailing list
> qemu-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/qemu-discuss
>
>   

-- 
Bernd Schemmer, Frankfurt am Main, Germany
http://home.arcor.de/bnsmb/index.html

M?s temprano que tarde el mundo cambiar?.
                        Fidel Castro

/* Note: 2nd try to send msg., this time without the oversized
attachment (url instead).
Eric:  I cannot cancel the original msg. (bad confirmation string, after
I reloaded page).
Please reject it, thanks. */

Bernd Schemmer wrote:
> Hi,
>
>> Actually, the latest CVS code is showing release 0.8.3,
>> and since they integrated the patch for block-raw.c the
>> current code base compiles fine with Solaris now.
>>   
>
>
> And the dma issue mentioned by Martin and you is not there anymore in
> this release?

yep, currently, still.
But I made minor progress when I last had time for it (a week ago).
The problems must (partially) be outside of ide.c and dma.c (bridge or
chipset or new ide vs. scsi disk support).

My next step will be to systematically narrow down the field, where the
problem can potentially be expected: First will I have to test the
behaviour on different HOST os''s.
If it does work on linUX HOSTs (sparc, x86/64), for example, then only
#ifdef''ed stuff like header files and other characteristics can be the
problem.

Again, a status summary:

(A)
With the old ide.c and dma.c from our Oct14 patched src tree (inside a
patched cvs20070102tue) I get:
Solaris11_b54-guest:
[ X] CDROM works
[X] DMA works

Win9x guest
[  ] CDROM works
[ ] DMA works

##############

(B)
With the unpatched default cvs20070102 ide.c and dma.c files I get:
Solaris11_b54-guest:
[ X] CDROM works
[ ] DMA works

Win9x guest
[  ] CDROM works
[ ] DMA works

##############

(C)
With Juergen Keil''s old dma patch merged into ide.c (of course by hand,
as much as it now fits) I currently get:
Solaris11_b54-guest:
[ X] CDROM works
[partially] DMA works

Win9x guest
[  ] CDROM works
[ ] DMA works

##############

(--)
With the old Oct14 SUNWqemu package, on the other hand, we used to get:
Solaris11_b46-guest:
[ X] CDROM works
[X] DMA works

Win9x guest
[X] CDROM works
[X] DMA works

It''s all just code and is therefore solvable.
... that is, literally, a.s.a.p.


Regards,
Martin
p.s. Again, status from last week, the old Oct14 patch merged into
cvs20070102tue:
http://www.opensolaris.org/jive/servlet/JiveServlet/download/13-21321-81940-1888/qemu_cvs20070102tue__solaris__MB.gdiff.bz2
Note: The other patches to be included are not yet inside, as we first
need to get the basics running - reliably enough.
>
> regards
>
> Bernd
>
>> -- 
>> This message posted from opensolaris.org
>> _______________________________________________
>> qemu-discuss mailing list
>> qemu-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/qemu-discuss
>>
>>   
>
>
>

> Bernd Schemmer wrote:
> 
> > Hi,
> >
> >> Actually, the latest CVS code is showing release
> 0.8.3,
> >> and since they integrated the patch for
> block-raw.c the
> >> current code base compiles fine with Solaris now.
> >>   
> >
> >
> > And the dma issue mentioned by Martin and you is
> not there anymore in
> > this release?
Yeah. The old patches I had, and the stuff martin has used to work,
but there has been substantial work in the last 6 months on the io
subsystem.  IDE was enhanced, and SCSI was added, and then
there was a DMA and AIO subsystem put in place (which I think
is where the crux of the problem is).  The changes that Martin have
against the current code base shows the amount of change that
has occured in hw/ide.c in the last couple of months, specifically
around IDE/DMA and CD DMA.

The stock CVS code can boot a Solaris NVX B54 ISO image, but sees
DMA timeout messages and eventually fails to complete when it can''t
see/mount the file system where the Solaris packages are.  I then tried
a basic, text mode, SUNWCuser install, disabling atapi-cd-dma-enabled
at the grub boot prompt, and that completed, but has yet to actually boot 
completely into Solaris.  I let it go for 30-40 minutes after it complted
the SMF initialization, but it never got the root prompt.  All I see are
DMA timeouts.  I''m trying to boot it with -B atapi-cd-dma-enabled=0 to
see if it will actually come up.

> yep, currently, still.
> But I made minor progress when I last had time for it
> (a week ago).
> The problems must (partially) be outside of ide.c and
> dma.c (bridge or
> chipset or new ide vs. scsi disk support).
Some SCSI disk stuff went back in again today.... <sigh>
> My next step will be to systematically narrow down
> the field, where the
> problem can potentially be expected: First will I
> have to test the
> behaviour on different HOST os''s.
> If it does work on linUX HOSTs (sparc, x86/64), for
> example, then only
> #ifdef''ed stuff like header files and other
> characteristics can be the
> problem.
I''d like to see us take specific subsets of your patches and get
them submitted to the QEMU CVS.  They are more willing to 
take tiny patches that fix one specific thing, than a big hairy
patch like we have now.

I see like 4-5 things that could be separate patches for CVS,
but there may be some intermingling of areas that require
more effort to separate.

1) sparcv7/v8/v8plus configure changes.  I understand why the 
CFLAGS/LDFLAGS need to be defined in the configure script 
(specifically so the libsdl test gets linked  correctly at 
configure time)

2) x86_64 kqemu support.  This looks like it needs some tuning, 
especially since kqemu only works with Solaris Express/Open 
Solaris (not Solaris 10)

3) Sparc V9 support (dyngen.c, elf.h)

4) Sparc/Arm changes

5) Sparc RTDC support (vl.c)  - didn''t we already have rtdc support
here, or
is this specific to the hw machine types?

6) ide.c - I think we''ll probably have to work within the current
changes. The patches
that martin have that are working are drastically different from the current CVS
code, and I don''t think we''re going to be able to make a case
on why it should stay
the same without proving the pbrook, theimo and fabrice otherwise.

Does this look about right?
> Again, a status summary:
> 
> (A)
> With the old ide.c and dma.c from our Oct14 patched
> src tree (inside a
> patched cvs20070102tue) I get:
> Solaris11_b54-guest:
> [ X] CDROM works
> [X] DMA works
> 
> Win9x guest
> [  ] CDROM works
> [ ] DMA works
> 
> ##############
> 
> (B)
> With the unpatched default cvs20070102 ide.c and
> dma.c files I get:
> Solaris11_b54-guest:
> [ X] CDROM works
> [ ] DMA works
> 
> Win9x guest
> [  ] CDROM works
> [ ] DMA works
> 
> ##############
> 
> (C)
> With Juergen Keil''s old dma patch merged into ide.c
> (of course by hand,
> as much as it now fits) I currently get:
> Solaris11_b54-guest:
> [ X] CDROM works
> [partially] DMA works
> 
> Win9x guest
> [  ] CDROM works
> [ ] DMA works
> 
> ##############
> 
> (--)
> With the old Oct14 SUNWqemu package, on the other
> hand, we used to get:
> Solaris11_b46-guest:
> [ X] CDROM works
> [X] DMA works
> 
> Win9x guest
> [X] CDROM works
> [X] DMA works
> 
> It''s all just code and is therefore solvable.
> ... that is, literally, a.s.a.p.
> 
> 
> Regards,
> Martin
> p.s. Again, status from last week, the old Oct14
> patch merged into
> cvs20070102tue:
> http://www.opensolaris.org/jive/servlet/JiveServlet/do
> wnload/13-21321-81940-1888/qemu_cvs20070102tue__solari
> s__MB.gdiff.bz2
> Note: The other patches to be included are not yet
> inside, as we first
> need to get the basics running - reliably enough.
I understand that the code from 3 months ago is working with patches,
but the IDE/DMA stuff is very different now.

Ben
--
This message posted from opensolaris.org

Dear (qemu@)opensolaris community,

I played a bit with porting virtualbox.de to Nevada_x86.
But I''m losing ways too much time there and will stop now.
The ROI doesn''t justify the effort required (at least not, if one has
more urgent things to get finished, as most of us do).
It can''t be done in a "day".
Then: The speed improvement, if any, wouldn''t be noticable over
qemu/kqemu_userMode, except some brilliant person would additionally
port vbox''s kernel module, too:
http://www.virtualbox.de/wiki/Mac%20OS%20X%20build%20instructions
""  Running VirtualBox ?
<http://www.virtualbox.de/wiki/Mac%20OS%20X%20build%20instructions#RunningVirtualBox>


As mentioned elsewhere, the Mac OS X port of VirtualBox is work in
progress. Only the very basic GUI (VBoxBFE) is available and because the
supporting kernel extension (trunk/src/VBox/HostDrivers/Support
<http://www.virtualbox.de/browser/trunk/src/VBox/HostDrivers/Support>)
isn''t ported yet, the guest performance is quite terrible.

   1. VirtualBox must be instructed not to try use the missing kernel
      extension.

export VBOX_SUPLIB_FAKE="fake"  ""
    


Plus: VirtualBox _is_ in fact based on a tuned version of qemu.
You see it here:
http://virtualbox.de/browser/trunk/src/recompiler
http://virtualbox.de/browser/trunk/src/recompiler/vl.h

Where it reads:
""  /vl.h
<http://virtualbox.de/browser/trunk/src/recompiler/vl.h>
View revision:

Revision 1 <http://virtualbox.de/changeset/1>, 31.1 kB (checked in by
vboxsync, 0 seconds ago)

import

    * Property *svn:eol-style* set to /|native|/

Line 	 
1 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L1> 	//*/
2 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L2> 	/ * QEMU
System Emulator header/
3 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L3> 	/ * /
4 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L4> 	/ *
Copyright (c) 2003 Fabrice Bellard/
5 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L5> 	/ * /
6 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L6> 	/ *
Permission is hereby granted, free of charge, to any person obtaining a
copy/
7 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L7> 	/ * of
this software and associated documentation files (the "Software"), to
deal/
8 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L8> 	/ * in
the Software without restriction, including without limitation the rights/

  ""

So we all (at least on x86/x64) _will_ benefit from virtualbox having
gone GPL: Whether directly (if someone ever ports it to Solaris_x86), or
indirectly, just exactly because the qemu developers are striving to
re-import vbox''s  speed tricks and enhanced device matrix back into
vanilla qemu:
http://lists.gnu.org/archive/html/qemu-devel/2007-01/msg00168.html
""  For what I have seen in the sources, that''s based on
qemu, sligthly
modified

in order to be somehow "modular", thus allowing them to distribute
additional
proprietary extensions (list at  
http://www.virtualbox.org/wiki/Closed-source%20features )  ::


Sigh, I finally have to release the updated cvs20070120sat SUNWqemu pkgs
for SPARC and x86/x64 (which already were 98% ready, before I moved over
to vbox for two days).

FYI, below is a _tiny_ excerpt, from how far I progressed after two days
of vbox porting work.
I cannot continue at this point, because I ran out of time.
Nor did I  want to (because qemu runs quite fine already) :

include/VirtualBoxErrorInfoImpl.h:74: error: `nsresult'' does not name a
type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:47:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:86:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:148:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:
In member function `void
ProgressBase::protectedUninit(util::AutoLock&)'':
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:175:
error: request for member `setNull'' in
`((ProgressBase*)this)->ProgressBase::mInitiator'', which is of
non-class
type `int''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:
At global scope:
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:194:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:208:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:222:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:246:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:258:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:278:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:290:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:302:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:318:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:334:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:346:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:358:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:370:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:389:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:420:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:470:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:548:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:611:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:674:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:700:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:722:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:756:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:837:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:879:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:908:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1002:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1026:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1041:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1056:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1071:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1086:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1101:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1116:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1141:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1200:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1287:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1313:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h: In
static member function `static void ComStrongRef<C>::release(C*) [with C
IProgress]'':/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:188:
instantiated from `void ComPtrBase<C, RefOps>::release() [with C
IProgress, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:102:  
instantiated from `ComPtrBase<C, RefOps>::~ComPtrBase() [with C IProgress,
RefOps = ComStrongRef]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:107:
instantiated from `void std::_Destroy(_Tp*) [with _Tp ComPtr<IProgress,
ComStrongRef>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:120:
instantiated from `void std::__destroy_aux(_ForwardIterator,
_ForwardIterator, __false_type) [with _ForwardIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:152:
instantiated from `void std::_Destroy(_ForwardIterator,
_ForwardIterator) [with _ForwardIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/vector.tcc:122:
instantiated from `typename std::vector<_Tp, _Alloc>::iterator
std::vector<_Tp, _Alloc>::erase(__gnu_cxx::__normal_iterator<typename
_Alloc::pointer, std::vector<_Tp, _Alloc> >,
__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp,
_Alloc> >) [with _Tp = ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_vector.h:701:
instantiated from `void std::vector<_Tp, _Alloc>::clear() [with _Tp
ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:994:  
instantiated from here
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:61:
error: invalid use of undefined type `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ErrorInfo.h:31:
error: forward declaration of `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h: In
static member function `static void ComStrongRef<C>::addref(C*) [with C
= IProgress]'':
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:194:  
instantiated from `void ComPtrBase<C, RefOps>::safe_assign(C*) [with C
IProgress, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:105:  
instantiated from `ComPtrBase<C, RefOps>& ComPtrBase<C,
RefOps>::operator=(const ComPtrBase<C, RefOps>&) [with C =
IProgress,
RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:218:  
instantiated from `ComPtr<I, RefOps>& ComPtr<I,
RefOps>::operator=(const
ComPtr<I, RefOps>&) [with I = IProgress, RefOps =
ComStrongRef]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:247:
instantiated from `_OutputIterator std::__copy(_RandomAccessIterator,
_RandomAccessIterator, _OutputIterator, std::random_access_iterator_tag)
[with _RandomAccessIterator = ComPtr<IProgress, ComStrongRef>*,
_OutputIterator = ComPtr<IProgress, ComStrongRef>*]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:266:
instantiated from `_OutputIterator std::__copy_aux2(_InputIterator,
_InputIterator, _OutputIterator, __false_type) [with _InputIterator
ComPtr<IProgress, ComStrongRef>*, _OutputIterator = ComPtr<IProgress,
ComStrongRef>*]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:296:
instantiated from `_OutputIterator std::__copy_ni2(_InputIterator,
_InputIterator, _OutputIterator, __true_type) [with _InputIterator
ComPtr<IProgress, ComStrongRef>*, _OutputIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:317:
instantiated from `_OutputIterator std::__copy_ni1(_InputIterator,
_InputIterator, _OutputIterator, __true_type) [with _InputIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > > >,
_OutputIterator __gnu_cxx::__normal_iterator<ComPtr<IProgress,
ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:358:
instantiated from `_OutputIterator std::copy(_InputIterator,
_InputIterator, _OutputIterator) [with _InputIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > > >,
_OutputIterator __gnu_cxx::__normal_iterator<ComPtr<IProgress,
ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/vector.tcc:121:
instantiated from `typename std::vector<_Tp, _Alloc>::iterator
std::vector<_Tp, _Alloc>::erase(__gnu_cxx::__normal_iterator<typename
_Alloc::pointer, std::vector<_Tp, _Alloc> >,
__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp,
_Alloc> >) [with _Tp = ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_vector.h:701:
instantiated from `void std::vector<_Tp, _Alloc>::clear() [with _Tp
ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:994:  
instantiated from here
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:60:
error: invalid use of undefined type `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ErrorInfo.h:31:
error: forward declaration of `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h: In
static member function `static void ComStrongRef<C>::release(C*) [with C
= IVirtualBoxErrorInfo]'':
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:188:  
instantiated from `void ComPtrBase<C, RefOps>::release() [with C
IVirtualBoxErrorInfo, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:102:  
instantiated from `ComPtrBase<C, RefOps>::~ComPtrBase() [with C
IVirtualBoxErrorInfo, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1386:  
instantiated from here
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:61:
error: invalid use of undefined type `struct IVirtualBoxErrorInfo''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ErrorInfo.h:32:
error: forward declaration of `struct IVirtualBoxErrorInfo''
kmk[2]: ***
[/export/home/PROJECTS/VIRTUALBOX/000/vbox/out/SunOS.x86/release/obj/src/VBox/Main/VBoxC/ProgressImpl.o]
Error 1
kmk[2]: Leaving directory
`/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main''
kmk[1]: *** [pass_dlls_before] Error 2
kmk[1]: Leaving directory
`/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox''
kmk: *** [pass_dlls_before] Error 2
bash-3.00#


Regards,
Martin Bochnig

On a side-note: Precompiled vbox linux binaries might potentially work
under LXrun or inside a linux zone (at least qemu does).
However, since LKMs are not supported by those environments, you could
never benefit from vbox''s better performance (over qemu), as the speed
can only be achieved by the associated vbox''s kernel module.

VMware doesn''t run at all under LXrun (nor under Janus), because it
cannot even be started without its LKMs loaded.
>
>Regards,
>Martin Bochnig
>