On Monday 03 December 2007, Samuel Thibault wrote:
Anthony Liguori, le Mon 03 Dec 2007 09:54:47 -0600, a écrit :
Have you done any performance testing? Buffered IO should absolutely
beat direct IO simply because buffered IO allows writes to complete
before they actually hit disk.
Since
Yes, librt is providing posix-aio, and librt coming with GNU libc uses
threads.
But if I remember correctly librt coming with RHEL uses a mix of threads
and linux kernel AIO (you can have a look to the .srpm of libc).
BTW, if everyone thinks it could be a good idea I can port block-raw.c
to
Well, let's separate a few things. QEMU uses posix-aio which uses
threads and normal read/write operations. It also limits the number of
threads that aio uses to 1 which effectively makes everything
synchronous anyway.
This is a bug. Allegedly this is to workaround an old broken glibc, so
Log message:
Always create an SD bdrv, so that PXA and OMAP boards can boot with
no card inserted again. Eventually SD, CDROM and floppy should all
be registered conditionally depending on machine.
This seems the wrong way to solve this problem. The SD emulation should be
On Tuesday 04 December 2007, andrzej zaborowski wrote:
On 04/12/2007, Paul Brook [EMAIL PROTECTED] wrote:
Log message:
Always create an SD bdrv, so that PXA and OMAP boards can boot
with no card inserted again. Eventually SD, CDROM and floppy should
all be registered
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch enforces that the sh4 target is 32 bit to prevent
qemu to expand incorrectly to a 64
target_phys_addr_t = physical address of the host
ram_addr_t = physical address of the guest
No, target_phys_addr_t is the physical address of the emulated target
system. For host addresses ram_addr_t, unsigned long or even int is
used. Host addresses are of course virtual, Qemu is a
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch enforces that the sh4 target is 32 bit to prevent qemu
to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need
to be
I think T2 may need to store host addresses as well. To be frank, I
don't understand that part but there is a compiler warning on a 64
bit host.
If you're thinking of the warnings in op_goto_tb0, these are actually due to
tb-tb_next having the wrong type.
In general all access to target
What solution do you prefer for the opaque types? I have used the simple:
-void *args[MAX_ARGS];
+intptr_t args[MAX_ARGS];
A more portable and clean solution would be this:
-void *args[MAX_ARGS];
+union
+{
+void* ptr;
+int i;
+}
On Thursday 29 November 2007, André Przywara wrote:
-qemu_get_be32s(f, depth);
+qemu_get_be32s(f, (uint32_t *)depth);
This is almost certainly the wrong way to fix this.
Paul
On Friday 30 November 2007, Blue Swirl wrote:
On 11/30/07, Jeremy C. Reed [EMAIL PROTECTED] wrote:
On Fri, 30 Nov 2007, Jeremy C. Reed wrote:
The pkgsrc build system has several patches against qemu 0.9.0.
They are at:
What is current situation with Host ARM and guest X86?
Should work with a bit of hacking.
Of course it's not likely to be particularly fast, even on relatively high-end
xscale hardware.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 23:22:12
Modified files:
target-arm : helper.c
Log message:
Thumb semihosting fixes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 23:35:08
Modified files:
. : Makefile Makefile.target
hw : omap_mmc.c pl061.c pl181.c primecell.h
pxa2xx_mmci.c sd.c sd.h ssd0323.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 23:55:53
Modified files:
hw : pxa2xx_mmci.c
Log message:
Fix SD init arguments.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_mmci.c?cvsroot=qemur1
Then I took a closer look to the code, to ensure I was not wrong.
The PowerPC 32 on 64 bits hosts is implemented the same way that the
specification says a PowerPC in 32 bits mode should be. Then higher bits
are not garbage. They are what the PowerPC specification say they should
be (apart if
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 03:09:07
Modified files:
hw : arm-misc.h arm_gic.c armv7m_nvic.c stellaris.c
Log message:
ARMv7-M SysTick fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 03:13:04
Modified files:
. : Makefile.target
hw : arm-misc.h armv7m_nvic.c stellaris.c
Added files:
hw : stellaris_enet.c
Log message
I think what you mean is that they work the way that ppc64 is defined, to
remain compatible with ppc32. IMHO this is entirely irrelevant as we're
emulating a ppc32. You could replace the high bits with garbage and
nothing would ever be able to tell the difference.
PowerPC is a 64 bits
The old code before the patch is obviously broken. It's mixing 64-bit
(ppc_gpr_t) and 32-bit (target_ulong) values.
It seems you do not understand that what was done was correct. It's not
mixing two different types. GPR are of ppc_gpr_t type and should be
displayed this way.
It's not
Furthermore this patch was made in a brainless way, it will be reverted
asap.
If you think there is a bug in someone else code, submit it a patch, if
it's cleaver and addresses a real bug (which is not the case here) it
will be accepted and merged.
The old code before the patch is obviously
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/23 17:33:13
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Fix ppc32 register dumps on 64-bit hosts.
CVSWeb URLs
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/23 16:54:00
Modified files:
. : exec.c
Log message:
Fix va_list reuse in cpu_abort.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.115r2
There is a chance that when using unix or dynticks clock, the
signal arrives when no cpu is executing.
I've seen similar stalls, but not managed to track down the source. Your
analysis seems correct.
+ /* cause an interrupt in the first cpu that tries to start running */
+ if (!env)
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/23 02:11:10
Modified files:
. : cpu-exec.c
Log message:
Fix TB chaining for exceptions.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/21 15:32:12
Modified files:
fpu: softfloat.c
Log message:
Fix typo in softfloat code.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemur1
Ok the problem comes from bad copypaste. Please find a patch below that
fixes the problem on MIPS.
av = float64_val(a);
-bv = float64_val(a);
+bv = float64_val(b);
Applied, thanks for tracking this down. Sorry about the breakage.
Paul
On Monday 19 November 2007, Samuel Thibault wrote:
Samuel Thibault, le Mon 19 Nov 2007 15:20:16 +, a écrit :
Qemu currently uses 6 65k tables of pointers for handling ioports, which
makes 3MB on 64bit machines. There's a comment that says XXX: use a two
level table to limit memory
there might be
some issues in the ohci/uhci because they currently assume only
isochronous transfers are async.
That's definitely incorrect. The USB mass storage emulation uses async bulk
transfers.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/18 14:36:09
Modified files:
. : Makefile
hw : devices.h irq.c stellaris.c
Added files:
hw : stellaris_input.c
Log message
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/18 14:33:24
Modified files:
fpu: softfloat-specialize.h softfloat.c softfloat.h
target-arm/nwfpe: double_cpdo.c single_cpdo.c
target-m68k: helper.c op.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/18 14:40:35
Modified files:
hw : gumstix.c
Log message:
Fix connex board init routine.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gumstix.c?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/18 21:12:37
Modified files:
. : Makefile
Log message:
Fix out of tree builds.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.133r2=1.134
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/18 21:54:57
Modified files:
hw : ssd0323.c
Log message:
SSD0323 vertical incrememnt mode.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ssd0323.c?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/19 02:38:22
Modified files:
hw : stellaris.c
Log message:
Fix typo in error message.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/stellaris.c?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/17 14:53:06
Modified files:
target-mips: fop_template.c op.c op_helper.c
Log message:
Fix int/float inconsistencies.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/17 15:32:38
Modified files:
hw : sd.c
Log message:
sd.c build fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.c?cvsroot=qemur1=1.4r2=1.5
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/17 17:14:51
Modified files:
. : Makefile Makefile.target arm-semi.c block-raw.c
block.c block.h cocoa.m console.c cpu-defs.h
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/17 17:35:54
Modified files:
audio : alsaaudio.c coreaudio.c dsoundaudio.c
fmodaudio.c
Log message:
Remove stray uses of vl.h.
CVSWeb URLs:
http
I just applied a patch that breaks up and removes vl.h
My strategy (as discussed previously) is to split the contents along
functional lines, and hardware split along bus/machine boundaries..
In order to avoid lots of little header files it makes fairly extensive use of
opaque structure
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/18 01:44:38
Modified files:
. : block-vvfat.c block.c console.c dyngen.c
elf_ops.h i386-dis.c loader.c monitor.c osdep.c
qemu
Then, I choosed to replace 'inline' by 'always_inline', which is more
invasive but have less risks of side effects. The diff is attached in
always_inline.diff.
The last thing that helps solve the problem is to change the inlining
limits of gcc, at least to compile the op.o file.
Presumably
On Friday 16 November 2007, Lauro Ramos Venancio wrote:
Hi all,
I'm creating a project in Sourceforge to maintain a bleeding edge
version of QEMU for ARM-EABI programs. The main idea is to keep up to
date the ARM EABI patches.
Why don't you just fix whatever's wrong with normal qemu?
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/15 19:04:09
Modified files:
. : vl.c
Log message:
Init dumb display if no others available.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1
So gcc puts the zero constant to .rodata.cst8 and generates code to
load the zero value from this location. This method is not supported
by dyngen for Sparc, but ARM uses similar method for all (?)
constants.
Not quite. ARM puts constant pools inline with the code, not in rodata. This
is a
This means that time_t had to be tracked down on varying architectures
to find the size and there was an assumption made that time_t is 32 bits
- which isn't true for all targets. The next problem is that if the
target is 32 bits but the host is 64 bits then there's a sign extension
problem
time_t is only one example. There are similar problems with the
handling of struct target_iovec. There are still other places with
similar problems.
Yes, special casing can work. There's the possible problem of value
truncation when moving between 32 and 64 bits.
My point is that I
On Sunday 11 November 2007, Blue Swirl wrote:
On 11/11/07, Paul Brook [EMAIL PROTECTED] wrote:
The attached patch starts splitting vl.h up a bit.
I understand Fabrice's concern about small files, but I think this is
the right direction.
Ok, I'll try to keep them to a minimum. e.g. I can
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 11:43:27
Modified files:
. : block-raw.c
Log message:
block-raw/kqemu fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.26r2=1.27
On Sunday 11 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch includes exec-all.h in block-raw.c when QEMU_IMG is
not defined to avoid the following implicit declaration :
I applied a slightly different version, thanks.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 12:02:33
Modified files:
hw : mips_r4k.c
Log message:
mips_r4k warning fixes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.52r2
On Sunday 11 November 2007, Carlo Marcelo Arenas Belon wrote:
as shown by the following warning when compiling HEAD :
qemu/target-sh4/translate.c: In function `cpu_sh4_reset':
qemu/target-sh4/translate.c:139: warning: overflow in implicit constant
conversion
...
the following patch
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 14:36:36
Modified files:
target-arm : translate.c
Log message:
Fix msr_mask.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemur1=1.58r2
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 14:52:02
Modified files:
. : gdbstub.c
Log message:
Fix format mismatch.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.69r2=1.70
+#undef NULL
+#define NULL ((void *)0)
Absolutely not.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/10 16:34:47
Modified files:
hw : integratorcp.c pl011.c pl050.c pl080.c pl110.c
pl181.c pl190.c smc91c111.c
Log message:
Fix 64-bit host printf
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/10 17:38:00
Modified files:
. : arm-dis.c dis-asm.h
Log message:
Update ARM disassembler.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/arm-dis.c?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/10 18:03:23
Modified files:
. : Makefile.target vl.c vl.h
Added files:
hw : dummy_m68k.c
Log message:
Add dummy m68k board.
CVSWeb URLs:
http
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/10 19:21:30
Modified files:
hw : dummy_m68k.c
Log message:
Fix build failure.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/dummy_m68k.c?cvsroot=qemur1=1.1r2
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/10 19:30:52
Modified files:
. : Makefile
Log message:
Fix Makefile dependencies.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.128r2
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 00:04:50
Modified files:
. : Changelog Makefile.target cpu-exec.c
qemu-doc.texi vl.c vl.h
fpu: softfloat-native.h softfloat.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 01:18:28
Modified files:
. : Makefile.target
Log message:
Remove duplicate i2c.o.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 02:51:17
Modified files:
. : Makefile Makefile.target aes.c block-bochs.c
block-cloop.c block-cow.c block-dmg.c
block
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/11 03:33:14
Modified files:
. : qemu-img.c
Log message:
Cleanup qemu-img.c.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemur1=1.24r2=1.25
The attached patch starts splitting vl.h up a bit.
I've pulled out the i2c, disk and irq code.
Because I picked some of the easier ones, they can also be built once, rather
than for every target.
Obviously there's a lot left to do, but my grand plan is to get rid of vl.h
altogether. A few
- Modify lock_user() so that it automatically does access_ok() and
returns NULL if access_ok() fails.
You'll also need to augment all lock_user calls to indicate whether the buffer
needs to be writable. Currently this information is not available until
unlock_user is called.
Paul
On Wednesday 07 November 2007, Bernhard Fischer wrote:
On Wed, Nov 07, 2007 at 11:55:26PM +0100, Fabrice Bellard wrote:
Why not adding a new CPU type such as PPC970 with hypervisor and keep
the current PPC970 implementation as it is without the hypervisor mode.
I don't see the problem in
I can check the hypervisor feature is not present, for emulating PowerPC
620 on a target that would have hypervisor emulation support. But I
cannot do as if the CPU do not have the feature if it's actually
available. The PowerPC 64 target emulates PowerPC 64 without the
hypervisor feature,
This patch also removes the MMU flags from being saved in the
translation block code as a result of an off line discussion with Paul
Brook.
I'd like to hear the reasoning behind that. The TBs generated while in
boot mode and MMU disabled may contain translations generated from
virtual
IIUC enabling/disabling boot mode is no different to and other VM change.
If the virtual-physical mapping happens to be the same then it's
perfectly ok to reuse the TB.
Not in this case: in boot mode, physical and virtual address 0
generates TBs from PROM code.
How is this different to
By the time you consider the different combinations of targets hosts,
most of the opportunities for zero copy are eliminated anyway. Byte
ordering and structure packing amd content differences mean that we can't
do zero-copy except in the rare circumstance that the host target
match is all
access_ok() and lock_user() perform essential functions. lock_user(),
however, isn't directly comparable to how the kernel operates and should
therefore be encapsulated inside more typical kernel functions such as
{get,put}_user(), copy_{to,from}_user() and the like. access_ok() and
I have another solution: include all architecture specific files from
the main file.
I'd really rather not do this. I doubt it's going to be a win, as now you have
to recompile the whole thing every time you change the implementation. At
least with vl.h you only have to recompile when you
On Sunday 04 November 2007, J. Mayer wrote:
On Sun, 2007-11-04 at 12:17 +, Paul Brook wrote:
I have another solution: include all architecture specific files from
the main file.
I'd really rather not do this. I doubt it's going to be a win, as now you
have to recompile the whole
I not sure a single hw/hw.h file will give any benefit because there's a
fair amount of interfacing between the target devices emulation and the
host side interaction code. i.e. there's not much that's only used inside
hw/. hw/ is about as big as most of the rest of qemu put together, so
On Sunday 04 November 2007, Robert Reif wrote:
I'm looking at adding more complete support for different sparc32
CPUs, MMUs, cache controllers and systems.
Each CPU/MMU/cache controller combination is slightly different and
requires its own unique state. For example the two CPUs currently
On Saturday 03 November 2007, TJ wrote:
I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
warnings of the class:
warning: cast to pointer from integer of different size
There are at due to the recent EFAULT/access_ok changes. There should be (and
used to be) a clear
RISC CPUs don't support self-modifying code unless the affected area
is flushed explicitly.
For experience with ARM cpus, I think this is only true for userspace.
Many CPUs only require explicit flushes when the icache is enabled. It's not
uncommon for bootloaders to leave the icache
If you take a close look, you'll find more variations between Linux ABIs
for different CPUs than between all BSD implementations: common syscalls
of all BSD flavors do the same thing (and have the same ABI whatever the
CPU...). You'll also find very few variations between the syscalls
common
I changed Slirp output to use vectored IO to avoid the slowdown from
memcpy (see the patch for the work in progress, gives a small
performance improvement). But then I got the idea that using AIO would
be nice at the outgoing end of the network IO processing. In fact,
vectored AIO model could
On Monday 22 October 2007, Arnon Gilboa wrote:
Hi,
The attached patch adds isochronous transfers support to the OHCI
emulation, similarly to the UHCI patch pushed two weeks ago.
+uint16_t offset[8];
+};
+static inline int ohci_read_iso_td(uint32_t addr, struct ohci_iso_td *td)
+{
+
- there is no hardware machine emulation for Alpha in Qemu.
As I have no Alpha platform, I don't know much about the hardware to be
emulated.
I do know that the ev6 bus is the same as the Athlon used.
The CPU bus is pretty much irelevant. It's almost entirely transparent from a
I think your question is quite reasonable. Imagine a Linux host
running X Windows and a terminal like xterm or kconsole.
Then run a program like top or less in this terminal.
When a user changes the size of the console window, top, less
and other console applications get notified of this
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?
For VLE
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?
[ I meant to say
I suspect the best solution is to backtrack (remove the generated ops)
after decoding the insn if we discover we've passed a page boundary. The
ld*_code routines can simply return garbage (e.g. zero) if the read is
not on the first page.
The incorrect returned value may be target
+unsigned long phys_pc;
+unsigned long phys_pc_start;
These are ram offsets, not physical addresses. I recommend naming them as
such to avoid confusion.
Well, those are host addresses. Fabrice even suggested me to replace
them with void * to prevent confusion, but I kept
VLE targets (x86, m68k) can translate almost a full page of instructions,
and a page boundary can be anywhere within that block. Once we've spanned
multiple pages there's not point stopping translation immediately. We may
as well translate as many instructions as we can on the second page.
On Tuesday 16 October 2007, Jeff Carr wrote:
Has anyone looked into finding a way to pass SIGWINCH through to the
guest? I started looking at linux-user/signal.c.
For those that might not be familiar with SIGWINCH, supporting it
would allow qemu -nographic to tell when the terminal is a
On Friday 12 October 2007, Felipe Contreras wrote:
Hi,
When I try to use codesourcery's toolchain arm-2006q3-27 in my Fedora
7 box I always have the following issue:
qemu: Unsupported syscall: 983045
I guess it's a problem of NPTL incompatibility. Anyway, the patch that
Paul Brook sent
There seem to have specific problems when using dynticks in Qemu. What I
can see is that it makes the PowerPC emulation quite unusable, at least
on my PC, which is an amd64 (with a fix CPU frequency), no matter if I
run 32 or 64 bits mode.
I'd expect to see the same problems running a
On Sunday 14 October 2007, J. Mayer wrote:
Here's an updated version of the code fetch optimisation patch against
current CVS.
As a remainder, this patch avoid use of softmmu helpers to fetch the
code in most case. A new target define TARGET_HAS_VLE_INSNS has been
added which is used to
I'm confused. You say you don't agree with me, then give an example that
confirms what I said (Replace Guest OS with machine memory map as
appropriate).
What I don't agree is the fact that emulating huge amount of physical
address space is not immediatly useful.
Ah, ok. I meant
Also note that changing variables from int to long have strictly no
impact on 32 bits host machines, then won't help emulating more than 2
GB of RAM. Another variable type (target_phys_addr_t ?) should be used
instead.
This patch should be restricted to 64-bit hosts. I don't think it's
On Tuesday 25 September 2007, Avi Kivity wrote:
J. Mayer wrote:
On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
Dan Kenigsberg wrote:
On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
Hi,
On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
As with previous
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/09/22 16:49:15
Modified files:
. : Makefile configure
Log message:
Only build qemu-img with softmmu targets.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile
On Wednesday 19 September 2007, Stuart Anderson wrote:
On Wed, 19 Sep 2007, J. Mayer wrote:
The idea is great but there seem to be a problem in those patches:
you directly cast syscall arguments, which are (or should be)
target_ulong to pointers in the host environment. You should to use
OK, great. Having 64 bits may also help for additional (ie future...)
features in PowerPC 64 emulation.
Maybe worth letting the target say whether it needs 32 or 64-bit
flags.
The flag lookup is likely to be on a hot path.
I may be wrong, but it seems to me that TB flags are
On Wednesday 19 September 2007, Stuart Anderson wrote:
On Wed, 19 Sep 2007, J. Mayer wrote:
Then, the changes you've done, changing long arguments (which should be
target_long to be correct, you can take a look at the last patch I sent
on the list) to pointers, for example in function
701 - 800 of 1522 matches
Mail list logo
