Re: [Qemu-devel] [sneak preview] major scsi overhaul
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 if the guest hardware/OS isn't cooperative then you loose. With scsi-disk we can do significantly better. The only way to make your API work is to skip straight from step 3 to step 6, which effectively looses the command queueing capability. It doesn't. The disconnect and thus the opportunity to submit more commands while the device is busy doing the actual I/O is there. Disconnecting on the first DMA request (after switching to a data phase and transferring zero bytes) is bizarre behavior, but probably allowable. However by my reading DMA transfers must be performed synchronously by the SCRIPTS engine, so you need to do a lot of extra checking to prove that you can safely continue execution without actually performing the transfer. It may be that it's hard/impossible to get both command queueing and zero-copy. I have it working. More likely you have a nasty hack that happens to work with the Linux drivers. IIUC you're pretending that the DMA completed and eventually disconnecting the device, assuming that nothing will read that data until the command complete notification is received. Consider the case there the guest transfers the data from a single command in two blocks, and has the HBA raise an interrupt in-between so that it can start processing before the command completes. This processing could even be done by the SCRIPTS engine itself, or a guest could even reuse the buffer for the second DMA block. Paul
Re: [Qemu-devel] arm, mips and mipsel broken
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 aurel...@aurel32.net wrote: Please note that at least qemu-system-arm, qemu-system-mips and qemu-system-mipsel are broken by this commit: Given that none of the devices touched by the commit should be used by these targets, the breakage comes from just the single new call to qemu_system_reset in vl.c. This means that the reset functions for those boards and devices must be awfully buggy. I'll try to have a closer look at the problem tomorrow, if I can't find the problem, it's what I'll commit. This is latent breakage introduced by 45a50b1. See commits 97fe84f5 (makes breakage obvious) and f2d7497 (fixed ARM). MIPS still needs fixing. Paul
Re: [Qemu-devel] arm, mips and mipsel broken
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.savannah.gnu.org/cgit/qemu.git/commit/?id=f2d7497 Paul
Re: [Qemu-devel] virtio-rng
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 stream (i.e. multiport virtio-console) sufficient? You can then connect that to your source of random data (e.g. /dev/random) without requiring any changes to qemu. Paul
Re: [Qemu-devel] [PATCH] gdbstub: x86: Switch 64/32 bit registers dynamically
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 execution mode between 16/32 and 64 bit. Again, absolutely not. Changing the register set reported to a connected gdb is *never* correct. An option (possibly monitor command) to change the register set reported to gdb *before* a connection is establisted, that may be acceptable. Paul
Re: [Qemu-devel] [PATCH 1/3] tcg: add ext{8,16,32}u_i{32,64} TCG ops
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 non-RISC machines. Example on x86: ext16u_i32 r1, r2 is translated into mov%eax,%ebx movzwl %bx, %ebx while the optimized version should be: movzwl %ax, %ebx I don't like your solution. Having two operations that do the same thing is bad, especially when we have no way of converting one into the other, and no clear indication which is best. I think we need to understand why does the original code introduces an extra copy. At first glance there's no good reason for it to be there. Paul
Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option
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 recommended configuration. We want this because it is only with this configuration that we feasibly add optimizations like GSO support or vhost-net. If we're going to introduce point-point connections then IMO everything should be a point-point connection. Having separate point-point and multiple-peer cases is just going to come back and bite us later. Once you have a symmetric point-point API, negotiation of features (such as offload, filtering, etc) should be relatively straightforward. Device creation and port connection should be separate events, with feature negotiation occurring at connection. This gives you hotplug for free, and avoids ordering issues. vlan functionality is implemented via a fairly trivial hub device that has many ports and doesn't implement any of the fancy optional features. Paul
Re: [Qemu-devel] PATCH: Qemu user-mode - fork - exec -
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 killed by the exec, so I simply called the exec for a new instance of qemu, also this seems to work fine. Let me know what do you think: It will break horribly for shell scripts, multi-arch systems, etc. This is something the host kernel should really be taking care of. Your patch also appears to have a load of unrelated cruft. Paul
Re: [Qemu-devel] [PATCH 00/18] target-arm cleanup
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 the fact that it causes TBs for only one or two guest instructions to be generated. Fabrice wrote this (tcg/README): Don't hesitate to use helpers for complicated or seldom used target intructions. There is little performance advantage in using TCG to implement target instructions taking more than about twenty TCG instructions. How applicable is it, I can't say. It'd probably be a good thing to benchmark the two versions, TCG vs helper. The problem is that you can not do memory accesses from within a helper function. Paul
Re: [Qemu-devel] [PATCH 00/18] target-arm cleanup
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
variables, and that leads to strange code like:
|if (rn == 15) {
|tmp = new_tmp();
|tcg_gen_movi_i32(tmp, 0);
|} else {
|tmp = load_reg(s, rn);
|}
There is actually logic behind this
Consider the obvious implementation of the neg instruction:
val = load_reg(rn);
tcg_gen_neg_i32(val, val);
store_reg(rd, val);
With the current code this is safe. However if load_reg returns cpu_R[n]
instead of a temporary then the above code will incorrectly clobber the source
register.
My theory was that tracking down an accidental write to a source register is
much harder than tracking down a mismatched temporary.
Paul
Re: [Qemu-devel] Re: [PATCH 01/12] TCG sync op
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 32 or 64 bit, as TCG doesn't know anything about aliases. See the s390x target for an example. Fixed sync_i64 build failure on 32-bit targets. Looking more in details to the use case of this patch, I think it can be useful in QEMU. However I don't feel very comfortable in merging it without having the opinion of more persons. Paul, Malc Blue Swirl or others, any opinion? I don't think this is the right solution. IIUC the basic problem is that we have a register file where adjacent pairs of 32-bit registers are also accessed as a 64-bit value. This is something many other targets need to do (at least ARM, PPC, MIPS and SPARC). 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 pair of registers horribly slow. We already have some support for this (concat_i32_i64). Paul
Re: [Qemu-devel] net packet storms with multiple NICs
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 anything but `kill -9'. You created a network loop. It is working exactly as expected. Create the same topology with a physical network hub and a pair of NICs and you'll get the same end result. Paul
Re: [Qemu-devel] [PATCH] qemu/virtio: make wmb compiler barrier + comments
On Monday 26 October 2009, Michael S. Tsirkin wrote: wmb must be at least a compiler barrier, even without SMP. Why? Paul
Re: [Qemu-devel] [PATCH 0/4] megaraid_sas HBA emulation
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 transport (e.g. parallel SCSI or USB) and the mechanism by which the initiator transfers data to the host. Paul
Re: [Qemu-devel] [PATCH V3 0/3] usb-gotemp: USB thermometer emulation
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. This is just another HID device. As discussed previously in the context of the wacom tablet, duplicating this code is bad (IMO usb-wacom.c should ever have been committed). Instead you should be sharing the existing code. Paul
Re: [Qemu-devel] Re: [PATCH 05/26] Unexport ticks_per_sec variable. Create get_ticks_per_sec() function
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 Juan's series. The result is that get_ticks_per_sec() should be optimized to a literal value. The result being that uses of it are faster than they were before (not it should matter). Having this as a function/variable is completely misleading. It is and always will be 10. You'd be better off using QEMU_TIMER_BASE directly. Paul
Re: [Qemu-devel] CVS build error
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
Re: [Qemu-devel] [PATCH] mipsnet incorrect device ID fix
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
[Qemu-devel] qemu/tcg tcg-op.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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=qemur1=1.7r2=1.8
Re: [Qemu-devel] Still compile problems with TCG
I still have problems (Pentium M, gcc (GCC) 4.1.2 20061115 (prerelease) gcc4 isn't supposed to work. Paul
Re: [Qemu-devel] Still compile problems with TCG
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 whole point in breaking non-x86 hosts! In the long term, yes. However the gcc3 dependency will remain until the tcg migration has been completed. Paul
Re: [Qemu-devel] [PATCH 4/9] AppleSMC device
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 given via the command line. How is the key obtained? I have access to a couple of macintoshes, but I don't know what code to run on them to snapshot the key? Two minutes with google suggests the correct values are: OSK0 [ch8*] (bytes 6f 75 72 68 61 72 64 77 6f 72 6b 62 79 74 68 65 73 65 77 6f 72 64 73 67 75 61 72 64 65 64 70 6c) OSK1 [ch8*] (bytes 65 61 73 65 64 6f 6e 74 73 74 65 61 6c 28 63 29 41 70 70 6c 65 43 6f 6d 70 75 74 65 72 49 6e 63) Which are obviously not machine specific values. Paul
Re: [Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
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
Re: [Qemu-devel] Qemu emulation for PXA320 based board
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. Paul
Re: [Qemu-devel] TCG code in qemu has broken PPC host support .... anyone working on this?
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 plans go, I expect they'll get fixed when someone implements them. Someone posed (incomplete) sparc host support fairly recently. Your best bet is probably just to follow this list, and post here when you start working on a particular target. Paul
Re: [kvm-ppc-devel] [Qemu-devel] TCG code in qemu has broken PPC host support .... anyone working on this?
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 all. Paul
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
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, but please don't spew log messages to the monitor console, because that'll make it very hard to interact with reliably from management tools. Actually I think a better default would be for qemu to die right there and then. If the host is getting IO errors then something is badly wrong, and you're probably screwed anyway. Paul
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
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 problems. Many guest OS effectively just lock up when this occurs. Paul
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
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
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
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 have been run inside qemu ARM emulation. Paul
Re: [Qemu-devel] Patch for compiling with GCC 4
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 detecting function ends on i386 when last instruction is a jump. I applied following change and successfully compiled/run qemu i386. This extra test check for a relative backward jump to function exit ret, gcc 4 apparently generates a few of these. You patch is wrong. The dyngen error is correct. Paul
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
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
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
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 to tell the user to pastebin the environment, it may have changed by then. I'm pretty sure Paul knows how to list the env variables :) Indeed. I see many, many users complain that qemu dies because of SDL errors. Almost without fail this is because they're running qemu in a different environment (e.g. under su as root), so are using an environment that can't connect to their X server. Running set | grep QEMU is fine, except that it has to be done in the same environment as qemu runs in. You'd be surprised how many users are incapable of doing what seems to be a straightforward task. This is similar to why I dislike qemu automagically guessing settings. If you force everything to be explicitly specified (or use fixed defaults) then there's no margin for error. If behaviour depends on external factors then you can guarantee the person stuck between you (the expert) and the misbehaving application will have no clue how to determine or control those external factors. Paul
Re: [Qemu-devel] What does code_copy_enabled do?
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). SVN fixes these, and in most cases works as a direct drop-in replacement for CVS. While I can see that distributed revision control systems do enable some interesting possibilities, there's certainly no clear winner. All of them seem to have have fairly serious issues with either usability, portability, scalability, and/or require learning a whole new workflow. I'm sure advocates of each system will claim that their system is the best, but I remain unconvinced. SVN may not have the bells and whistles of some of the more exotic systems. However it is is well tested proven technology, and IMO universally better than CVS. Paul
Re: [Qemu-devel] Re: 2.6.24 says serial8250: too much work for irq4 a lot.
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 by target OS access patterns. Thanks, this clarified the difference. But I'll rephrase my original comment: The patch looks OK, but the simulated FIFO exhaustion should benefit all devices, as discussed here: http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html The difference is you *can't* do that in a general layer. What makes you think that is impossible? IIUC the proposed patch makes the serial driver return an empty FIFO exactly once, them immediately continue receiving data. Throughput should be approximately the same, you've just got a bit of extra overhead to process the additional interrupts. This is very different to the previous patch which did time-based throughput limiting. You can't do this in generic code because there's no way to guess when the guest os has seen the FIFO empty condition. The best you can do is pause for some arbitrary length of time, which is both unreliable (the guest OS may not have got to far enough yet, especially if the host machine is heavily loaded), and has a significant negative impact on throughput. Also win2k install hack in ide.c seems to be related to this problem, so even more generic solution would be desirable. IIUC the win2k hack is an actual timing problem. The win2k IDE drivers are buggy, and fall over if the drive responds too soon. Paul
[Qemu-devel] qemu translate-all.c tcg/tcg.c tcg/tcg.h tcg/i3...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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: Simplify TCG relocation bugfix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.26r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemur1=1.2r2=1.3
Re: [Qemu-devel] Re: [PATCH 2/6] Use correct types to enable 2G support (v2)
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 really answer the question. What was wrong with the original definition? Paul
Re: [Qemu-devel] Re: [PATCH 2/6] Use correct types to enable 2G support (v2)
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, the fact is that i dont know if it ever fixed anything It fixes TARGET_PAGE_MASK, defined one line downscreen. That doesn't really answer the question. What was wrong with the original definition? There are many instances of ((physical address) TARGET_PAGE_MASK) scattered throughout the code. With 64-bit physical addresses, this causes truncation. No it doesn't. TARGET_PAGE_MASK will be sign extended to the width of physical_address. This is why I asked for a concrete example of something that broke. Paul
[Qemu-devel] qemu translate-all.c tcg/tcg.c tcg/tcg.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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 annother potential bug. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemur1=1.3r2=1.4
Re: [Qemu-devel] Kernel memory allocation debugging with Qemu
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 memory allocator in target kernel and Qemu running in the host. Memory allocator tells the allocated area to Qemu using the channel. Qemu changes the physical memory mapping for the area to special memory that will report any reads before writes back to allocator. Writes change the memory back to standard RAM. The performance would be comparable to Qemu in general and host kernel + Qemu only take a few MB of the memory. The system would be directly usable for other OSes as well. The qemu implementation isn't actually any more space efficient than the in-kernel implementation. You still need the same amount of bookkeeping ram. In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by using a bitmask rather than whole bytes. Qemu would not track all memory, only the regions that kmalloc() have given to other kernel that have not yet been written to. Memory still has the be tracked after it has been written to. You can only stop tracking after the whole page has been written to, and there's no easy way to determine when that is. The kernel actually has better information about this because it can replace the clear/copy_page routines. If you're only trying to track things with page granularity then that's a much easier problem. Performance is a less clear. A qemu implementation probably causes less relative slowdown than an in-kernel implementation. However it's still going to be significantly slower than normal qemu. Remember that any checked access is going to have to go through the slow case in the TLB lookup. Any optimizations that are applicable to one implementation can probably also be applied to the other. Again, we are not trapping all accesses. The fast case should be used for most kernel accesses and all of userland. Ok. So all the accesses that the in-kernel implementation intercepts. That's obviously a significant number. If it wasn't then performance wouldn't matter. The number of accesses intercepted and amount of bookkeeping required should be the same in both cases. The only difference is the runtime overhead when an access in intercepted. qemu goes through the slow-path softmmu routines, the in kernel implementation takes a pagefault+singlestep. Paul
Re: [Qemu-devel] Kernel memory allocation debugging with Qemu
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 the physical memory mapping for the area to special memory that will report any reads before writes back to allocator. Writes change the memory back to standard RAM. The performance would be comparable to Qemu in general and host kernel + Qemu only take a few MB of the memory. The system would be directly usable for other OSes as well. The qemu implementation isn't actually any more space efficient than the in-kernel implementation. You still need the same amount of bookkeeping ram. In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by using a bitmask rather than whole bytes. Performance is a less clear. A qemu implementation probably causes less relative slowdown than an in-kernel implementation. However it's still going to be significantly slower than normal qemu. Remember that any checked access is going to have to go through the slow case in the TLB lookup. Any optimizations that are applicable to one implementation can probably also be applied to the other. Given qemu is significantly slower to start with, and depending on the overhead of taking the page fault, it might not end up much better overall. A KVM implementation would most likely be slower than the in-kernel. That said it may be an interesting thing to play with. In practice it's probably most useful to generate an interrupt and report back to the guest OS, rather than having qemu reports faults directly. Paul
Re: [Qemu-devel] What does code_copy_enabled do?
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). What I can't find is any code ever actually checking or using the value put into this variable It got ripped out a while back. Paul
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
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 configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. Paul
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
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 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 configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. If it _doesn't_ guess, i.e. uses the fixed default of 10.0.2.x (or any other), then it's _not_ host independent. Well, obviously anything that involves talking to the host or the outside world is never going to completely host independent. Your case will also break if you run it on a machine with no internet connection. The environment inside qemu is consistent. If you have qemu automagically guess things then the gust OS also has to be capable of coping with things changing underneath it. Paul
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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=qemur1=1.185r2=1.186
[Qemu-devel] qemu exec-all.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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=qemur1=1.74r2=1.75
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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=qemur1=1.186r2=1.187
[Qemu-devel] qemu target-i386/translate.c tcg/tcg-op.h tcg/t...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 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/viewcvs/qemu/target-i386/translate.c?cvsroot=qemur1=1.77r2=1.78 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemur1=1.1r2=1.2
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable 2G support
I agree with the fact that ram_size should be 64 bit. Maybe each machine could test the value and emit an error message if it is too big. Maybe an uint64_t would be better though. uint64_t is probably more reasonable. I wouldn't begin to know what the appropriate amount of ram was for each machine though so I'll let the appropriate people handle that :-) I'd say ram_addr_t is an appropriate type. Currently this is defined in cpu-defs.h. It should probably be moved elsewhere because in the current implementation it's really a host type. If we ever implement 2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). Paul
Re: [Qemu-devel] 3D acceleration
On Friday 01 February 2008, Johannes Schindelin wrote: Hi, On Fri, 1 Feb 2008, Christian Laursen wrote: Gervase Lam [EMAIL PROTECTED] writes: From my minimal understanding of what he is saying, it seems he would prefer there to be a BOCHS graphics adapter, which would then pass the OpenGL commands from Windows to Linux OpenGL. Also, Direct3D commands would be passed from Windows to Linux Wine. I don't care much about the 3D stuff but wouldn't a BOCHS graphics adapter with a special driver for the guest OS allow arbitrary screen resolutions with minimal effort? Yes, I agree. Since it is minimal effort, when do you start? Or you could just use the VMware adapter that already exists. Paul
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable 2G support
virtio could still be made to work with map cache. You would just have to change it to be able to map more than one page contiguously. As I mentioned though, it just starts getting ugly. That's why you should be using the cpu_physical_memory_rw routines :-) Anything that assume large linear accesses (Currently only some of the embedded LCD controllers) is going to break as soon as you start introducing IOMMUs. There have been several threads on this list about having a sane DMA infrastructure. Paul
[Qemu-devel] qemu Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 08/02/01 22:45:05 Modified files: . : Makefile.target Log message: Add missing dependencies on generated files (for parallel build). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.242r2=1.243
Re: [Qemu-devel] TCG
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. When playing with this a bit with the ARM target I found it very easy to get variables, immediate values and register indexes mixed up. e.g. using gen_add_i32 instead of gen_add_i32, or gen_mov_i32(foo, rn) instead of gen_ld_i32(foo, cpu_env, offsetof(CPUState, regs[rn]). Would you object to a patch that changed then gen_* functions in tgc_op to use an opaque type for variables? For performance reasons we probably want to keep it as an in in production builds, but for debugging it's nice to be able to catch the types of error mentioned above. IMHO it also helps to improve the clarity of the code. The changes should be mostly mechanical. Paul
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable 2G support
On Thursday 31 January 2008, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
You've still got a fairly random mix of unsigned long, ram_addr_t and
uint64_t.
-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
+typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size,
This breaks every target except x86.
+ if (above_4g_mem_size) {
+ rtc_set_memory(s, 0x5b, (unsigned int)above_4g_mem_size 16);
+ rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size 24);
+ rtc_set_memory(s, 0x5d, above_4g_mem_size 32);
This will cause warnings on 32-bit hosts.
+if (ram_size = 0xe000 ) {
+above_4g_mem_size = ram_size - 0xe000;
+ram_size = 0xe000;
+}
I'm fairly sure this will break the VMware VGA adapter:
pci_vmsvga_init(pci_bus, ds, phys_ram_base + ram_size,
ram_size, vga_ram_size);
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
This seems fairly arbitrary. Why? Any limit is certainly target specific.
Paul
[Qemu-devel] Re: [PATCH 4/6] Tell BIOS about the number of CPUs
-cmos_init(ram_size, above_4g_mem_size, boot_device, hd); +cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus); smp_cpus is a global variable. Why bother passing it around? Are the CMOS contents documented anywhere? Paul
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable 2G support
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL) This seems fairly arbitrary. Why? Any limit is certainly target specific. On a 32-bit host, a 2GB limit is pretty reasonable since you're limited in virtual address space. On a 64-bit host, there isn't this fundamental limit. If a target may have it's own limit but there is definitely a host imposed limit. 2047GBs is a somewhat arbitrary limit though for 64-bit hosts. If you have a more logical suggestion, I'll happily change it. Don't have a limit at all. The reason we have the current 31-bit limit is because qemu is/was known to use a signed int do hold the size. With your code 64-bit hosts should be able to handle anything atoi can parse. As mentioned on IRC, I also noticed that ram_save hasn't been updated. Paul
[Qemu-devel] Re: [PATCH 4/6] Tell BIOS about the number of CPUs
Are the CMOS contents documented anywhere? No, but if you have a suggestion of where to document them, I'll add documentation. I suggest in or with the BIOS sources. As we're using a common BIOS it seems a good idea to make sure this kind of things is coordinated. Paul
Re: [Qemu-devel] Merging KVM QEMU changes upstream
Is this a reasonable merge strategy? We won't introduce regressions but I can't guarantee these new things will work cross-architecture. I think it depends to some extent whether things will need rewriting to be made cross-architecture. In particular if this requires interface changes. This means either breaking existing guests, or having to support both interfaces. e.g. the extboot stuff seems like something that should be usable by all targets, except that the current interface looks like it's inherently x86 specific. Paul
Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target
Why don't you just put your custom flags in CFLAGS, not CPPFLAGS? The former is deliberately left for the user to override. Several (but not all AFAICT) of the target subdirectory Makefiles set CFLAGS. Really? Which ones? Paul
Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target
What I mean is: if you want for any reason to build qemu in a weird way then you're going to have to edit config-host.mak (or somewhere similar) in any case. You probably want to set some CPPFLAGS as well as various other things. If you do this at the moment then you have to reproduce all of the CPPFLAGS -I settings and so on from Makefile.target in your own setting that you add to config-host.mak. In that case you should always provide a definition in config-host.mak. Under some circumstances make may inherit initial values from elsewhere. The rules for make variables are sufficiently twisty that it's best to be explicit, rather than allowing a subset of the ways of defining that variable. Paul
Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target
Saying CPPFLAGS+= is much more convenient if for any reason the external build environment would like to pass unusual CPPFLAGS. No. This doesn't do what you thing it does. The most common way of overriding these variables is to pass them on the commandline, i.e. make CPPFLAGS=-blah. This overrides all assignments to that variable including +=. Paul
Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target
Providing a definition in config-host.mak involves duplicating the value, which can't be right. Huh? No it doesn't. config-host.mak contains CPPFLAGS= then Makefile.target contains CPPFLAGS+=whatever If there's no other way to do it then there should be a reference to USER_CPPFLAGS or some such but frankly that's a pain and overkill. Why don't you just put your custom flags in CFLAGS, not CPPFLAGS? The former is deliberately left for the user to override. Paul
Re: [Qemu-devel] WE NEED GCC 4 please
Well, what about adding a new backend phase to gcc generating what we expect for our purpose? Ok, it is rather easy to have a branch in gcc, harder to have it accepted in the main-stream gcc... :-) With a good argumentation... IMHO (as a full time gcc developer) it's easier to just implement a code generator from scratch. Paul
Re: [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
On Sunday 20 January 2008, Filip Navara wrote: Hello, attached is a patch that implements the SMBIOS within the Bochs BIOS code. Complete list of changes: This should be submitted to the Bochs list. Paul
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
In the absence of a global configuration file, a reasonably sane way to support this configuration system wide is to use an environmental variable. QEMU already uses a number of global variables for configuring audio options. I'd really prefer we didn't do this, and preferably obsoleted/removed the existing environment variables. IMHO using environment variables is a really bad idea and should be avoided wherever possible. Environment variables are about the worst user interface I can think of. For a start they're a global resource, which is limited on some systems. It's also extremely hard to determine what environment a user is running. This makes reproducing user bugs somewhere between hard and impossible. Paul
Re: [Qemu-devel] Re: [kvm-devel] [PATCH] e1000 emulation code
the next step would be to emulate LSI SCSI chips, eh? Qemu already does. Paul
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tuesday 08 January 2008, Dor Laor wrote: On Tue, 2008-01-08 at 01:30 +, Paul Brook wrote: -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. It still works even without accurate timing demands. Only isochronous mode will have problems and it is not yet supported for ehci. It could also cause problems for periodic interrupt transfers. It's not uncommon for linux hosts to have a minimum timer period of 10ms (100Hz). This means the periodic list will be traversed 80x slower than it should, so a typical for a mouse or tablet with a 10ms poll interval will only be polled every 800ms. 800ms lag on a mouse is unacceptable. The existing USB hosts have similar issues. However the problem is an order of magnitude less severe, so isn't noticeable under normal circumstances. Requiring a 8kHz timer is a non-starter. The 100kHz retry timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul Latest Linux host compiled HR_TIMER and DYN_TICK can give pretty good accuracy, surely it can provide 1khz and probably even 8khz Only if the host is lightly loaded. qemu tends to use a lot of CPU, so scheduler heuristics will tend to give it a low priority. c.f. an mp3 player that uses a small amount of CPU, so the scheduler will try hard to provide prompt signal delivery. Paul
Re: [Qemu-devel] [RFC] ide: multi-profile DVD-ROM support v2
+/* Some generally useful CD-ROM information */ +#define CD_MINS 99 /* max. minutes per CD */ +#define CD_SECS 60 /* seconds per minute */ +#define CD_FRAMES 75 /* frames per second */ +#define CD_FRAMESIZE2048 /* bytes per frame, cooked mode */ +#define CD_MAX_BYTES 912384000 /* multiply all of the above */ +#define CD_MAX_SECTORS 1782000 /* divide by 512 */ The last two should be calculated from the first, not hardcoded values. Paul
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
-The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. Requiring a 8kHz timer is a non-starter. The 100kHz retry timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
On Friday 04 January 2008, Markus Hitter wrote: Am 03.01.2008 um 15:02 schrieb Paul Brook: Having to check every return value is extremely tedious and (as you've proved) easy to miss. Checking every return value is a measure for programming reliable code. Never failing is even more reliable. If the allocation fails we don't have any viable alternatives, so we may as well stop right there. Stop != segfault? Yes. What about a meaningful exit message? Out of memory is a fairly comprehensive description of the problem. In fact I'd say it's much more informative than random widget the user doesn't know or care about failed to initialize. Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
The latter depends how general you want the solution to be. One possibility is for the device DMA+registration routines map everything onto CPU address space. Interesting idea, do you mean that all individual bus address spaces could exist in system view in the same large address space outside the target CPU address space? Then some of the translations could become simple offset operations. No, I was basically assuming that all cpu-device mappings are linear offsets. This means you need almost no changes to the current CPU access code. You can also arrange for all device DMA requests to be translated into CPU physical addresses (VIA IOMMU, or whatever), then treat them the same as if they were CPU accesses. However on second thoughts this probably isn't such a clever idea. There are some potentially interesting cases it can't handle. I'll see if I can come up with an actual proposal. My current theory is that we should be able to combine the bus mappings with the TLB fill, which should help mitigate the overhead. Paul
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
On modern operating systems, allocations only return zero when you exhaust virtual memory. Returning nonzero doesn't mean you have enough memory, because it's given you a redundant copy on write mapping of the zero page and will fault in physical pages when you write to 'em, which has _no_ return value. Instead, the out of memory killer will shoot your program in the head in the middle of it's run Decent operating systems allow the system administrator gets to choose how optimistic memory allocation is. You're describing wildly-optimistic mode, which is often but not always the default. Paul
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
We currently don't check the return value in the init function where the new timer is created but do check it wherever it is used which is backwards and wasteful. You would prefer that qemu just segfaults rather than die gracefully? I think qemu should die before it returns from qemu_malloc. Having to check every return value is extremely tedious and (as you've proved) easy to miss. If the allocation fails we don't have any viable alternatives, so we may as well stop right there. Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
As I said earlier, the only correct way to handle memory accesses is to be able to consider a memory range and its associated I/O callbacks as an object which can be installed _and_ removed. It implies that there is a priority system close to what you described. It is essential to correct long standing PCI bugs for example. This should be feasible, though raises a few questions. Does this mean another API for stacked registration, or should stacking happen automatically with current API? A new function is needed for removal. What could be the API for setting priorities? How would multiple layers be enabled for multiple devices at same location? How can a higher level handler pass the request to lower one? Do we need a status return for access handler? I don't think passing through requests to the next handler is an interesting use case. Just consider a device to handle all accesses within its defined region. If an overlapping region is accessed then at best you're into highly machine dependent behavior. The only interesting case I can think of is x86 where a PCI region may be overlayed on top of RAM. A single level of priority (ram/rom vs. everything else) is probably sufficient for practical purposes. The most important thing is that when one of the mappings is removed, subsequent accesses to the previously overlapped region hit the remaining device. A few use cases: Partial width device unassigned ROM RAM unassigned SBus controller EBus controller Device unassigned Other direction (for future expansion): Device DMA controller SBus controller IOMMU RAM unassigned I think these are different things: - Registering multiple devices within the same address space. - Mapping access from one address sapce to annother. Currently qemu does neither. The former is what Fabrice is talking about. The latter depends how general you want the solution to be. One possibility is for the device DMA+registration routines map everything onto CPU address space. Paul
Re: [Qemu-devel] performance monitor
... Ok, to cut a long question short: Is there any hardware support im qemu for doing monitoring (that goes deeper than using time) and has anyone ever tested something that could work? Probably your application wants the performance counters. Qemu doesn't emulate those. Besides which, qemu is not cycle accurate. Any performance measurements your make are pretty much meaningless, and bear absolutely no relationship to real hardware. Paul
Re: [Qemu-devel] performance monitor
Does anyone have an idea on how I can measure performance in qemu to a somewhat accurate level? I have modified qemu (the memory handling) and the linux kernel and want to find out the penalty this introduced... does anyone have any comments / ideas on this? Short answer is you probably can't. And even if you can I won't believe tyour results unless you've verified them on real hardware :-) With the exception of some very small embedded cores, Modern CPUs have complex out of order execution pipelines and multi-level cache hierarchies. It's common for performance to be dominated by these secondary factors rather than raw instruction throughput. Exactly what features dominate performance is very application specific. Determining which factor dominates is unlikely to be something qemu can help with. However if e.g. you know that for your application there's a good correlation was between performance and L2 cache misses you could instrument qemu to and a L1/L2 cache model. The overhead will be fairly severe (easily 10x slower), and completely screw up any realtime measurements. However it would produce some useful cache use statistics that you could use to guesstimate actual performance. This is similar to how cachegrind works. Obviously if your application isn't cache bound then these figures will be meaningless. Paul
Re: [Qemu-devel] performance monitor
Well, the measuring I had in mind partly concentrats on TLB misses, page faults, etc. (in addition to the cycle measuring). guess i'll have to implement something for myself in qemu :-/ Be aware that the TLB qemu uses behaves very differently to a real CPU TLB. If you want to get TLB miss statistics you'll need to model a real TLB for that separately. Page faults should be straightforward, but any half-decent guest OS would be able to tell you those anyway. Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
Also the opaque parameter may need to be different for each function, it just didn't matter for the unassigned memory case. Do you really have systems where independent devices need to respond to different sized accesses to the same address? Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
On Wednesday 02 January 2008, Blue Swirl wrote: On 1/2/08, Paul Brook [EMAIL PROTECTED] wrote: Also the opaque parameter may need to be different for each function, it just didn't matter for the unassigned memory case. Do you really have systems where independent devices need to respond to different sized accesses to the same address? I don't think so. But one day unassigned or even normal RAM memory access may need an opaque parameter, so passing the device's opaque to unassigned memory handler is wrong. I'm not convinced. Your current implementation seems to introduce an extra level of indirection without any plausible benefit. If you're treating unassigned memory differently it needs to be handled much earlier that so you can raise CPU exceptions. Paul
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state)); + if (!s) + return NULL; None of the callers bother to check the return value, And even if they did I don't think there's any point trying to gracefully handle OOM. Just abort and be done with it. I suggest guaranteeing that qemu_malloc will never return NULL, and removing the null checks from all the various users. Paul
Re: [Qemu-devel] adding a new PCI device support in QEMU
On Tuesday 01 January 2008, Vinod E wrote: Hi, I have a special kind of PCI device on my system. I want QEMU to emulate that device and have Guest VM see that. Can someone point me to any documentation available on how I/O device handling is done in QEMU? Read the source. There are plenty of examples of PCI devices (e.g. USB host adapters, LSI scsi adapter and various network cards). Paul
Re: [Qemu-devel] Bug report
- Qemu initializes all its memory to 0. Real hardware doesn't seem to do that. This means that usage of uninitialized memory is very hard to debug (because 0 is often a good value, while [random] is not, so the problem can only be seen on real hardware, which makes it hard to debug). Definitely not a bug. I'm fairly sure I've seen real machines that zero memory on reset. If you want random data if should be fairly trivial to achieve this in your OS loader. - The timing of the ports are impossibly fast. - The system timer (irq 0) runs on real-time, not on emulated time. Qemu is not cycle accurate, so any notion of emulated time is completely arbitrary. Currently qemu is also fairly non-deterministic. The rate at which it executes instructions may vary greatly. It's not uncommon for the CPU to stall for several ms, and executing the same code sequence multiple times may take vastly different amounts of time This is often true of modern hardware, though generally to a lesser extent. There are many things that can stall execution, e.g. frequency scaling, thermal throttling, cache or TLB interactions, DRAM refresh cycles, external bus masters, etc. You have to lock things down really tightly (and be extremely careful what hardware you use) if you want hard-realtime guarantees. Paul
Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and restore vram buffer (revised)
In any case, vl.c's saving arrangements do save the buffer in phys_ram_base - but that isn't what the guest sees in the VGA memory It doesn't matter what the guest physical mappings (if any) are. area. The guest sees the vga memory-mapped IO registers (whose meaning _is_ generally saved by vga.c), plus it can use the VGA memory area and those control registers to access the whole of s-vram_ptr in a bank-switched way. And it is that whole VGA memory buffer which is `displayed' to (eg) vlc clients. If you look closer, you'll find that s-vram_ptr actually points to an offset from phys_ram_base. So the VGA framebuffer is already saved by ram_save. If the xen patches have changed this then you may need your patch. It has no business in mainstream qemu though. Paul
Re: [Qemu-devel] xen / qemu convergence ?
I don't really understand why the vga is handled in this way in qemu but then I'm not an expert on PC graphics hardware. Is it necessary or desirable for the VGA RAM to take up virtual address space in this way, or is there some other reason why VGA RAM in the ordinary vga driver is regarded as a special use of system RAM rather than as a special kind of hardware device ? RAM is RAM. We don't care whether it's nominally owned by the vga controller or the system. If you don't do this then all accesses have to go via horribly slow IO callbacks, which is just silly. I've no idea what you're talking about when you say it's taking up virtual address space. Paul
Re: [Qemu-devel] [PATCH 2/2 v2][UPDATED] Direct IDE I/O
On Monday 17 December 2007, Fabrice Bellard wrote: Laurent Vivier wrote: This patch enhances the -drive ,cache=off mode with IDE drive emulation by removing the buffer used in the IDE emulation. --- block.c | 10 +++ block.h |2 block_int.h |1 cpu-all.h |1 exec.c | 19 ++ hw/ide.c| 176 +--- vl.c |1 7 files changed, 204 insertions(+), 6 deletions(-) [...] Unfortunately it is more complicated to write to the CPU memory. In particular, specific action should be done when translated code is present. A consistent API must include something like cpu_page_lock() / unlock(). Look at cpu_physical_memory_rw() to see the various issues which must be handled. Moreover, it would be better to add bus specific APIs (at least for PCI), but I can accept a CPU memory API for now. In general it may also be unsafe to do async writes directly to guest memory because you break the atomicity of loads/stores. Paul
Re: [Qemu-devel][Patch] Windows build broken
Typically, gcc provides a built-in function ffs Actually, not it doesn't. As with many other standard functions, gcc will sometimes optimize it, maybe expanding to inline code. However there's always the possibility of falling back to the standard C library implementation. Paul
Re: [Qemu-devel] qemu vl.c
On Sunday 16 December 2007, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/12/16 13:17:13 Modified files: . : vl.c Log message: Redundant timer rearm optimisation by Anders Melchiorsen. I think this is incorrect. When a timer is modified, we need to rearm the host timer immediately. We can not wait for the old timer to fire, or for execution to fall back to the main_loop_wait. Consider the case where the guest adds a timer interrupt and immediately enters a tight loop - Quite a common operation when calibrating a software delay loop. The timer won't be rearmed until some other event occurs. It the system is otherwise quiescent and you're not using SDL output it may never occur. Paul
Re: [Qemu-devel] qemu vl.c
On Sunday 16 December 2007, Anders wrote: Paul Brook wrote: Redundant timer rearm optimisation by Anders Melchiorsen. I think this is incorrect. When a timer is modified, we need to rearm the host timer immediately. We can not wait for the old timer to fire, or for execution to fall back to the main_loop_wait. Consider the case where the guest adds a timer interrupt and immediately enters a tight loop - Quite a common operation when calibrating a software delay loop. The timer won't be rearmed until some other event occurs. It the system is otherwise quiescent and you're not using SDL output it may never occur. Hi Paul, I am certainly open to it not being correct, but currently I fail to see how it changes the scenario that you mention. The rearming is moved away from qemu_run_timers(), not qemu_mod_timer(). Can you elaborate? It's possible that this code has always been broken. You changes make it much more obviously so. There was a previous patch to remove the rearming when timers are modified, http://cvs.savannah.gnu.org/viewvc/qemu/vl.c?root=qemuview=log#rev1.345 I think this this is unrealted.
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
On Tuesday 11 December 2007, andrzej zaborowski wrote: On 10/12/2007, Balazs Attila-Mihaly (Cd-MaN) [EMAIL PROTECTED] wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap - it is also available from the monitor - added some more constants / defines to avoid repeating portions of the code Would it be possible to implement this as simply another vlan client that does the logging in it's fd_read callback? I think this would be cleaner, we would avoid the special case and an additional condition check in every qemu_send_packet(). That's exactly what I was imagining when I suggested making it a -net option. Paul
Re: [Qemu-devel] [PATCH] arm eabi TLS
On Wednesday 12 December 2007, Thayne Harbaugh wrote: I believe Paul Brook did the original patch for arm eabi TLS. The patch has bounced around for a bit but hasn't been applied. We've been using this patch for a while and have tweaked it to be a bit more correct as far as code organization. Please let me know what else should be improved for this so that it can be applied. Implementing clone(CLONE_VM) is a bad idea. We should only do that after we've fixed everything else that breaks with multiple threads You're also missing some of the ARM kernel helper routines. Paul
Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated
On Monday 10 December 2007, Anthony Liguori wrote: Balazs Attila-Mihaly (Cd-MaN) wrote: Here goes v0.2 for my patch :-) Changes - now the option is a separate command line switch: -net capture,vlan=2,file=test.pcap Is it really necessary/useful to specify this on the command line since it can be controlled from the monitor? By that argument you could remove half the rest of the commandline options (e.g. the USB options). I think it would be good to expose the whole -net functionality via the monitor, rather than have a special hack for -net monitor. Obviously some functionality would only be usable via the commandline (e.g. non-hotplug NICs). Paul
Re: [Qemu-devel] high resolution timer question
I think the throttling should be done at CharDriver level so that all targets and also other devices, like parallel ports (SUNW,bpp anyone?) But the timing is entirely a concept of the hardware devices. It seems like it would be easier to just add a growable buffer, and then setup a timer in each device that reads from the buffer. I don't see why timing is device specific. The mechanisms for setting the speed are device specific, but the throttling should not be. You may need to augment the char driver API to support outgoing throttling. I'd also like to request that this feature be disabled by default. As I've mentined several times before qemu is not cycle accurate, so any attempt to do accurate timing is completely arbitrary. In practice I'd expect any throttling is probably going to have to be fairly coarse grained because the emulated cpu speed is extremely variable/irregular, and you're limited by host timer resolution. Paul
Re: [Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
+x86_cpu_def-vendor1 = cpu_to_le32(*(uint32_t *)val); +x86_cpu_def-vendor2 = cpu_to_le32(*(uint32_t *)(val + 4)); +x86_cpu_def-vendor3 = cpu_to_le32(*(uint32_t *)(val Still not good enough. val might not be aligned. Paul
Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device
virtio makes things a bit trickier though. There's a shared ring queue between the host and guest. The ring queue is lock-less and depends on the ability to atomically increment ring queue indices to be SMP safe. Using a copy-API wouldn't be a problem for QEMU since the host and guest are always running in lock-step. A copy API is actually needed to deal with differing host/guest alignment and endianness. That seems a rather poor design choice, as many architectures don't have an atomic increment instruction. Oh well. Paul
Re: [Qemu-devel] [PATCH 2/2] Real SCSI device passthrough (v3)
On Friday 07 December 2007, Laurent Vivier wrote: - acb-aiocb.aio_nbytes = nb_sectors * 512; + if (nb_sectors 0) + acb-aiocb.aio_nbytes = -nb_sectors; + else + acb-aiocb.aio_nbytes = nb_sectors * 512; Ugly hacks like this need at least a decent comment. Paul
Re: [Qemu-devel] qemu user mode ELF binaries with vma != lma
On Friday 07 December 2007, Alexandre Pereira Nunes wrote: Hi, I'm attempting to use qemu-user-arm in a very weird way: Everything works fine, except that the entry points attempts to copy memory from what it believes to be the rom image and the ram segment. Don't do that then. Just disable your copying routine. Paul
Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device
Actually according to qemu's standard, one should use
cpu_physical_memory_write/ cpu_physical_memory_read functions.
This is true also for reading the ring values.
Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
interfaces. We really don't want that for high speed I/O.
I really don't like doing direct access to guest ram without implementing a
proper API for zero-copy/scatter-gather access. There was a list thread about
this not so long ago.
Paul
Re: [Qemu-devel] [PATCH] Capture traffic to a pcap file
On Wednesday 05 December 2007, Balazs Attila-Mihaly (Cd-MaN) wrote: This patch allows to capture the traffic flowing through a particular vlan in a tcpdump compatible pcap file. The patch is identical to the one created some time back, however it was updated to apply to HEAD. Usage: -net nic,pcap=capture_file.pcap This should be a separate -net option, not part of -net nic. Paul
Re: [Qemu-devel] [PATCH] sparc32 machine specific maximums
If you want to make a 16 CPU, 64 Gb machine, define a QEMU specific machine. There are no real 32 bit sparc systems like that. I believe the Cray CS6400 was a 64-way sparc32 machine with 16Gb ram. Admittedly it's a sun4d variant, not sun4m. I've no idea how much difference (if any) that makes to OS. Paul
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
On Monday 03 December 2007, Markus Hitter wrote: Am 03.12.2007 um 11:30 schrieb Laurent Vivier: But if you think I should remove the buffered case, I can. In doubt, less code is always better. For the unlikely case you broke something badly, there's always the option to take back the patch. BTW, do you think I should enable cache=off by default ? This would be fine for a transition phase, but likely, the cache=on case gets forgotten to be removed later. So, do it now. I think host caching is still useful enough to be enabled by default, and provides a significant performance increase in several cases. - The guest typically has a relatively small quantity of RAM, compared to a modern machine. Allowing the host OS to act as a demand-based L2 cache allows this to be used without having to dedicate excessive quantities of ram to qemu. - I've seen reports that it significantly speeds up the windows installer. - Host cache is persistent between multiple qemu runs. f you're doing anything that requires frequent guest reboots (e.g. kernel debugging) this is going to be a huge win. - You're running a host OS that has limited or no caching (e.g. DOS). I'd hope that the host OS would have cache use heuristics that would help limit cache pollution. Paul
