Re: [Qemu-devel] time inside qemu

> code (a) : for (int i = 0; i< 100; i++) c[i] = a[i] * b[i]; > > code (b) : for (int i = 0; i< 1000; i++) for(int j = 0; j < b[i]; j++) > c[i] += a[i]; > > code (c) : for (int i = 0; i< 1000; i++) c[i] = HW_MUL(a[i], b[i]); > > I'm sure that code (b) will execute much longer that code (a) ins

Re: [Qemu-devel] time inside qemu

On Monday 16 April 2007 15:41, Marius Monton wrote: > > Any benchmark/performance measurements you make inside qemu are > > meaningless. qemu performance bears no relation whatsoever to the > > performance characteristics of real hardware. > > That's true, and I don't care about it. I'd like to get

[Qemu-devel] qemu/hw acpi.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/15 23:54:20 Modified files: hw : acpi.c Log message: Remove unused variable. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/acpi.c?cvsroot=qemu&r1=1.9&r2=1.10

Re: [Qemu-devel] [Patch] Makefile.target

> But nevertheless, sometimes it happens that I "do that", > and then I'm always happy when I get a clear error > message. Or even better, when something works as > expected even when I did something unexpected. > You are lucky if you never experienced such situations. > > In my case, even a simple

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

On Sunday 15 April 2007 20:11, Blue Swirl wrote: > > Probably the linker is making sure the file offset and VMA are the same > > modulo the page size. > > But that would be one huge file, as the VMA is near 2TB: I said *modulo the pace size* :-) Lets say ld thinks the page size for your system is

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

On Sunday 15 April 2007 16:03, Blue Swirl wrote: > On 4/15/07, Stefan Weil <[EMAIL PROTECTED]> wrote: > > The Sparc64 image is much larger than the Sparc32 image, > > but the size command displays a much smaller text and data size > > (about the same size as for the Sparc32 image). > > > > Maybe it

[Qemu-devel] qemu/linux-user flatload.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/15 14:13:11 Modified files: linux-user : flatload.c Log message: bFLT loader alignment fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flatload.c?cvsroot=qemu&am

Re: [Qemu-devel] [Patch] Makefile.target

On Sunday 15 April 2007 14:57, Stefan Weil wrote: > This small patch for Makefile.target fixes a very special build issue: > > make distclean # (only needed to remove files left from earlier builds) > ./configure > make -C i386-softmmu # (or any other system emulation) > > will try to build the mis

Re: [Qemu-devel] 16-bit (and 8-bit) emulation

On Sunday 15 April 2007 14:46, Nigel Horne wrote: > Let me approach this in a different way in the hope that I'll get an answer > to my question: will Qemu run a 286 guest O/S? Yes. Paul

Re: [Qemu-devel] 16-bit (and 8-bit) emulation

> > My point is that pretty much anything that runs on a 286 should also run > > on any subsequent x86 processor. If you want to test 16-bit x86 > > software/systems you don't need an actual 286. A 386 is just as good for > > almost all purposes. > > How does that address my issue? You wanted a 28

Re: [Qemu-devel] 16-bit (and 8-bit) emulation

> > Modern x86 are backwards compatible[*], so you should be able to do that > > anyway. > > Care to share with us how I do that? Is it an option to gcc? gcc does not support 16-bit mode. My point is that pretty much anything that runs on a 286 should also run on any subsequent x86 processor. If

Re: [Qemu-devel] 16-bit (and 8-bit) emulation

On Sunday 15 April 2007 13:08, Nigel Horne wrote: > Stuart Brady wrote: > > On Sun, Apr 15, 2007 at 11:08:56AM +0100, Nigel Horne wrote: > >> Can qemu emulate 16-bit machines (286?)? > > > > None that I'm aware of. Is there any particular need for 286 emulation? > > To test my code on machines whe

Re: [Qemu-devel] 16-bit (and 8-bit) emulation

On Sunday 15 April 2007 12:33, Stuart Brady wrote: > On Sun, Apr 15, 2007 at 11:08:56AM +0100, Nigel Horne wrote: > > Can qemu emulate 16-bit machines (286?)? > > None that I'm aware of. Is there any particular need for 286 emulation? > OTOH, it might be interesting to see some m68k system emulati

Re: [Qemu-devel] Determine simulated pc during an exception

> Can anyone point me to the place in the code where the simulated program > counter is determined after an exception? cpu_restore_state Paul

[Qemu-devel] qemu gdbstub.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/14 22:35:50 Modified files: . : gdbstub.c Log message: Fix format specified for watchpoint address. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemu

Re: [Qemu-devel] FDC and M48T59 save/reset methods

> I'd like to commit the attached FDC and M48T59 device save and reset > methods. After this change, all Sparc32 devices can be saved. > > Any comments? Do you also need to save the state of the attached drives? Paul

[Qemu-devel] Re: sparc64 gdb

> By my reading this get f0 and f1 the wrong way round on little-endian > hosts. Should this be(omitting uint32 *casts for clarity): > > tmp = env->fpr[i]; > tmp |= env->fpr[i + 1]; > registers[i/2 + 32] = tswap64(tmp) Argh. What I meant was: tmp = env->fpr[i] << 32; tmp |= env->fpr[i +

[Qemu-devel] sparc64 gdb

I'm currently reqriting bits of the qemu gdb stub to take advantage of new GDB target description mechanisms, and have come accross what looks like a bug in the sparc64 code. My understanding is that gdb considers sparc64 to have 48 "registers". The first 32 are the same as sparc32, the last 1

Re: [Qemu-devel]Debian for arm

> > http://www.aurel32.net/info/debian_arm_qemu.php > > > > Paul > > Thank you Paul. Unfortunately, I have already tried it few days ago and > it didn't work. That's why I asked for a net-install. This is a network install. Paul

Re: [Qemu-devel]Debian for arm

On Friday 13 April 2007 14:21, Maxime Tierrie wrote: > Hi all, > > I would like to build Debian for an ARM target and simulate it with qemu. > I tried the following command: > qemu-system-arm -M versatilepb -cdrom debian-31r5-arm-netinst.iso -hda > hda.img -boot d > Obviously, it doesn't work (it a

Re: [Qemu-devel] Re: IRQ handling

> > In its current implementation it doesn't provide any functional > > enhancements over a {callpack, opaque, nIRQ} triplet. What it does do is > > isolate the device (IRQ source) emulation from the implementation > > details. > > So, I was confused by some remarks saying that this would give new

Re: [Qemu-devel] Re: IRQ handling

> > In summary the IRQ source (ie. device raising the IRQ) needs to keep > > track of 4 values: > > 1) Callback > > 2) Opaque callback argument > > 3) PIN number > > 4) IRQ state. >... > > I believe (1) and (2) are inherently linked, and it makes no sense to > > set/change them individually. > > OK

[Qemu-devel] qemu/hw pl190.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/09 02:01:58 Modified files: hw : pl190.c Log message: ARM IRQ fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl190.c?cvsroot=qemu&r1=1.2&r2=1.3

[Qemu-devel] Re: IRQ handling

[replying to a couple of different mails] > What do you need to route an IRQ ? > -> A peripheral destination Agreed. > What we got now ? > -> a callback with 3 parameters: an opaque, a PIN (the n_IRQ) and a > state We have this in some places. Other places only have some parts. > Is more neede

Re: [Qemu-devel] Just to add one single point

> Mr Paul Brook did break the PREP and heathrow machines while doing > changes in the PCI code. There were some posts on this list reporting > this and he never even tried to fix what he broke. And now he's > complaining "I cannot test as it does not work". Looks like a

Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

> 2) I don't like hiding pointers in types, so I would use for example > 'QEMUSignal *' instead of 'qemu_irq'. FWIW I did it this way so that devices are agnostic about whether it was implemented as a pointer or an integer index. Paul

Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

On Saturday 07 April 2007 23:18, J. Mayer wrote: > It seems that you don't figure out how real hardware works AT ALL. > IRQ callbacks and private data CANNOT BE SHARED as they are INTERNAL TO > ONE IRQ CONTROLLER. IRQ management, once again, is completelly specific > to an IRQ controller technology

Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

On Saturday 07 April 2007 21:28, J. Mayer wrote: > On Sat, 2007-04-07 at 20:10 +0100, Paul Brook wrote: > > On Saturday 07 April 2007 19:32, J. Mayer wrote: > > > On Sat, 2007-04-07 at 18:14 +, Paul Brook wrote: > > > > CVSROOT:/sources/qemu > > >

Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

> Sparc seems undamaged, devices using IRQs work as before. SMP BogoMIPS gets > calculated and that needs per-CPU IRQs. For the record I tested win2k, knoppix and x86 debian, mips test image, sparc debian installer, arm test image, and a preinstalled ARM linux. I didn't test ppc (other than that

Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

On Saturday 07 April 2007 19:32, J. Mayer wrote: > On Sat, 2007-04-07 at 18:14 +0000, Paul Brook wrote: > > CVSROOT:/sources/qemu > > Module name:qemu > > Changes by: Paul Brook 07/04/07 18:14:41 > > The patches in the PowerPC target seem complete nonse

[Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/07 18:14:41 Modified files: . : Makefile.target vl.h hw : acpi.c adlib.c apb_pci.c arm_gic.c arm_pic.c arm_pic.h arm_timer.c cs4231.c cuda.c

Re: [Qemu-devel] Feature proposal: USB devices over TCP

> I don't think that tunneling traffic through VNC is possible. In QEMU the > VNC implementation is asynchronous, while the USB layer expects an > immediate response to any request. Not entirely true. While some transfers (typically control transfers) are synchronous, bulk transfers can by asynch

[Qemu-devel] qemu/hw rtl8139.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/07 01:41:50 Modified files: hw : rtl8139.c Log message: Remove dead code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.c?cvsroot=qemu&r1=1.7&r2=1.8

[Qemu-devel] qemu/hw ide.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/07 01:24:43 Modified files: hw : ide.c Log message: Remove dead code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.56&r2=1.57

Re: [Qemu-devel] Patch: dyngen-exec.h for OpenBSD

On Thursday 05 April 2007 23:12, Todd T. Fries wrote: > Penned by Thiemo Seufer on 20070402 10:54.53, we have: > | > /* NOTE: standard headers should be used with special care at this > | > point because host CPU registers are used as global variables. Some > | > host headers do not allow

Re: [Qemu-devel] Virtual braille device support?

> The question I'd have for now is: how to choose which brand of USB > braille device to emulate? Should the simplest, fastest, or most > powerful protocol be chosen? I'd go for whichever is best documented and supported by the widest range of (Open Source) operating systems. Paul

Re: [Qemu-devel] [patch] use socklen_t with getsockopt()

On Friday 06 April 2007 22:51, Mike Frysinger wrote: > On Thursday 05 April 2007, Jamie Lokier wrote: > > Sylvain Petreolle wrote: > > > Was incorrect before too, since it was sizeof(int) in the first place ? > > > > The old type of "val" was "int", so it made no different to the size. > > When "va

[Qemu-devel] qemu/hw arm_timer.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/06 20:58:25 Modified files: hw : arm_timer.c Log message: Comment spelling fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_timer.c?cvsroot=qemu&r1=1.2&r2=1.3

[Qemu-devel] qemu/hw pl181.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/06 16:54:11 Modified files: hw : pl181.c Log message: Use correct type for card field. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl181.c?cvsroot=qemu&r1=1.

[Qemu-devel] qemu Makefile.target qemu-doc.texi vl.c vl.h hw...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/04/06 16:49:48 Modified files: . : Makefile.target qemu-doc.texi vl.c vl.h hw : integratorcp.c realview.c versatilepb.c Added files: hw : pl181.c

Re: [Qemu-devel] [qemu-system-arm]Help needed

On Thursday 05 April 2007 10:57, Maxime Tierrie wrote: > Hi, > I would like to build a linux kernel for an arm system and use Qemu for > the simulation. What target exactly can I use ? May I use something > like XXX_defconfig? I will be very interested to know how was built the > arm-test-0.2 ava

Re: [Qemu-devel] Simtec BAST emulation

On Monday 02 April 2007 14:56, Daniel Silverstone wrote: > Hi, > > Myself and my colleagues have worked hard and produced a new system > emulation for qemu for the Simtec BAST board. A few issues with the patch, which I think need to be resolved before it can be applied: - You're using global st

[Qemu-devel] qemu/hw pc.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/31 19:41:22 Modified files: hw : pc.c Log message: Large kernel initrd fix (initial patch by Daniel Jacobowitz). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c

Re: [Qemu-devel] [PATCH] Increase max -kernel size

> Like this? I can't reliably test that it fixes the problem - for some > bizarre reason, I can now load kernels without this patch. But it > looks right and I can load kernels with it, too. Turns out there's a problem. qemu puts ACPI tables at the top of ram. We have to be careful to avoid sto

Re: [Qemu-devel] [PATCH] add a simple 24mhz clock for the versatile

> +        uint64_t now = qemu_get_clock(vm_clock); > +        return (uint32_t)(now*.024); We should be able to do this without resorting to floating point arithmetic. Paul

Re: [Qemu-devel] QEMU Alpha target

On Thursday 29 March 2007 16:12, Stuart Brady wrote: > On Thu, Mar 29, 2007 at 04:08:25PM +0100, Paul Brook wrote: > > > There do seem to be a few people who'd like Alpha emulation for QEMU. > > > Obviously, you'd want to get dynamic translation working first

Re: [Qemu-devel] QEMU Alpha target

> There do seem to be a few people who'd like Alpha emulation for QEMU. > Obviously, you'd want to get dynamic translation working first. :-) > > OTOH, I'm now wondering which archs can support full virtualisation. Depends how you define "full virtualization". If you call kqemu full virtualizatio

Re: [Qemu-devel] [PATCH] Increase max -kernel size

On Wednesday 28 March 2007 03:21, Daniel Jacobowitz wrote: > On Wed, Mar 28, 2007 at 12:35:18AM +0100, Thiemo Seufer wrote: > > Right, a piggyback-style loader would likely fail in that case. > > Which is exactly the interesting case for x86_64. So, since Paul's > verified that grub and lilo just

Re: [Qemu-devel] virtual machine halting and loosing connections

On Wednesday 28 March 2007 01:22, andrzej zaborowski wrote: > On 28/03/07, Kyle Hubert <[EMAIL PROTECTED]> wrote: > > I've been looking online, but I can't say that I have found the answer > > to this yet. > > > > When using QEMU, I've noticed that if I switch away to a different > > virtual deskto

Re: [Qemu-devel] [PATCH] Increase max -kernel size

> > Note, that does not readily work - this is where we load the > > compressed kernel image and initrd, but what matters is the size it > > gets uncompressed to. > > I think what matters is the space taken by (uncompressed and loaded) > kernel ALLOC segments. Everything above that should be ok to

Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works

> > I moved to helper2.c because AFAICT helper.c is compiled with the same > > sort of restrictions as op.c which leads to the compile failure. > > Yes, helper.c is compiled with the global register variables and the code > is called directly from the op_xxx functions, but one needs the global > re

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

> I do not understand enough of QEMU yet, but I have checked out CVS and > am reading through its source. When I understand more I hope we can fix > this long-standing annoyance. This is GCC PR16185 . There's no fundamental reason why some options trigger it, and others

Re: [Qemu-devel] RFC: This project needs a stable branch

On Thursday 22 March 2007 23:57, Julian Seward wrote: > On Thursday 22 March 2007 23:27, Paul Brook wrote: > > > Do you mean you're asking me to break up Paul Brook's QOPS tree at > > > https://nowt.dyndns.org and submit it to mainline? I can do this > > >

Re: [Qemu-devel] RFC: This project needs a stable branch

> Do you mean you're asking me to break up Paul Brook's QOPS tree at > https://nowt.dyndns.org and submit it to mainline? I can do this thing, if > you really think it would help. If you implement all the missing bits in the process it'll help ;-) Paul _

Re: [Qemu-devel] [PATCH] fcntl64 fix

> Now that the dust has settled, I see where the change is probably a > no-op anyway. A quick little test program indicates that on x86_64, > l_start will have an offset of 8 wether the structure is packed or not, > and wether the __pad member is present or not. The unsigned long long is > always g

Re: [Qemu-devel] [PATCH] fcntl64 fix

> struct target_eabi_flock64 { > short l_type; > short l_whence; > +#if HOST_LONG_BITS == 32 > int __pad; > +#endif This change is definitely wrong. This is a target structure, and is packed, so should be independent of the host. Paul ___

Re: [Qemu-devel] [PATCH] EABI fcntl on x86_64

On Monday 19 March 2007 15:30, Stuart Anderson wrote: > When running ARM EABI binaries on x86_64, the target_eabi_flock64 > structure is already padded correct so the padding is not needed. > This patch adds an #ifdef to only include the _pad member on 32-but > hosts. This is wrong. The struct is

Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction

> >> So an emulation has several options: > >> > >> 1. Show undefined behaviour (this is what it does today). > >> 2. Emulate the behaviour of existing CPUs as far as possible. > >> As different CPUs behave different, this must depend on the > >> current CPU. > >> 3. Display an error message. > > >

[Qemu-devel] qemu/hw ppc_chrp.c ppc_prep.c realview.c usb-oh...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/17 16:59:31 Modified files: hw : ppc_chrp.c ppc_prep.c realview.c usb-ohci.c usb.h versatilepb.c Log message: OHCI USB PXA support (Andrzej Zaborowski

Re: [Qemu-devel] [PATCH] PXA-specific ARM hacks.

On Friday 16 March 2007 22:06, andrzej zaborowski wrote: > This patch contains some ugly but very useful chnages: > - in cpu-exec.c, halt the arm CPU on CPU_INTERRUPT_HALT like in other > architectures. This is ok. Though I'd prefer it to actually be common code (like CPU_INTERRUPT_DEBUG). > -

Re: [Qemu-devel] [PATCH] SecureDigital card emulation.

On Friday 16 March 2007 20:59, andrzej zaborowski wrote: > Emulates an SD card with the full command set (no SPI mode though). > Should be more or less compliant with version 1.10 specification. I suspect your code only works on x86. Specifically things like: > +struct sd_response_r1_s { > +u

[Qemu-devel] qemu/target-arm translate.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/17 01:43:01 Modified files: target-arm : translate.c Log message: ARM register index+writeback fix (Lauro Ramos Venancio). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target

[Qemu-devel] qemu/linux-user syscall.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/17 01:27:24 Modified files: linux-user : syscall.c Log message: Usermode recv syscall fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&am

[Qemu-devel] qemu cpu-all.h cpu-defs.h cpu-exec.c exec.c gdb...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/16 23:58:11 Modified files: . : cpu-all.h cpu-defs.h cpu-exec.c exec.c gdbstub.c target-arm : translate.c Log message: Watchpoint support

Re: [Qemu-devel] [PATCH] iwMMXt instruction set for the PXA270.

> The iwMMXt has 16+ of its own registers, Does someone know if there's > any standard way for gdb to read their values so they can be printed > when you do "info registers"? It may be worth adding proper piece in > gdbstub.c then. Yes, recent gdb has remote protocol bits for this. The same mechan

Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

> > Will this work also for the CL542x adaptor? (Does that fall in the > > category of vga?) My current hack works for with/without -std-vga and I > > think that's because it lives "underneath" both, in the connection to > > SDL. > > Each adapter will have to do it's own minimization but that's s

Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

> > 8b50 : > > 8b50: 8b 05 00 00 00 00 mov0(%rip),%eax > > 8b52: R_X86_64_PC32 __op_param1+0x3c > > 8b56: ff e0 jmpq *%rax > > 8b58: f3 c3 repz retq > > > > qemu only strips the fin

Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

On Friday 16 March 2007 14:15, Julian Seward wrote: > I'm seeing redundant repz (0xF3) prefixes in generated code, typically > just before jumps: > > : repz mov $0xe07f,%eax > : mov%eax,0x20(%rbp) > : lea-25168302(%rip),%ebx # 0xaf0420 > : retq > : mov-25168245(%rip),%eax # 0xaf

Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register

On Thursday 15 March 2007 21:55, Laurent Desnogues wrote: > Paul Brook a écrit : > > I suggest you check again. I'm fairly sure the arm926 implements the Base > > Restored abort model. > > Yes, but arm7 is Based Updated IIRC. What particular implementation > does

Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register

> > This is still wrong. > > So, is this a known bug? Still wrong implies it's a bug, and your patch does not fix it properly. > > The writeback must happen after the load. > > We code like this because > - we didn't find this restriction in arm reference manual It's the Abort model section you

Re: [Qemu-devel] qemu-arm: wrong execution of post-indexed loads when Rm and Rd are the same register

On Thursday 15 March 2007 19:35, Lauro Ramos Venancio wrote: > Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are > the same register. For example: > > ldr r0, [r1], +r0 > > Current behavior: > r0 <- [r1] > r1 <- r1 + r0 > > Expected behavior: > addr <- r1 > r1 <- r1 + r0 > r0 <- [

Re: [Qemu-devel] RFC: This project needs a stable branch

> Subsequent releases of the branch would contain no functionality > enhancements, but just bug fixes, with the eventual aim of achieving > 'it just works' status for any x86/x86_64 guest I try to install/run. > I know that's a tall order, and that 0.9.0 may not be able to supply > that for all gue

Re: [Qemu-devel] problems using sockets inside qemu code

On Wednesday 14 March 2007 14:23, Marius Monton wrote: > Hi again, > > I'm using sockets inside qemu code for my work on SystemC + qemu > simulation. I've implemented a TCP client inside qemu code to connect to an > application (TCP server) outside QEMU (all SystemC stuff). > Almost all is working

Re: [Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu

> However, it's very wax-on, wax-off kind of thing. Without the patch, > arm-test and mips-test crash. With the patch, I can run both tests. As I've said before it's not sufficient to say that a patch fixes a bug, you have to explain *what* bug you are fixing, *how* it fixes the bug, and *why*

Re: [Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu

On Tuesday 13 March 2007 14:01, Ben Taylor wrote: > This patch fixes crashes when testing with arm-test-0.2.tar.gz and > mips-test-0.2.tar.gz. Without the patch, both arm-test and mips-test > segfault when trying to boot. I don't believe this is correct. You're going to have to come up with a fair

[Qemu-devel] qemu cpu-all.h cpu-defs.h cpu-exec.c exec.c gdb...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/12 01:47:26 Modified files: . : cpu-all.h cpu-defs.h cpu-exec.c exec.c gdbstub.c target-arm : translate.c Log message: Implement

[Qemu-devel] qemu vl.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/11 18:54:57 Modified files: . : vl.c Log message: SMP half-idle fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.263&

[Qemu-devel] qemu hw/arm_boot.c hw/arm_sysctl.c target-arm/c...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/11 13:03:18 Modified files: hw : arm_boot.c arm_sysctl.c target-arm : cpu.h helper.c Log message: ARM reabbot support (orginal patch by Aurelien Jarno). CVSWeb URLs

Re: [Qemu-devel] Patch: arm versatile video mode support

> Perhaps someone has a more general or a better way of doing this. > Before this patch, the only ways I found to change the video mode of > qemu versatile was to > change the default clcd mode in the kernel code or change the clcd mode > in the qemu code. Use fbset. Paul __

[Qemu-devel] qemu vl.c target-arm/cpu.h target-arm/helper.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/08 03:15:18 Modified files: . : vl.c target-arm : cpu.h helper.c Log message: Fix typo in help output. List ARM cpus. CVSWeb URLs: http

[Qemu-devel] qemu vl.c vl.h hw/integratorcp.c hw/realview.c ...

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/08 03:04:12 Modified files: . : vl.c vl.h hw : integratorcp.c realview.c versatilepb.c linux-user : main.c target-arm : cpu.h helper.c Log

[Qemu-devel] qemu loader.c vl.h hw/arm_boot.c uboot_image.h

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/06 23:52:01 Modified files: . : loader.c vl.h hw : arm_boot.c Added files: . : uboot_image.h Log message: Simple u-boot image loading

Re: [Qemu-devel] armv6 support

On Tuesday 06 March 2007 23:27, Rob Landley wrote: > On Friday 23 February 2007 5:54 pm, Paul Brook wrote: > > On Friday 23 February 2007 20:09, Rodrigo Vivi wrote: > > > Hi all, > > > > > > Is there someone working on armv6 support? > > > I'm ver

Re: [Qemu-devel] Bugs. Patches. Feedback.

On Sunday 04 March 2007 11:52, Kirill A. Shutemov wrote: > I want to help qemu project, but some patches which I post to the mail > list have ignored. I guess that a open source project should have faster > feedback. Giving some description of the patches might help. Patches with no explanation o

Re: [Qemu-devel] QEMU/pc and scsi disks

On Sunday 04 March 2007 11:48, Avi Kivity wrote: > Paul Brook wrote: > >> Out of curiosity, why? If the options are store in some database, as is > >> likely, surely it is easier to generate a longish command line than to > >> generate a unique name for a file,

Re: [Qemu-devel] QEMU/pc and scsi disks

On Sunday 04 March 2007 09:28, Avi Kivity wrote: > Anthony Liguori wrote: > >> 1. Any option should be settable either in the config file or > >> command line. In other words, the user should not be forced to use a > >> config file. This is useful for management programs who keep all > >> option

[Qemu-devel] qemu a.out.h dyngen.c

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/03/04 00:52:16 Modified files: . : a.out.h dyngen.c Log message: 64bit->win32 cross build fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/a.out.h?cvsroot=qemu&r1

Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test

> : I find this curious... C99 (6.7.2.1) says "the allocation order of > : bit-fields within a unit (high-order to low-order or low-order to > : high-order) is implementation defined". I can't see any requirement > : for this, so is it just convention that bitfields on big endian systems > : star

Re: [Qemu-devel] QEMU/pc and scsi disks

> > > There's also no reason to limit to 7 disks, and we should support scsi > > > cdroms. > > > > The reason for 7 is the number of available id on the scsi bus. > > For wide scsi it is 15. I wouldn't bet on wide scsi working. For PCI based systems you can add more host adapters to get more devic

Re: [Qemu-devel] QEMU/pc and scsi disks

On Thursday 01 March 2007 17:26, Laurent Vivier wrote: > Hi, > > As I'm a newcomer, I don't know the story about qemu/pc and scsi disks, but > I propose a little patch to make SCSI disks visible. See previous discussion about how the disk options need to be fixed properly. Apart from anything els

Re: [Qemu-devel] [PATCH] Experimental patch providing accelerated OpenGL for Linux i386 (update as of 2007-02-28)

> The patch has been updated and is available at > http://qemu-forum.ipi.fi/viewtopic.php?t=2984 How does this compare to chromium[1] and in particular vmgl[2] ? Any particular reason you're re-inventing the wheel? Paul [1] http://chromium.sourceforge.net/ [2] http://www.cs.toronto.edu/~andresl

Re: [Qemu-devel] [PATCH] Mention RealView in docs.

> Mention ARM RealView emulation in user docs (similar to ARM Versatile). > [EMAIL PROTECTED] > +Versatile PCI host bridge - PCI memory space only. This is wrong. Also the proper name is RealView Emulation Baseboard. Fixed and applied. Paul ___ Qemu-

[Qemu-devel] qemu qemu-doc.texi

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/02/28 16:25:17 Modified files: . : qemu-doc.texi Log message: iDocument ARM RealView board (Andrzej Zaborowski). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu

[Qemu-devel] qemu configure

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/02/27 21:04:49 Modified files: . : configure Log message: Compiler check for byteswap.h instead of hardcoded path. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure

[Qemu-devel] qemu Makefile.target

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/02/27 21:02:54 Modified files: . : Makefile.target Log message: Include LDFLAGS when linking system emulator. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target

[Qemu-devel] qemu configure

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/02/27 01:03:41 Modified files: . : configure Log message: Honor $cross_prefix when searching for suitable gcc. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure

[Qemu-devel] qemu configure

CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/02/27 00:52:01 Modified files: . : configure Log message: Fix "make install prefix=/somewhere". CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsro

Re: [Qemu-devel] armv6 support

> > I already have ARMv6 and ARMv7 implemented, but am unable to > > release the code. > > See: > > http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00202.html > > > > We (CodeSourcery) are negotiating with ARM to have this > > restriction lifted, but it's slow going. > > > > If you want to

Re: [Qemu-devel] armv6 support

On Friday 23 February 2007 20:09, Rodrigo Vivi wrote: > Hi all, > > Is there someone working on armv6 support? > I'm very interested to help this development... I already have ARMv6 and ARMv7 implemented, but am unable to release the code. See: http://lists.gnu.org/archive/html/qemu-devel/2006-03

Re: [Qemu-devel] [PATCH] mount syscall

On Wednesday 14 February 2007 08:26, Kirill A. Shutemov wrote: > In the attachment fixed Debian patch(with lock_user_string). This is still wrong. You need to figure out what arg5 really is. I've attached an old, bitrotten and untested patch you might want to use as a base. It predates all the l

<    6   7   8   9   10   11   12   13   14   15   >