Thanks, we'll look at this. At first glance the patch looks very reasonable,
and it's in line with the other configurable OEM strings.
- Michal
From: vbox-dev on behalf of Eckardt, Hendrik
via vbox-dev
Sent: Friday, September 22, 2023 10:56 AM
To:
Yes and no... the relevant bit is "Kernel trap at 0xff80195e7090, type
6=invalid opcode". So probably an unsupported instruction. But unfortunately
Apple does not log the opcode bytes at the faulting location, so it's anyone's
guess what the instruction might be.
The simulator probably
Yes, it's expected, and yes, it's a consequence of removing the "old style" 3D
support in VirtualBox 6.1.
Regards,
Michal
- Original Message -
From: mno...@startmail.com
To: vbox-dev@virtualbox.org
Sent: Thursday, January 2, 2020 11:34:49 AM GMT +01:00 Amsterdam /
in memory. So it
looks like it's a kind of caching of the operating system at this point.
It is not the "fast boot" option, which I already checked, so it's
probably something else. I need to dig on this.
Anyway, thanks for your help.
Il giorno mer 31 lug 2019 alle ore 16:01 Mich
ld be done, I'll try to re-run a set of
tests, may be I'm missing something. Consider that I'm running the VM with
--dbg option, not sure if this change something.
Thanks and let me know if you need more details on this.
Thanks
c
Il giorno mar 30 lug 2019 alle ore 10:11 Michal Necasek <
Can you provide a simple reproduction scenario? What does one have to
do to see this?
A VM reset should clear memory. A caveat is that a given guest OS may
not perform a full reset but only a soft reboot, which does not clear
memory.
- Michal
On 7/28/2019 10:15 PM, b38911 wrote:
Hi,
I think you must mean 5.2.28, not 5.2.26. If it really does not work for you
under 5.2.26 then please disregard the following.
This is a known but not understood problem, and there is a ticket about it:
https://www.virtualbox.org/ticket/18593
It only affects some USB devices, but
Thanks for the patch. Just out of curiosity, did you check if the code is ever
compiled in VirtualBox? I very much doubt we ever shipped that particular iPXE
driver or ever intended to, and users would have to work quite hard to make the
corresponding hardware appear in a VirtualBox VM.
that also makes sense ... maybe we even mean the same thing
anyways ... :-)
Cheers, Martin
On 05.02.2019 17:37, Michal Necasek wrote:
Hi Martin,
That's not what I'm saying. What I'm saying is that because my BIOS
image was run through biossums, I didn't see the dmidecode problem
because although
/DevPcBios.cpp#L1594
where the number and size of the DMI tables is updated) and therefore
the checksum must be re-calculated. The _SM_ table checksum is not
affected by these changes (as long as the _DMI_ checksum is correctly).
Cheers, Martin
On 05.02.2019 17:02, Michal Necasek wrote:
Hi Martin
is somehow valid by accident or there
is some code missing/different in the OSE repository.
Best regards, Martin
On 05.02.2019 15:48, Michal Necasek wrote:
Hi Martin,
The patch looks good, but I'm struggling to reproduce the problem.
The dmidecode utility in Ubuntu 18.04.1 and 18.10 (dmide
Hi Martin,
The patch looks good, but I'm struggling to reproduce the problem. The
dmidecode utility in Ubuntu 18.04.1 and 18.10 (dmidecode version 3.1 in
both) does not generate any complaints. So what exactly does?
Regards,
Michal
On 2/4/2019 12:16 PM, Martin Fleisz wrote:
The only requirement should be nested paging (aka RVI in AMD-speak), so that
translates to any AMD CPU less than about 10 years old.
- Michal
- Original Message -
From: th...@voicenet.com
To: vbox-dev@virtualbox.org
Sent: Tuesday, December 18, 2018 10:37:26 PM GMT +01:00
I'd like to point out that using DMI tables to detect available memory size is
a fundamentally flawed idea. For one thing, I really doubt that the table is
required to be present (or that VirtualBox is the only platform where it's
not). "Works fine with real hardware" only means "works with
remove the SLICTable/CustomTable aliases now if preferred.
I would leave that decision to the devs, since it would be a breaking change
for users currently using those config params.
Regards,
On Tue, Sep 18, 2018 at 3:56 PM Michal Necasek < michal.neca...@oracle.com >
wrote:
ensed on (this
was the motivation for the original custom table mechanism for SLIC
passthrough for Windows 7/8 - see
https://www.virtualbox.org/ticket/9231). Reducing the detection surface
for dynamic analysis of malware that actively detects sandboxes is another.
Regards,
On Tue, Sep 4, 2018 at 10:45 PM
Hi,
Thanks for the patch! I quickly looked over it and it looks to me that
the behavior of existing VMs with the
VBoxInternal/Devices/acpi/0/Config/CustomTable keys set will subtly
change because the call to
acpiR3PrepareHeader(pThis, , "CUST", sizeof(cust), 1);
is no longer done and
Hi Alexander,
Thanks for the report.
The bug is real, though the fix is unlikely to be quite correct. It's
not something your porting introduced (we've seen it too, but extremely
sporadically), but it's very likely that in your environment the
probability of hitting the bug is much
Sorry, no. There is a difference between "supported" and "happens to work".
Much like Windows XP itself didn't stop working when Microsoft's support for it
ended, VirtualBox still happens to work on Windows XP and Server 2003 hosts.
But it is not officially supported (i.e. if you have a
On 1/10/2018 12:13 AM, Kalogrianitis Socratis wrote:
The problem is that the USB controller type does not map to USB specification
revisions at all.
Just trying to get it as close to the GUI as (un-confusingly) possible. Your
average Joe is going to know bupkis about OHCI or EHCI, or 1.1
Hi Socratis,
The idea is good, but your suggestion is not much less confusing than
the current state. The problem is that the USB controller type does not
map to USB specification revisions at all.
The USB 1.0 specification defined low-and full-speed devices. USB 1.1
made minor
as guest
Hi Michal,
On 26-07-17 17:18, Michal Necasek wrote:
>
> Hi Hans,
>
> The message is harmless. It's triggered because VirtualBox currently does
> not expose the host CPU microcode revision to guest operating systems. I
> don't think we want to do that without fully
patch.
See https://www.virtualbox.org/wiki/Contributor_information for details.
- Michal
On 7/13/2017 2:05 PM, Sameeh Jubran wrote:
On Thu, Jul 13, 2017 at 2:59 PM, Michal Necasek
<michal.neca...@oracle.com <mailto:michal.neca...@oracle.com>> wrote:
Hi
Hi Sameeh/Yuri,
Thanks for the patch. For us to actually accept it, the patch needs to
be either explicitly licensed under MIT or submitted by someone with a
signed OCA (Oracle Contributors Agreement).
Do you happen to know if the patch also solves interoperability
problems with
here was a more strict dependency to an old
>> version of gcc from code in src/recompiler. This has been fixed long time
>> ago.
>> Newer versions of MingW will most likely work but are not tested ATM.
>> Kind regards,
>> Frank
>> On Montag, 26. Juni 2017 10
Hi Alexander,
Could you please describe your use case, or rather how we can
reproduce the problem? This is not code we want to change without
precisely understanding why it needs to change and testing the behavior.
Also, why are you using the recompiler at all? On a typical system
Expecting someone to jump at the patches within 2 days after a major release
may be just a little unrealistic.
- Michal
- Original Message -
From: n...@gmx.com
To: vbox-dev@virtualbox.org
Sent: Friday, July 15, 2016 7:21:42 AM GMT +01:00 Amsterdam / Berlin / Bern /
Rome /
DS are ignored.
Ref 2: Like the ref 1, xrstor doesn't restore FPU CS and DS
Regards
2016-05-13 15:39 GMT+02:00 Michal Necasek <michal.neca...@oracle.com
<mailto:michal.neca...@oracle.com>>:
Hi Quentin,
Please add a bit more detail... we're on a 64-bit system the whole
nt
> >
> > Regards,
> >
> > 2016-05-12 12:18 GMT+02:00 quentin buathier < qbuath...@tetrane.com >:
> >> Hi Michal,
> >>
> >> I can't now give a way to reproduce the bug. I'll send an executable if I
> >> manage to repro
Hi Quentin,
Thank you for the patch!
Unfortunately (?) I can't reproduce the problem that was originally
fixed. Could you please provide a bit more information? What's the host
OS, guest OS, host CPU type? How to reproduce the problem?
Regards,
Michal
On 5/12/2016 11:26 AM,
On 2/18/2016 6:25 PM, Christian Svensson wrote:
>
> On Thu, Feb 18, 2016 at 4:35 PM, Michal Necasek
> <michal.neca...@oracle.com <mailto:michal.neca...@oracle.com>> wrote:
>
>According to my reading of it, qemu-img produced an rater suspect
> image. Y
Yes, it is an automatically generated file, a COM wrapper based on the IDL
description. It does make navigating the source code a bit harder.
- Original Message -
From: rudolfs.bundu...@gmail.com
To: vbox-dev@virtualbox.org
Sent: Wednesday, February 3, 2016 10:35:33 AM GMT +01:00
It doesn't *need* to be in R0 context. You can disable the R0 device
bits and see what that does to performance. Hint: Switching R0->R3->R0
takes a lot more time than not switching at all.
Keep in mind that with hardware virtualization, guest code effectively
runs in the host's R0 context
any
change in this context with MSI code between VirtualBox 5.0.10 and VirtualBox
5.0.14
Thanks.
On Mon, Jan 18, 2016 at 8:33 AM, Michal Necasek < michal.neca...@oracle.com >
wrote:
Hi Ananth,
Sorry for taking so long. Unfortunately I was not able to merge the patch
becau
along with the source code, requesting to submit under
MIT License. Let me know if I missed anything.
Ananth
On Wed, Dec 30, 2015 at 2:52 PM, Michal Necasek < michal.neca...@oracle.com >
wrote:
Please take a look at this:
https://www.virtualbox.org/wiki/Contributor_infor
Not sure what you're referring to. Your driver specifically? Or the entire
guest OS? In general, there is not known to be any significant performance
difference between the chipsets either way. Specific devices might perform
faster with ICH9 (e.g. xHCI with MSIs is faster than xHCI without)
g & 0x80
>
> Thanks.
>
>
>
>
> On Mon, Dec 28, 2015 at 4:50 AM, Michal Necasek
> <michal.neca...@oracle.com <mailto:michal.neca...@oracle.com>> wrote:
>
>
> Hmm, that doesn't make sense to me. The mask bits do not overlap
> anything else
I'm sure this solves a real problem, unfortunately I'm also certain this patch
has absolutely zero chance of being accepted the way it is.
The code you're changing is currently under development (and known to be less
than perfect). What revision exactly is the patch intended for? It's
--
主题：Re: [vbox-dev] GDT entries syncing between qemu mode & raw mode bug
发件人：Michal Necasek
收件人：vbox-dev@virtualbox.org
抄送：
This doesn't look unreasonable, but one important thing is missing: How exactly
do we reproduce the problem? If we can't reproduce it, we can't verify t
This doesn't look unreasonable, but one important thing is missing: How
exactly do we reproduce the problem? If we can't reproduce it, we can't verify
that the patch does anything useful. I'm sure you know that "linux" is not a
particularly accurate description of the guest OS.
Thanks,
Please do not use the vbox-dev mailing list for tech support. There
are already ample avenues for support -- bug tracker, forums, IRC.
This is a mailing list for developers, so bug reporting would be
relevant if there was a patch or a detailed suggestion for a fix. Please
do not consider
Hi Ananth,
PCIDevSetDWord in the device won't do it, that's expected. It will get
rewritten.
I don't think VirtualBox supplies any device with so many BARs so it's entirely
possible that something isn't working. The trouble is that you have your code +
ours, and we only have our code, so
.
On Wed, Aug 19, 2015 at 7:51 AM, Michal Necasek michal.neca...@oracle.com
wrote:
Hi Ananth,
PCIDevSetDWord in the device won't do it, that's expected. It will get
rewritten.
I don't think VirtualBox supplies any device with so many BARs so it's entirely
possible that something
On 8/6/2015 3:18 PM, Maarten Hoes wrote:
Now what I dont understand is why such a setting should/does break
bridged to wifi networking - especially when at the same time NAT does
work as expected with that setting enabled.
I don't know if this is obvious or not, but with NAT the WiFi router
And there's one more thing -- if you just say I want to write a PDM
device, no one will be terribly interested. If you explain what you
want to achieve, people might be more willing to help when it intersects
with their own interests.
Michal
On 6/26/2015 3:22 PM, Klaus Espenlaub
SIP = System-in-Package? Session Initiation Protocol? Something else?
I hope you're not trying to discuss something covered by an Apple NDA
on a public mailing list :)
- Michal
On 6/22/2015 8:56 PM, Louis King Jr wrote:
I was wondering what if anything anyone has to say about
In general, some slowdown is expected. It's normal that scheduling in
SMP systems has higher latency. The short story is that
context-switching back and forth on a single CPU/core is faster than
waking up another CPU, going to sleep, and being woken up again when the
work is done.
What
In addition to what Alexander already said (i.e. Qt is not technically usable
as an IPRT replacement at all), there is another major reason: We have no
intention of making core VirtualBox depend on Qt. The Qt-based GUI is only one
(albeit very important) aspect of VirtualBox.
And I highly
Rudolfs,
The recompiler crash you had there is not the same as what we just
debugged but it is similar.
The difference is that what we saw only affected 32-bit Windows. It
only happened with release builds, not debug builds.
The problem was a bug in the gcc compiler triggered by a
The question isn't whether a compiler can warn. The question is, why should it?
What you quoted doesn't contradict what Frank said. There is a very well
defined pointer to bool conversion. So what's the problem? Or in other words,
what is the semantic difference between
if (ptr)
and
to
bool
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/26/2015 14:03, Michal Necasek wrote:
The question isn't whether a compiler can warn. The question is,
why should it?
Although this specific code has absolutely no problem, compilers are
not smart enough to read authors' mind yet
If you're talking about Windows host, that is true... but I thought you were
trying to debug something on a Linux host? In which case the hardening approach
is completely different and with sufficient privileges, you can run and debug
anything you want.
- Original Message -
can't
Hi,
Unfortunately this patch not only doesn't fix anything, it actively breaks the
code. If you look at the comments at the top of the file, you'll see that the
X/Y movement deltas (dX/dY) are 9-bit values, not 8-bit. So yes, -255 and 255
*will* fit and are not out of range.
You are
Hello,
This is all very interesting, but what does it have to do with
VirtualBox development? If you want to ask questions about TinyOS,
you've definitely got the wrong mailing list. If you want to ask
questions about VirtualBox development then please ask specific
questions about
Hi Dave,
Thanks for the patch! I'll take a look at it in detail soon (at first glance it
looks very reasonable). However, I'm not going to commit anything unless I can
run at least the most basic verification that the code does something useful.
So what can I use as a testcase so check that
When every user sets the importance of their problem to major or critical,
the priorities completely lose meaning. Sad but true.
Regards,
Michal
- Original Message -
From: kulakov.i...@gmail.com
To: vbox-dev@virtualbox.org
Sent: Saturday, January 31, 2015 2:39:29 PM GMT +01:00
Hardening is supposed to protect against a malicious user on the host
(in other words, privilege escalation). A compromised host is a
compromised host and there's nothing we can really do about it, but that
is what hardening is in fact supposed to prevent.
Hardening is unrelated to
Hi,
I had a look at your patches regarding I/O port registration but they are
unfortunately not correct. You seem to have a misconception of how port I/O
works in the x86 architecture and assume that it behaves much like memory.
That's not the case.
You already suspected that you were
58 matches
Mail list logo
