> I made minimal modifications in each target so that they can still work
> by using TCG and legacy "dyngen" micro operations. More work will be
> needed to convert each target to TCG, but it can be done progressively.
> Only the x86 and x86_64 targets have been significantly modified to use
> TCG.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 16:27:13
Modified files:
. : configure
Log message:
Use ARCH_CFLAGS in configure tests.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 17:35:41
Modified files:
. : exec-all.h
Log message:
Fix opparam_buf size estimate.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.7
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 19:20:13
Modified files:
. : configure
Log message:
Robustify source directory check.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 19:56:34
Modified files:
target-i386: translate.c
tcg: tcg-op.h tcg.c tcg.h
Log message:
Add TCG variable opaque type.
CVSWeb URLs:
http://cvs.savannah.gnu.org
> > but make
> > it configurable on the command line. That way, there are no surprises
> > ever. The rare people like me with an issue can just pass a command-line
> > parameter in.
>
> The point I was trying to make is that qemu could easily arbitrate the
> guest network based on how the host is
On Wednesday 06 February 2008, Jamie Lokier wrote:
> Paul Brook wrote:
> > > > but make
> > > > it configurable on the command line. That way, there are no
> > > > surprises ever. The rare people like me with an issue can just pass
> > > > a com
On Friday 08 February 2008, Rob Landley wrote:
> Grepping through the source code, I can find 3 places where this global
> variable is set (it's initialized to a default value of 1, there's
> a "no-code-copy" command line option that sets it to zero, and then it
> shows up in the test suite once).
On Friday 08 February 2008, Blue Swirl wrote:
> On 2/8/08, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > The patch takes a half of the memory and slows down the system. I
> > > think Qemu could be used instead. A channel (IO/MMIO) is created
> > > between the m
> The patch takes a half of the memory and slows down the system. I
> think Qemu could be used instead. A channel (IO/MMIO) is created
> between the memory allocator in target kernel and Qemu running in the
> host. Memory allocator tells the allocated area to Qemu using the
> channel. Qemu changes
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/10 02:41:15
Modified files:
. : translate-all.c
tcg: tcg.c tcg.h
Log message:
Fix TCG relocation bug (exposed by fault after brcond op). Add FIXME
for
On Sunday 10 February 2008, Blue Swirl wrote:
> On 2/9/08, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Blue Swirl wrote:
> > >> If you look at the patch, there are no timing dependencies; the only
> > >> parameter is the depth of the virtual queue. The exhaustion is
> > >> completely controlled
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/10 14:09:09
Modified files:
. : translate-all.c
tcg: tcg.c tcg.h
tcg/i386 : tcg-target.c
tcg/x86_64 : tcg-target.c
Log message
> > as far as i remember it was used to address something with
> > cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE
> > or ~TARGET_PAGE_SIZE,
> >
> > the fact is that i dont know if it ever fixed anything
>
> It fixes TARGET_PAGE_MASK, defined one line downscreen.
That doesn't reall
On Sunday 10 February 2008, Avi Kivity wrote:
> Paul Brook wrote:
> >>> as far as i remember it was used to address something with
> >>> cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE
> >>> or ~TARGET_PAGE_SIZE,
> >>>
>
> I think Paul Brook was concerned about a situation where a user
> reports a problem saying FOO is not working when running "qemu -hda ..."
> and suddenly the number of things that may have triggered the bug has
> grown by the size of the environment. Even if you manage
On Tuesday 12 February 2008, Rob Landley wrote:
> On Saturday 19 January 2008 15:10:09 Paul Brook wrote:
> > > In the absence of a global configuration file, a reasonably sane way to
> > > support this configuration system wide is to use an environmental
> > > variabl
> > Any news on the possible cvs->svn migration?
>
> To be perfectly honest, IMO there is little point moving an existing
> project from CVS to SVN.
I disagree. CVS has several fairly fundamental flaws (no global revision IDs,
unable to move files, and more subtle problems with branches/tags).
S
> If people don't like using environmental variables, I can accept that.
> Let's not pretend though that the reason is that we're protecting the
> end users :-)
It's more protecting me from end users :-)
I should have said part of the reason. I'll admit a large part is personal
preference.
Paul
On Saturday 16 February 2008, Christian Roue wrote:
> Hi all,
> I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
> --disable-gcc-check, I found compile fails as stated in configure before i
> disabled gcc check..
> Error message, points to a problem of dyngen not correctly d
> SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I
> don't think anything other than Linux runs in QEMU's Sun emulation (or
> for that matter, any of the non-PC QEMU emulators).
While linux is certainly the most most widely tested, I'm fairly sure both
vxWorks and SymbianOS h
> > Finally, it would perhaps be best if the block device emulators wrote
> > to the qemu console to complain if they give write errors. Otherwise
> > the errno value and other important information will be lost, which
> > makes debugging hard.
>
> If by 'qemu console' you mean stderr, then fine,
> Write errors for non-raw formats can easily be caused by a disk full
> situation on the host. Killing the guest hard is unfriendly for that
> situation.
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer. Reporting errors back to the host has its own set of pro
> Is savevm-upon-disk-full a realistic prospect?
Not particularly useful. If you're run out of disk space, chances are that
savevm will also fail.
Paul
On Thursday 21 February 2008, Arabinda Verma wrote:
> Hello Paul,
>
> Thanks for your reply.
>
> Please recommend some document or pointer on how to implement emulation of
> hardware.
Theere isn't any, just what's in the source. It's mostly fairly
straightforward once you get your head round it.
On Thursday 21 February 2008, Jerone Young wrote:
> The recent TCG code to replace dyngen code in qemu cvs has broken
> PowerPC host support (or from what is appears...anyone else who is not
> x86 or x86-64). Is anyone working to fix this ? Is there a plan to fix
> all the other hosts?
As far as p
> I'm not really familiar with the qemu development process; is this
> usually how it works? People are free to break things and assume others
> will fix it?
Not really. However this is fairly exceptional circumstances. The gcc3
dependency means it's getting harder and harder to build qemu at al
> Another point is that you should define TCG globals for each SPARC GPR.
> It was not done for i386 because I feared performance regressions when
> accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have
> this issue.
How would these be kept consistent with CPUState?
Paul
On Monday 25 February 2008, Rob Landley wrote:
> On Tuesday 08 January 2008 09:22:49 Alexander Graf wrote:
> > Apples hardware dongle sits withing the fan control. To get Mac OS X up
> > and running, this control device needs to be emulated and given the
> > correct dongle key. This key has to be g
> I still have problems (Pentium M, gcc (GCC) 4.1.2 20061115 (prerelease)
gcc4 isn't supposed to work.
Paul
On Wednesday 27 February 2008, Andreas Färber wrote:
> Am 27.02.2008 um 17:14 schrieb Paul Brook:
> >> I still have problems (Pentium M, gcc (GCC) 4.1.2 20061115
> >> (prerelease)
> >
> > gcc4 isn't supposed to work.
>
> And I thought that was the wh
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/03/04 23:52:48
Modified files:
tcg: tcg-op.h
Log message:
32-bit host sign extension fix (Juergen Lock).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot
> That's the '&' which is wrong here. The string can be accessed with
> *((uint32_t *)devid). So you can simply use:
>
> ret = le32_to_cpu(*((uint32_t *)devid))
No you can't. Even ignoring the aliasing violation, devid might not be
sufficiently aligned.
Paul
> gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
Which part of "gcc 4.x is not supported" didn't you understand?
Paul
On Saturday 15 March 2008, Peter Volkov wrote:
> Hello.
>
> I just wanted to point developers attention to the following bug:
> bugs.gentoo.org/212351 , comment #11 and further. The problem is that
> qemu does not compile any more on x86. I've tried recent snapshot
> (2008-03-15_05) and the problem
On Tuesday 08 September 2009, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
> > $subject says pretty much everything.
> >
> > extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c
> > and hw/pc.c is done slightly different, I've added a function to lookup
> > the boot drive instea
On Friday 11 September 2009, Anthony Liguori wrote:
> malc wrote:
> > And generalizations are always true. Anyhow, i'm explicitly against the
> > patch, so first obtain the express acknowledgment from the leaders,
> > otherwise i'll revert it should it go in.
>
> I'm adding the following patch to
> No question, this is a gdb issue. But, as it was confirmed in several
> discusssions with gdb people, it is a non-trivial thing to fix. So until
> qemu finds a gdb version attach with a rework x86 support, we have to
> work around it by switching the register layout as the guest switches
> its ex
On Wednesday 30 September 2009, Aurelien Jarno wrote:
> Currently zero extensions ops are implemented by a and op with a
> constant. This is then catched in some backend, and replaced by
> a zero extension instruction. While this works well on RISC
> machines, this adds a useless register move on n
On Thursday 08 October 2009, Mark McLoughlin wrote:
> Hi,
> Here's a series of patches which gets the ball rolling on adding
> a -netdev option.
>...
> The idea is to de-emphasise the vlan support, and instead make
> a nic directly connected to a host backend the default and recomme
On Monday 12 October 2009, Toni wrote:
> Hi guys,
> I found a solution for the problems with the fork and the exec under qemu
> user-mode.
> With the fork I enabled the NPTL and now it seems to work fine.
> For the exec the problem was that it was execute natively, and so the qemu
> process was kil
> > Some of the generated tcg code is not very optimal, for example a
> > single vld4.8 instruction can generate over 250 tcg ops. I did some
> > optimizations and got it under 200 but do you think it could be an
> > issue that a single instruction can expand to so many tcg ops? I mean
> > besides
> On the code itself, I don't really like the remaining, new_tmp(),
> dead_tmp(), and even more the fact that some functions can allocate
> (e.g load_reg) or free (e.g. store_reg) some TCG variables implicitely.
> This is a way to make errors by reallocating or forgetting to free some
>
> variable
On Thursday 22 October 2009, Aurelien Jarno wrote:
> On Wed, Oct 21, 2009 at 03:52:22PM +0200, Ulrich Hecht wrote:
> > sync allows concurrent accesses to locations in memory through different
> > TCG variables. This comes in handy when you are emulating CPU registers
> > that can be used as either
> I immediately reproduced the problem locally. It turns out that
> kvm reflects packets coming from one guest NIC on another guest
> NIC, and since both are connected to the same bridge we're getting
> endless packet storm. To a level when kvm process becomes 100%
> busy and does not respond to
On Monday 26 October 2009, Michael S. Tsirkin wrote:
> wmb must be at least a compiler barrier, even without SMP.
Why?
Paul
> But I certainly do _not_ want to update the SCSI disk
> emulation, as this is really quite tied to the SCSI parallel
> interface used by the old lsi53c895a.c.
This is completely untrue. scsi-disk.c contains no transport-specific code. It
is deliberately designed to be independent of both the tr
On Thursday 05 November 2009, Juan Quintela wrote:
> Daniel Jacobowitz wrote:
> > On Thu, Nov 05, 2009 at 05:17:46PM +0100, Juan Quintela wrote:
> >> How are you compiling?
> >> It works for me compiling in-tree with make -j3 (only 2 cores)
> >
> > I can reliably reproduce it by building all my QE
On Friday 06 November 2009, Gerd Hoffmann wrote:
>Hi,
>
> http://repo.or.cz/w/qemu/kraxel.git/shortlog/refs/heads/scsi.v6
>
> What is in there?
> (3) New interface for HBA <=> SCSIDevice interaction:
> * building on the new SCSIRequest struct.
> * the silly read_data/write_data
On Wednesday 11 November 2009, Scott Tsai wrote:
> I reworked the second patch in this series to add generic monitor commands
> to change the temperature reported from thermometers.
> Thermometer devices can now include "sensor.h" and call
> 'qemu_add_therm_temp_handler' to register themselves.
T
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2009 at 01:34:12AM +0000, Paul Brook wrote:
> > On Monday 26 October 2009, Michael S. Tsirkin wrote:
> > > wmb must be at least a compiler barrier, even without SMP.
> >
> > Why?
>
>
> > > > > wmb must be at least a compiler barrier, even without SMP.
> > > >
> > > > Why?
> > >
> > > Because virtio code might run on a separate thread from guest.
> > > If compiler reorders writes, guest might see inconsistent data.
> >
> > If you've got threads running in parallel (which may be
On Wednesday 11 November 2009, Anthony Liguori wrote:
> Hannes Reinecke wrote:
> > But why? Why do we have to emulate the entire HBA for the BIOS?
> > The HBA is emulated, too, and just uses the bdrv interface
> > internally anyway.
> > So IMHO it makes far more sense to skip the HBA emulation in
>
> The current qemu code *does* cache the response. scsi-disk caps the
> buffer at 128k (which is big enough for any request I've seen in my
> testing). scsi-generic has no cap.
That cap is important.
For scsi-generic you probably don't have a choice because of the way the
kernel interface works
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2009 at 01:45:35PM +0000, Paul Brook wrote:
> > If you don't need real barriers, then why does the kvm code have them?
>
> We need real barriers but AFAIK kvm does not have them :(
> IOW: virtio i
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2009 at 02:16:00PM +0000, Paul Brook wrote:
> > On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> > > On Wed, Nov 11, 2009 at 01:45:35PM +, Paul Brook wrote:
> > > > If you don&
>> That cap is important.
>> For scsi-generic you probably don't have a choice because of the way the
>> kernel interface works.
>
>Exactly. And why is the cap important for scsi-disk if scsi-generic
>does fine without?
With scsi-generic you're at the mercy of what the kernel API gives you, and i
On Tuesday 10 November 2009, Aurelien Jarno wrote:
> On Tue, Nov 10, 2009 at 11:19:40PM +0200, Blue Swirl wrote:
> > On Tue, Nov 10, 2009 at 10:50 PM, Aurelien Jarno
wrote:
> > > Please note that at least qemu-system-arm, qemu-system-mips and
> > > qemu-system-mipsel are broken by this commit:
>
> > This is latent breakage introduced by 45a50b1.
> > See commits 97fe84f5 (makes breakage obvious) and f2d7497 (fixed ARM).
> > MIPS still needs fixing.
>
> I can't find 97fe84f5 or f2d7497, what commits are those?
http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=97fe84f5
http://git.savanna
> I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got
> something up and running that works, and will pass data gathered from a
> char device on the host through to the virtio-rng driver on a guest copy
> of linux.
Why do you need a special device? Isn't a regular serial data stre
> > While sync appears attractive as a quick hack to achieve this, I think it
> > is liable to be abused, and cause us serious pain long-term. If you need
> > an easy solution then use ld/st (as with ARM VFP registers). If you want
> > a good solution then fix whichever bit of TCG makes accessing a
On Monday 16 November 2009, Gerd Hoffmann wrote:
> On 11/11/09 17:38, Paul Brook wrote:
> >>> That cap is important.
> >>> For scsi-generic you probably don't have a choice because of the way
> >>> the kernel interface works.
> >>
> >>
> >> It would require a mechanism to do enumeration and identification
> >> though.
> >
> > Huh? Do you want export *all* block devices via extboot? Will IDE
> > drives show up twice then?
>
> No, because SeaBIOS already has an ATA driver so we wouldn't want to
> expose IDE on the extboot bus.
> move scsi command from SCSIGenericReq to SCSIRequest.
Why? AFAICS This has precisely one user, and more importantly it is not
populated by scsi-disk.c.
Sharing common code is good. Implementing shared fields inconsistently or
putting implementation specific fields in common structures.
Paul
> add xfer mode
This should also be used by scsi-disc.c
Paul
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> Changes:
> * Move from open-coded lists to QTAILQ macros.
> * Move the struct elements to the common data structures
>(SCSIDevice + SCSIRequest).
> * Fix request cleanup in the destroy callback.
This feels like the abstraction boundaries w
> > The practical example below will explain it completely:
> >
> > 1) we take 4 common modern computers - CoreQuad + 8 GB Memory.
> > 2) we assemble a standard Linux cluster with 16 cores and 32G memory.
> > 3) and now - we run the only one virtual guest system, but give it ALL
> > available resou
On Tuesday 17 November 2009, Christoph Hellwig wrote:
> The subject is a bit confusing - it's not the full request parsing but
> just some helpers.
This is a good example of a patch with an insufficient commit message.
Given the way GIT treats the first line of the commit mesaage, my advice is to
> > In fact I'd much prefer to see extboot rewritten to just virtio-block.
>
> Hmm, I'd prefer something which is *not* used by the guest OS, so it is
> a pure bootloader thing. When using it to boot from scsi you don't want
> to have the disk show up twice (as virtio and scsi) in the guest.
You
On Tuesday 17 November 2009, Ian Molton wrote:
> Hi,
>
> Qemu currently is making a bit of a hash of parsing suffixes,
>
> Right now, it has:
>
> T, G, M, and K which are multiples of 1024 bytes - fair enough
>
> but it also has:
>
> k - 1024 (should be 1000)
>
> and b:
>
> Byte (also wron
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> On 11/17/09 13:36, Paul Brook wrote:
> >>> In fact I'd much prefer to see extboot rewritten to just virtio-block.
> >>
> >> Hmm, I'd prefer something which is *not* used by the guest OS, so it is
>
> > Why aren't you also using this function in scsi- disc.c? Surely that's the
> > whole point of moving it into common code.
>
> Same as with the command move: next patch series will rework scsi-disk
> to put the new fields and functions into use.
Hmm, maybe you need to rethink your patch sequen
> > That's an option, basically keeping the list (or only one ?) of aliased
> > TCG variables for each of them, and freeing the others before using one.
>
> Yeah, only one. I don't think this should be getting overengineered (and
> thus slow) :-).
> Doesn't really sound hard, does it? Any TCG magi
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> Add a greeting string to CharDriverState which is printed after
> initialization. Used to have the qemu vc consoles labeled. This
> way we can avoid walking all the chardevs a second time after
> initialization just to print the greeting.
I thi
On Monday 23 November 2009, Gerd Hoffmann wrote:
> On 11/20/09 18:41, Paul Brook wrote:
> > On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> >> Add a greeting string to CharDriverState which is printed after
> >> initialization. Used to have the qemu vc consoles lab
On Monday 23 November 2009, Gerd Hoffmann wrote:
> On 11/23/09 14:26, Paul Brook wrote:
> > I thinking more that this should be done by the character backend itself.
> > For example, the "graphical" consoles should probably be putting this as
> > part of the wind
On Sunday 22 November 2009, Stefan Weil wrote:
> All files config-devices.mak are copies from files in
> directory default-configs.
See commit a992fe3, specifically "make defconfig".
Paul
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
> > 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
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
> 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 +
> 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
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
> Can anyone point me to the place in the code where the simulated program
> counter is determined after an exception?
cpu_restore_state
Paul
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
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
> > 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
> > 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
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
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
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
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
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
> 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
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
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
> 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
On Wednesday 18 April 2007 16:19, tang peilei wrote:
> in qemu's doc, i found it support some arm integrator/cp board and arm926e
> or arm1026e cpu.
> but if i can choose to use arm926e cpu or arm1026e cpu ???
Use the -cpu commandline option.
> when i build a linux kernel image, i let it run on q
> > If you're interressed in such a feature, you may take a look of what
> > I've done in hw/ppc405_uc.c. There are some device sharing the same
> > memory page on those microcontrollers so I introduced a fake device
> > called mmio that allow to register multiple devices into a single page
> > in
> > While you're fixing this, it would be good to fix overlapping devices as
> > well ;-) Currently if you (temporarily) have overlapping regions then
> > remove one of them you end up with unmapped memory.
>
> What is the correct behavior in such a case ? What device would you
> actually see ? May
601 - 700 of 1782 matches
Mail list logo
