On 07 Nov 2014, at 08:23, Riku Voipio wrote:
On Thu, Nov 06, 2014 at 01:43:13PM -0600, Tom Musta wrote:
When computing the upper address of a program segment, do not
subtract the
offset from the virtual address; instead compute the sum of the
virtual address
and the memory size.
Thanks,
The first program header does not necessarily start at offset 0. This change
corresponds to what the Linux kernel does in load_elf_binary().
Signed-off-by: Jonas Maebe
---
linux-user/elfload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/elfload.c b/linux-user
On 01 Mar 2006, at 00:37, Geoffrey Bayer wrote:
a nice little utility for x86 users with old machines (like Virtual
USB) would be Virtual MMX.
'd be a litl 56kilobyte power tool type utility allowing older
processors to mimic mmx operations
without the performance hit of a full virtual PC.
On 31 jul 2006, at 09:08, Jens Axboe wrote:
Applications running on the host can count on fsync doing the
right thing, meaning that if they call fsync, the data *will*
have made it to disk. Applications running inside a guest have
no guarantees that their data is actually going to make it
anyw
On 28 jun 2006, at 10:48, Tieu Ma Dau wrote:
[quote]
The basic idea is to split every x86 instruction into fewer simpler
instructions. Each simple instruction is implemented by a piece of
C code (see `target-i386/op.c'). Then a compile time tool
(`dyngen') takes the corresponding object f
On 11 apr 2006, at 17:25, Jim C. Brown wrote:
Actually, the reason ATi and NVidia don't open source their graphics
drivers is because they are both afraid that as soon as as they do
that, the other one will sue them into oblivion based on software
patents.
See http://wiki.ffii.org/Smirl041025E
On 11 apr 2006, at 17:05, Leonardo E. Reiter wrote:
what if I am a hardware vendor in a desperately competitive market,
such as say, video cards. Releasing my source code to the driver
would mean giving up some IP that allows me to surpass the
capabilities of my competitor for a few weeks
On 01 Apr 2006, at 22:51, Chris Wilson wrote:
and they have been an extensive user of software patents,
And how:
http://www.patent.gov.uk/patent/legal/summaries/2004/o29204.htm
"The invention in this case involves locating all of the input
registers in one data storage area, and all of t
On 28 sep 2005, at 16:29, Enric Pedascoll Quingles wrote:
i try to boot a fisical mac's partition with qemu but i don't obtain
good results
i have read in documentation files that the command is:
~#qemu -snapshot -hda /dev/(your disk)
i try several way with the same result
~#qemu -snapshot -
On 26 aug 2005, at 15:57, [EMAIL PROTECTED] wrote:
QEMU is working better from hour to hour :-)
Now I am looking for a way to get my data from the linux client to
the Win2K host. When I use the integrated smb I get a transfer rate
from about 15 KB :-(
the tftp is about 600 KBps and using Wi
On 18 aug 2005, at 18:44, Flavio Visentin wrote:
Is it possible to statically link the kqemu module into the linux
kernel 2.6.x)? (because I would like to disable loadable modules).
AFAIK no, at least because of the licence (not GPL). Technically there
would be broblems too, because you don't
On 14 May 2005, at 14:16, Fabrice Bellard wrote:
1) Do the CPUs share the same translation cache ?
2) The first implementation would use a cycle counter to schedule
between CPUs. Is it interesting to go further and to use a host
thread for each guest CPU at the expense of more locking overhead
On 01 May 2005, at 19:04, Paul Brook wrote:
This is not correct.
If the blr is not at the end of the function, things will break.
dyngen assumes the last instruction is the only return instruction in
the
function. This allows it to remove the blr insn and concatenate
multiple
functions together.
On 25 apr 2005, at 23:46, Massimo Dal Zotto wrote:
No, it has nothing to do with the speed of gettimeofday, which on my pc
takes only a few microsecons to execute.
Sorry, I had misread the original remark: I thought it was asking why
qemu suddenly ran (supposedly) 20% slower when calling gettimeof
On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
In the meantime until we find a better solution could you give us some
explanation on why using a microseconds clock from gettimeofday instead
of rdtsc the guest os clock runs always 20% slower?
Because a system call (which gettimeofday is) is very
On 22 apr 2005, at 17:41, [EMAIL PROTECTED] wrote:
Hello Jonas, here is the output of the command you gave me for this
function, does this help ?
It helps in the sense that it confirms my suspicion, although I don't
know why it creates such convoluted code. Maybe in order to have as
small code a
On 22 apr 2005, at 16:50, [EMAIL PROTECTED] wrote:
dyngen: ret or jmp expected at the end of op_bsfw_T0_cc
any ideas for that ? :)
gcc 4.0 apparently performs some sort of optimization which is
incompatible with qemu's object parser. Post the code of that routine
to have people see what the probl
On 17 Apr 2005, at 12:27, Paul Brook wrote:
Unfortunately it's not that simple. The push instruction may cause an
exception. Whatever optimizations you apply you've got to make sure
that the
guest state is still consistent when the exception occurs.
If we just concatenate the C code of the two pro
On 17 Apr 2005, at 10:21, John R. Hogerhuis wrote:
One thought would be to have a peephole optimizer that looks back over
the just translated basic block (or a state machine that matches such
sequences as an on-line algorithm) and match against common, known
primitive sequences, and replaces them w
19 matches
Mail list logo
