CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/07/01 18:21:11
Modified files:
. : exec.c
Log message:
Fix bogus fopen mode.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.102&r2=1.103
On Sunday 01 July 2007, Stefan Weil wrote:
> ANSI / POSIX do not define "wa" as mode string for fopen.
> I have no idea how many implementations of libc
> will fail with this mode which was introduced by
> the latest version of exec.c.
>
> The standard mode for append is just "a".
You are correct.
On Monday 02 July 2007, Ulrich Hecht wrote:
> On Saturday 30 June 2007 04:19, Paul Brook wrote:
> > > QEMU does not set the Thumb bit when reading from R15 in Thumb mode.
> >
> > Neither does real hardware.
>
> You are, unsurprisingly, right. The problem seems to be
On Monday 02 July 2007, Ulrich Hecht wrote:
> Hi!
>
> This patch adds ARM7TDMI emulation with Thumb v1 (no BLX, no BKPT, ignore
> bit 0 on POP PC) and without CP15.
ARM_FEATURE_THUMB1 is a bad name for this. Thumb-1 covers both v4t and v5t.
Thumb-2 is a completely new architecture revision which
On Wednesday 04 July 2007, Rob Landley wrote:
> Does arm (versatilepb) have any kind of battery backed clock? I can't find
> a way to init the linux kernel's clock from the kernel command line, and if
> there's clock hardware that should be initializing it I haven't enabled the
> driver in the ker
On Friday 06 July 2007, Eric S. Johansson wrote:
> I'm looking for a way to encapsulate applications on a firewall (IPCop).
> My line of reasoning is an encapsulated extension environment would help
> protect the integrity of the firewall and give users greater latitude in
> creating extension app
On Tuesday 10 July 2007, Stuart Anderson wrote:
> On Mon, 9 Jul 2007, Fabrice Bellard wrote:
> > No. Ideally you should use the same conventions as the Linux kernel and
> > assume that you cannot access the user data directly.
>
> That's what I had already started doing today.
>
> > For the time be
> > Besides, most
> > filesystems reserve some space for the superuser, now unless there's a
> > cross-platform way to figure out just how much space that is, you'd still
> > be getting errors despite having 5~10% of the filesystem technically
> > free.
>
> Qemu might freeze the guest when it gets
> >> Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
> >> second or wait for user input on the monitor.
> >
> > Better would IMHO be to report an IO error to the guest and allow that to
> > decide what to do. If you're bothered about robustness and reliability
> > then arbitr
> The hw/rtl8139.c code is passing 0x100 in as the size parameter for the
> cpu_register_physical_memory call, despite the fact that the API contract
> says size has to be a multiple of page size.
Have you tried recent CVS? This should not be necessary.
Paul
On Friday 20 July 2007, 姚春林 wrote:
> > Can you try using the other nic types? I'm most interested in the
> > results with the rtl8139 model.
>
> I have used rtl8139 the first time.Does not work.
>
> I think the etherboot is OK. because I can use it to boot from vmware.
> and the ethereal captured t
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/07/22 18:16:42
Modified files:
target-arm : op.c
Log message:
Thumb shifter carry flag fixes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op.c?cvsroot=qemu&r1=1.2
On Tuesday 24 July 2007, Nathaniel Filardo wrote:
> Greetings all.
>
> I am attempting to port QEMU to Plan 9 for the Google Summer of Code.
> A big chunk (in terms of diff line count) of the work that has been
> done on this before was to convert all the lines of the form
> case A ... B:
> to
> >As Qemu cannot use multicore CPUs (partially due to missing thread
> >safety), yet, you won't benefit from this unless you want to run
> >multiple instances of Qemu in parallel.
>
> how close is thread safey?
In a useful form: a fair way off.
It's relatively simple to hack something together t
> >> how close is thread safey?
> >
> > In a useful form: a fair way off.
> >
> > It's relatively simple to hack something together than runs. Making it
> > work correctly and go fast is much harder though. My current prototype
> > (running on 2 cores) runs about a quarter the speed of normal qemu,
> > void op_cfc1 (void)
> > {
> > +#ifdef __s390__
> > +if(!T1)
> > +T0 = (int32_t)env->fcr0;
>
> I guess this breaks when you _breathe_ at the compiler. Inventing
> switch-table support in dyngen would be preferable (if possible...).
Actually, I'm surprised this doesn't break on oth
On Wednesday 01 August 2007, Dan Shearer wrote:
> On Wed, Aug 01, 2007 at 02:02:13AM +0100, Paul Brook wrote:
> > I suspect making dyngen handle jump tables is not going to happen.
>
> Which brings up the question of dyngen. Very clever and a very good way
> of bootstrapping QEMU
On Wednesday 01 August 2007, Dan Shearer wrote:
> On Wed, Aug 01, 2007 at 03:23:45PM +0100, Paul Brook wrote:
> > Some parts of this code effectively are a "special language" for
> > describing a CPU, that happen to be implemented using the C
> > preprocessor :-)
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/08/06 13:19:15
Modified files:
. : gdbstub.c
Log message:
Ensure string is properly terminated.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemu&am
> What popularity of CPU will dominate in the years 2008 .. 2013?
AFAICS this has nothing to do with qemu.
Please don't post random unrelated questions to this list.
You've already been told the same thing on some of the other lists you posted
the exact same mail to.
Paul
On Thursday 09 August 2007, Jeremy Katz wrote:
> The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
> for the Cirrus emulation so that you can tell that the system is running
> under qemu. This will make it so that, eg, we can detect that in X and
> know that resolutions > 800x6
On Friday 10 August 2007, Jeremy Katz wrote:
> On Fri, 2007-08-10 at 17:28 +0100, Paul Brook wrote:
> > On Thursday 09 August 2007, Jeremy Katz wrote:
> > > The attached adds a PCI subsystem vendor ID of 0x514D (QM ascii->hex)
> > > for the Cirrus emulation so that y
On Wednesday 15 August 2007, Blue Swirl wrote:
> Hi,
>
> I'd like to use similar mechanism as qemu_irq as reset signal for
> devices. The difference is that the opaque data and callback are not
> specified at the time of creating the signal at upstream device, but
> when the receiving device is cre
> Okay, more explaining. This is the case where I'd want to use the
> signal: DMA controller ("upstream") can reset the slave device (ESP or
> Lance). DMA controller is created first and I also want to allocate
> reset signals at that point. Later when ESP is created, it should be
> possible to put
On Wednesday 15 August 2007, Paul Brook wrote:
> > Okay, more explaining. This is the case where I'd want to use the
> > signal: DMA controller ("upstream") can reset the slave device (ESP or
> > Lance). DMA controller is created first and I also want to allocat
On Wednesday 15 August 2007, Blue Swirl wrote:
> On 8/15/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On Wednesday 15 August 2007, Paul Brook wrote:
> > > > Okay, more explaining. This is the case where I'd want to use the
> > > > signal: DMA contro
> I implemented reset that way with qemu_irq, the result survives some
> quick tests.
I'd probably make it take notice of the level parameter, and lower the line
immediately after raising it. Future implementations of qemu_irq may cache
the value internally.
Other than that, looks ok, though yo
On Thursday 16 August 2007, dragoran wrote:
> Bill C. Riemers wrote:
> > You don't need to compile kqemu into the kernel. When I install
> > dkms-kqemu from freshrpms, I do NOT rebuild my kernel. I am fairly
> > certain with Fedora's new policy for extras, there would not be much
> > of a problem
> > Mainly because the kernel already has one perfectly good virtualization
> > interface. There's very little motivation to add another incompatible
> > one, especially when the implementation is known to be fundamentally
> > flawed, and probably insecure.
> >
> > If you really want to get it merg
> Yes, good thinking, but this should only be done if it actually impacts
> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it
> introduces extra complexity.
If the overhead is that small, why are we touching this code in the first
place?
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/08/23 20:22:22
Modified files:
. : vl.c
Log message:
Suppress int<->pointer compiler warnings.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r
On Friday 24 August 2007, Blue Swirl wrote:
> I have now converted the ISA DMA devices (SB16, FDC), most PCI devices
> and targets.
>
> gdma.diff: Generic DMA
> pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA
> pc_sb16_to_gdma.diff: Convert SB16 to GDMA
> pc_fdc_to_gdma.diff: FDC
> pc_dma_clea
> >> pci_gdma.diff: Convert PCI devices and targets
> >>
> >> Any comments? The patches are a bit intrusive and I can't test the
> >> targets except that they compile.
> >
> > Shouldn't the PCI DMA object be a property of the PCI bus?
> > ie. we don't want/need to pass it round as a separate parame
> On second thought, there is a huge difference between a write access
> originating from CPU destined for the device and the device writing to
> main memory. The CPU address could be 0xf000 1000, which may translate
> to a bus address of 0x1000, as an example. The device could write to
> main memo
>I solved that by placing one of the T[012] operands into memory
>for HOST_I386, thereby freeing one reg. Here's some justification
>of why that doesn't really cost performance: with three free regs
>GCC is already spilling like mad in the snippets, we just trade on
> This is a bit mysterious for me too. SBus address space is 28 bits
> (256MB). Usually each slot maps to a different area. So the CPU sees
> one slot for example at 0x3000 and other at 0x4000 .
>
> IOMMU can map max 2G of memory, usually a 32 or 64MB region. For the
> devices, this device
> If this is the case, it means we don't need anything complicated. Devices
> map themselves straight into the system address space at the appropriate
> slot address (no plug-n-play to worry about), and device "DMA" goes via the
> IOMMU.
Further searching by google suggests I may be wrong.
The al
On Sunday 02 September 2007, M. Warner Losh wrote:
> Is anybody working on N770 and/or N800 emulation for qemu?
Most of the OMAP (The main SoC used on the N770/N800) documentation is only
available under NDA, and some components don't even have open source drivers
(most notably the DSP and wirel
> This could be very valuable when thinking about running qemu *on* embedded
> systems with constrained memory and processing power, which is exactly what
> the KVM for embedded PowerPC project is considering. In that scenario,
> being able to strip out all unnecessary functionality (especially
> i
On Tuesday 04 September 2007, Hollis Blanchard wrote:
> On Tue, 2007-09-04 at 21:04 +0100, Paul Brook wrote:
> > > This could be very valuable when thinking about running qemu *on*
> > > embedded systems with constrained memory and processing power, which is
> > > exa
> > I think qemu-cvs has a -cpu option for non-x86 which could be used for
> > this. Agree machine types are the wrong approach.
>
> Yep, machine types are already used to switch between a different concept
> so using the new -cpu option would make sense. Could perhaps extend the
> syntax so that
> From DMA2.txt, NCR89C100.txt, NCR89C105.txt and turbosparc.pdf I
> gather the following:
> - CPU and IOMMU always perform slave accesses
> - Slave accesses use the 28-bit address bus to select the device
I thought device selection was separate from the 28-bit SBus slave address
space. ie. each
> > IIUC devices never register addresses on the master bus. The only thing
> > that responds on that bus is the IOMMU.
>
> Generally yes, but these "intelligent masters" and their targets would
> register on on both buses. The only case I can only think of is a
> video grabber, it's frame memory c
On Sunday 09 September 2007, Jamie Lokier wrote:
> Avi Kivity wrote:
> > Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
> > host-os' on the first bug report? I have a feeling we won't ever see it.
>
> In other words, host-os is what _I'd_ implement because I care too
> much a
> > What you really want to do is ask your virtualization module what
> > features it supports.
>
> Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/09/09 21:16:01
Modified files:
hw : usb-hid.c usb-uhci.c
Log message:
Implement HID idle mode (avoids flooding guest with useless updates).
Fix UHCI NACK bug.
CVSWeb URLs
On Monday 10 September 2007, lindalu wrote:
> Is it means qemu simulate 8x smp in a single-thread,and the 8 virtual cpus
> cannot excute dynamic translation parallel?
> If use a single-thread simulate a virtual cpu,maybe the simulated cpus can
> excute parallel.
This was covered on this list recen
> > I'm using qemu at the moment to run a system for debugging purposes. I
> > was wondering whether qemu does actually emulate the performance
> > counters on IA32. Every time i try to read the value out, it
> > consistently gives me zero even though i have written to the given model
> > specifi
On Monday 17 September 2007, J. Mayer wrote:
> It seems to me that there are many problems in linux-user/syscall.c
> - problems for 64 bits targets:
> it seems that do_syscall and child functions should take target_long /
> target_ulong arguments instead of long / unsigned long. This would make
> a
> > > Ok, I will try to shift the intercepts in an uint_64 flags variable
> > > in the TB.
>
> 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
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
> > >> 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
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
On Friday 21 September 2007, Edgar E. Iglesias wrote:
> Hello,
>
> I'm working on a new target port and the linux-user emulation is fairly
> functional and passing quite extensive test-suites.
>
> I've got a problem though, my target has 8K page sizes, so for example when
> running on a x86 host TA
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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?cvsroot
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]>
> > 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 th
> > IMHO Huge amounts of virtual address space can definitely be useful, even
> > if you don't have ram to back it.
> >
> > Huge amounts of physical address space is less immediately useful, though
> > in practice you have to emulate whatever real hardware provides. If
> > you're emulating a machin
> > 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 i
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 incompatibil
> 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 non-
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 h
> > > +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,
> > 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 secon
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 d
> 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 t
> 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 t
> 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
> > 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 tar
> > - 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
so
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)
>
> 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 c
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 se
> 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 disabl
> 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
> com
> 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 ch
On Sunday 04 November 2007, J. Mayer wrote:
> On Sun, 2007-11-04 at 12:17 +0000, 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'
> > 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 togethe
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 current
> 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
> loc
> > 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 con
> > 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 diffe
> 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 i
> - 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
> 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
A recent CVS commit ("Fix gdb stub for MIPS64.") looks incorrect:
> diff -u -r1.66 -r1.67
> --- gdbstub.c 8 Oct 2007 13:16:14 - 1.66
> +++ gdbstub.c 25 Oct 2007 21:30:37 - 1.67
> @@ -563,7 +563,7 @@
> ptr += sizeof(target_ulong);
>}
>
> -*(target_ulong *
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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 format
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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=qemu&r1=1.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/10 17:43:49
Modified files:
target-m68k: translate.c
Log message:
Fix m68k FP register debug dumps.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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 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=qemu&r1=1.1&r2=1.2
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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=qemu&r1=1.128&r2=1.129
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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 softfloat.h
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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=qemu&r1=1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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-parallels.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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=qemu&r1=1.24&r2=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 file
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
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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=qemu&r1=1.26&r2=1.27
801 - 900 of 1782 matches
Mail list logo
