<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Rūdolf,
<div class="moz-cite-prefix">On 31.03.2015 16:52, Rūdolfs Bundulis
wrote:<br>
</div>
<blockquote
cite="mid:CAHtFw63a9-FKLhJwT_OxBN4NrtRpAyvWQnrvNPdMQER8ovweCg@mail.gmail.com"
type="cite">
<div dir="ltr">HI Michal,
<div><br>
</div>
<div>> <span style="font-size:12.8000001907349px"> You could
sprinkle a few 'Assert(env == cpu_single_env)' statements
in </span><span style="font-size:12.8000001907349px">the
recompiler code and see if any of them hit.</span></div>
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div>thanks for the info, I'll try that out. Yeah, debugging the
debug build with gdb under Windows is kind of uncomfortable,
under Linux it went much smoother. If Linux runs fine I'm not
that desperate about fixing the Windows crash but then again -
we had an idea that we could make something similar to the
OpenGL service for Direct3D guest-to-host acceleration (of
course if both guest and host are Windows with matching
Direct3D version support), that should be more snappy than
wine translating stuff into OpenGL. If we actually achieve
that then I guess you could be interested into merging that
in. Thanks again.</div>
</div>
</blockquote>
Replying off the list because I don't want to discuss this much in
public at this point - might attract people with the wrong
intentions...<br>
<br>
There's the VMSVGA2 device emulation (these days 2D+3D) contribution
which might do most of what you need. VMware specified the 3D
interface along Direct3D concepts (which means that e.g. Linux VMs
need to get their shaders translated), which possibly helps a great
deal.<br>
<br>
The catch is - we don't have a driver for Windows guests, as the
contribution focused on the raw device compatibility and the company
doing the funding wasn't interested at all in Windows (or even Linux
- but as the Linux VMSVGA2 drivers are open source they work nicely
and have been tested).<br>
<br>
I would be very surprised if VMware's driver for Windows (should be
included in their tools installer) would work in VirtualBox. We
never tried, and probably won't try as we're afraid of legal issues,
leave alone that it'd be embarrassing to refer to the biggest
competitor for getting drivers. Are you interested in convincing our
WDDM driver to do 2D/3D with VMSVGA2 device backing - either as a
separate, standalone driver or making our current one talk to both
VBoxVGA and VMSVGA2?<br>
<br>
Regards,<br>
Klaus<br>
<blockquote
cite="mid:CAHtFw63a9-FKLhJwT_OxBN4NrtRpAyvWQnrvNPdMQER8ovweCg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Best Regards,</div>
<div>Rudolfs Bundulis</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-03-31 17:40 GMT+03:00 Michal
Necasek <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:michal.necasek@oracle.com" target="_blank">michal.necasek@oracle.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Rudolfs,<br>
<br>
The recompiler crash you had there is not the same as what
we just<br>
debugged but it is similar.<br>
<br>
The difference is that what we saw only affected 32-bit
Windows. It<br>
only happened with release builds, not debug builds.<br>
<br>
The problem was a bug in the gcc compiler triggered by a
large amount<br>
of local variables in a function. One or more registers
saved on the<br>
stack got destroyed.<br>
<br>
In the recompiler code, generally it must hold that env ==<br>
cpu_single_env. If that is not true then 'env' probably got
destroyed.<br>
Note that gdb will likely not display 'env' correctly.<br>
<br>
You could sprinkle a few 'Assert(env == cpu_single_env)'
statements in<br>
the recompiler code and see if any of them hit.<br>
<br>
<br>
Regards,<br>
Michal<br>
<div>
<div class="h5"><br>
On 3/31/2015 3:40 PM, Rūdolfs Bundulis wrote:<br>
> Hi Klaus,<br>
><br>
> > Did you by any chance extend the CPUCTX
struct or any other data<br>
> > structure which might be used by the
recompiler? Just hours ago we<br>
> > tracked down a MingW gcc bug in the very same
area which smells very<br>
> > similar...<br>
><br>
> No, they only thing I've done is provided an
IFramebuffer<br>
> implementation, I haven't touched any internals. I
mean, so far all I<br>
> was doing was based on the SDK API, the init call
now is the first thing<br>
> I'm using from the actual source tree. But
something very bad could be<br>
> wrong with my implementation that could cause this,
as I said, the<br>
> weirdest thing is that when running under Windows
with a debug build<br>
> VirtualBox frontends never hit the recompiler but
my code does. Now that<br>
> I have found a solution for Linux I'll do full
testing and see if it<br>
> works fine - if it does , the issue is Windows
only, if not, I should be<br>
> able to debug. Simply for me it's really hard to
understand what is<br>
> going on in the recompiler code under Windows since
I'm not familiar<br>
> with Qemu. I don't know if you had time to look at
it - but I at least<br>
> posted the longjmp stack trace here<br>
> <a moz-do-not-send="true"
href="https://www.virtualbox.org/pipermail/vbox-dev/2015-February/012872.html"
target="_blank">https://www.virtualbox.org/pipermail/vbox-dev/2015-February/012872.html</a>,<br>
> is it similar to what you have found?<br>
><br>
><br>
>> "Regular" API clients don't need this, they can
happily live with the<br>
>> implicit, delayed initialization which disables
some functionality.<br>
>> That's why it makes no sense to talk about it
in tstVBoxAPIXPCOM.cpp -<br>
>> it's happily working.<br>
><br>
> Sorry,I did not quite understand - so the fact I
was running fine<br>
> without it on Windows is because it is needed only
for XPCOM and not COM<br>
> or was I just lucky?<br>
><br>
><br>
> Best Regards,<br>
> Rudolfs Bundulis<br>
><br>
> 2015-03-31 16:16 GMT+03:00 Klaus Espenlaub <<a
moz-do-not-send="true"
href="mailto:klaus.espenlaub@oracle.com">klaus.espenlaub@oracle.com</a><br>
</div>
</div>
> <mailto:<a moz-do-not-send="true"
href="mailto:klaus.espenlaub@oracle.com">klaus.espenlaub@oracle.com</a>>>:<br>
<div>
<div class="h5">><br>
> Rūdolfs,<br>
><br>
> On 31.03.2015 13:22, Rūdolfs Bundulis wrote:<br>
> > Hi,<br>
> ><br>
> > ok I found the root issue - my code did
not call RTR3InitExe(argc,<br>
> > &argv, 0) since I built the
application only from looking at the API<br>
> > interfaces and was not aware that I need
to do this (actually maybe it<br>
> > makes sense to include a comment int the
xpcom tstVBoxAPIXPCOM.cpp<br>
> > sample about this?).<br>
><br>
> "Regular" API clients don't need this, they can
happily live with the<br>
> implicit, delayed initialization which disables
some functionality.<br>
> That's why it makes no sense to talk about it
in tstVBoxAPIXPCOM.cpp -<br>
> it's happily working.<br>
><br>
> Only API clients actually running VMs inside
them absolutely need the<br>
> full initialization as the very first thing,
otherwise they won't work.<br>
><br>
> > Now after I've taken a closer look to the
frontends<br>
> > I see that all them call the
initialization function the first thing. I<br>
> > added it and my IFrambuffer implementation
started to get invocations.<br>
><br>
> Pretty sure that e.g. VBoxManage.cpp only does
it because in uses quite<br>
> some runtime functionality, and doesn't want to
run any risk (in the old<br>
> days it was far less "optional" to do the
initialization).<br>
><br>
> > Since my Windows code worked fine without
it - should I add it to<br>
> > Windows as well? Any chance it is
responsible for the weird recompiler<br>
> > longjmp crash I get? Thanks in advance.<br>
><br>
> Did you by any chance extend the CPUCTX struct
or any other data<br>
> structure which might be used by the
recompiler? Just hours ago we<br>
> tracked down a MingW gcc bug in the very same
area which smells very<br>
> similar...<br>
><br>
> Regards<br>
> Klaus<br>
> ><br>
> > Best Regards,<br>
> > Rudolfs Bundulis<br>
> ><br>
> ><br>
> ><br>
</div>
</div>
> ><a moz-do-not-send="true" href="tel:2015-03-30"
value="+37120150330">2015-03-30</a> <tel:<a
moz-do-not-send="true" href="tel:2015-03-30"
value="+37120150330">2015-03-30</a>> 2:42 GMT+03:00
Rūdolfs Bundulis<br>
> <<a moz-do-not-send="true"
href="mailto:rudolfs.bundulis@gmail.com">rudolfs.bundulis@gmail.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:rudolfs.bundulis@gmail.com">rudolfs.bundulis@gmail.com</a>><br>
> > <mailto:<a moz-do-not-send="true"
href="mailto:rudolfs.bundulis@gmail.com">rudolfs.bundulis@gmail.com</a><br>
<div>
<div class="moz-signature">> <mailto:<a
moz-do-not-send="true"
href="mailto:rudolfs.bundulis@gmail.com">rudolfs.bundulis@gmail.com</a>>>>:<br>
> ><br>
> > Hi,<br>
> ><br>
> > I compiled debug version of 4.3.26
and tried my code against it -<br>
> > now the log has a much nicer assert
message just before it ends:<br>
> ><br>
> > 00:00:55.619996 TM: GIP - u32Mode=1
(SyncTSC) u32UpdateHz=83<br>
> > 00:00:55.652313 TM:
cTSCTicksPerSecond=0xa0861eba (2 693 144 250)<br>
> > fTSCVirtualized=true
fTSCUseRealTSC=false<br>
> > 00:00:55.652322 TM:
fMaybeUseOffsettedHostTSC=true<br>
> > TSCTiedToExecution=false
TSCNotTiedToHalt=false<br>
> > 00:00:55.652373<br>
> > 00:00:55.652376 !!Assertion Failed!!<br>
> > 00:00:55.652378 Expression:
<NULL><br>
> > 00:00:55.652380 Location :<br>
> ><br>
>
/home/rudolfs/VirtualBox-4.3.26/src/VBox/VMM/VMMR3/TM.cpp(576)
int<br>
> > TMR3Init(PVM)<br>
> > 00:00:55.652508 Failed to create
timer, u32Millies=10<br>
> > rc=VERR_NOT_SUPPORTED.<br>
> ><br>
> > I put a breakpoint in TM.cpp:576, and
it seems that I am failing<br>
> > because of the code in
RTTimerCreateEx():<br>
> ><br>
> > /*<br>
> > * We need the signal masks to
be set correctly, which they<br>
> > won't be in<br>
> > * unobtrusive mode.<br>
> > */<br>
> > if (RTR3InitIsUnobtrusive())<br>
> > return VERR_NOT_SUPPORTED;<br>
> ><br>
> > What is unobtrusive mode and what
signal masks do I need to set?<br>
> > I'll have a look at what is done in
the frontends, but I<br>
> guess that<br>
> > you guys here can explain it in more
detail.<br>
> ><br>
> > Best Reagrds,<br>
> > Rudolfs Bundulis<!-- This signature was generated by the MyDesktop Oracle Business Signature utility version 4.2 -->
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>