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
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 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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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 whole point in breaking non-x86 hosts!
In the long term, yes
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
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 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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 command-line parameter in.
The point I was trying to make
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
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
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
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
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
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
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
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
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
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
-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
+#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
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
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
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
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
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
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
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
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
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
the next step would be to emulate LSI SCSI chips, eh?
Qemu already does.
Paul
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
+/* 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 /*
-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
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
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
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_
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.
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
... 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
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
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
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
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.
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
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
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.
601 - 700 of 1522 matches
Mail list logo
