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: vb
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 ne
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 / Be
acts appears 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
ory.
If you say that this is reset should 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 gi
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:
H
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.
rect as it is now.
I hope 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
trunk/src/VBox/Devices/PC/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 Necas
t fine out of the box
... so I guess either the checksum 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 pro
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 Amsterda
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 t
be
removed.
It's easy enough to 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 < micha
n as a guest on the machine that it was licensed 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 a
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.header, "CUST", sizeof(cust), 1);
is no long
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 high
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 proble
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 change
sage when running 4.13 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 thin
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
mailto:michal.neca...@oracle.com>> wrote:
Hi Sameeh/Yuri,
Thanks for the patch. For
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 USBPc
is right. And years ago there 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
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
with
Hi Vincenzo,
Answer b) is correct. The short story is that all device emulation handlers are
runnable in user space, and some (many) are also implemented in kernel space.
Exactly which hardware accesses are handled where depends on the particular
device emulation, since some operations must b
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 / Stockholm
15, 2016 at 3:50 PM Michal Necasek < michal.neca...@oracle.com >
wrote:
Hi Vic,
It probably does not hurt to state that if you require real-time
responsiveness, you should *not* be using a VM. There are no latency
guarantees.
You forgot to mention the most relevant fact... which
Hi Vic,
It probably does not hurt to state that if you require real-time
responsiveness, you should *not* be using a VM. There are no latency
guarantees.
You forgot to mention the most relevant fact... which svn revision of
the OSE source code are you actually using? In fact you expec
CS and DS to save upper parts of FIP and FDP, so
FPU CS and 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 mailto:michal.neca...@oracle.com>>:
Hi Quentin,
Please add a bit more detail...
>
> > PS: Sorry for the previous mail that was accidently sent
> >
> > Regards,
> >
> > 2016-05-12 12:18 GMT+02:00 quentin buathier < qbuath...@tetrane.com >:
> >> Hi Michal,
> >>
> >> I can't now give a way to rep
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,
Yes, but with a caveat. Though to answer such questions for yourself, consider
creating a Windows or Linux VM with default settings, switching to the ICH9
chipset, and running some reasonably recent guest OS version. You'll see that
it uses a mix of IRQs and MSIs.
The caveat is that PCI IRQ d
On 2/18/2016 6:25 PM, Christian Svensson wrote:
>
> On Thu, Feb 18, 2016 at 4:35 PM, Michal Necasek
> mailto:michal.neca...@oracle.com>> wrote:
>
>According to my reading of it, qemu-img produced an rater suspect
> image. You have a supposedly 64K grain but af
Hi Christian,
You can read the specification yourself at
https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf
According to my reading of it, qemu-img produced an rater suspect
image. You have a supposedly 64K grain but after decompression, there is
only 49K of data. Th
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 Ams
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
and didn't find 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 me
h log file 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_i
setup, drivers as I used on PIIX3 ... not sure why ICH9 would take longer which
infact we expect it to be faster. Please comment.
Thanks.
On Fri, Jan 1, 2016 at 1:04 PM, Michal Necasek < michal.neca...@oracle.com >
wrote:
Not sure what you're referring to. Your dr
Here's a bone: Why did you post right after all of Oracle went on vacation?
- Michal
- Original Message -
From: myself...@opmbx.org
To: vbox-dev@virtualbox.org
Sent: Monday, January 4, 2016 8:02:57 PM GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [v
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) b
e glad to submit changes. N
ever submitted patches before, what is the process to do so ?
Ananth
On Tue, Dec 29, 2015 at 5:36 AM, Michal Necasek < michal.neca...@oracle.com >
wrote:
I can't say much without seeing exactly what you changed. But just two
questions:
- Do you ca
config & 0x80
>
> Thanks.
>
>
>
>
> On Mon, Dec 28, 2015 at 4:50 AM, Michal Necasek
> mailto:michal.neca...@oracle.com>> wrote:
>
>
> Hmm, that doesn't make sense to me. The mask bits do not overlap
> anything else. I'm looking at
Hmm, that doesn't make sense to me. The mask bits do not overlap anything else.
I'm looking at figure 6-9 on page 233 of the PCI 3.0 specification.
The code in MsiCommon.cpp is clear enough. Are you failing to set the fMsi64bit
flag when registering the MSI capability?
You probably also noti
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 possibl
--- 原始邮件
主题：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 reprod
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,
This is really confusing. You say VirtualBox crashes, but I see it reporting an
error caused by an assertion. You talk about CFGMR3QueryBytes() but the log
file shows failures due to CFGMR3AreValuesValid(). You talk about accessing
data from the "configuration xml file" but there is no such fun
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 p
gt; DevPciIch9.cpp / DevPCI.cpp.
Suggestions / recommendations would really help.
Thanks.
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 ge
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 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 ro
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 wro
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 Appl
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 ex
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 do
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 l
output? It's unfortunately not so easy
tell by looking at the actual source code.
Thanks,
Michal
On 3/26/2015 8:48 PM, Jung-uk Kim wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 03/26/2015 15:25, Michal Necasek wrote:
>> Sorry, I wasn&#
8:48 PM, Jung-uk Kim wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 03/26/2015 15:25, Michal Necasek wrote:
>> Sorry, I wasn't clear. By "what is the semantic difference" I meant
>> "under what circumstances will the conditional behave differentl
plicit conversion from pointer 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, compiler
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
Hi Rudolfs,
For Windows, yes, hardening was implemented in 4.3.14. For other host
platforms, hardening was introduced so long ago that I couldn't tell you when
exactly. Long before 4.3 for sure.
Michal
- Original Message -
From: rudolfs.bundu...@gmail.com
To: vbox-dev@virtualbox.
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 we
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 Virtu
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 t
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 guest-t
See https://www.virtualbox.org/ticket/10097 . This problem was fixed in 4.3.14
for Windows 7 guests and I have currently no reason to think Windows 8 is
different.
And yes, it's entirely normal that all local APICs in a system are mapped at
the same address. And those IPIs with vector zero
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 do
72 matches
Mail list logo
