[Qemu-devel] [PATCH] Capture network traffic
W00t, my first patch got applied :) Thank you.
Here goes version 0.3 of my packet capture patch. I rewritten it to be a custom
VLANClient which implements the capturing part in its fd_read proceudre, rather
than adding additional properties to the VLAN structure. Monitor support is
also present.
Also, could somebody please give me any hints regarding my questions described
here: http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00296.html (Qemu
architectural questions)? Any pointers would be greatly appreciated.
Best regards.
__
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.388
diff -u -r1.388 vl.c
--- vl.c 17 Dec 2007 04:42:28 - 1.388
+++ vl.c 18 Dec 2007 07:30:26 -
@@ -237,6 +237,19 @@
static CPUState *next_cpu;
static int event_pending = 1;
+/* File header which needs to be written at the start of each PCAP file*/
+static const PCAPHeader pcap_file_header = {
+0xa1b2c3d4, /* Magic header - used to determine file endianess */
+2, /* Version major */
+4, /* Version minor */
+0,
+0,
+MAX_CAPTURED_PACKET_SIZE,
+1 /* Ethernet */
+};
+/* Used to return in case a memory allocation fails (because obviously we can't allocate memory then!) */
+static char *pcap_memory_error = Failed to allocate memory;
+
#define TFR(expr) do { if ((expr) != -1) break; } while (errno == EINTR)
/***/
@@ -4669,6 +4682,7 @@
char buf[1024];
int vlan_id, ret;
VLANState *vlan;
+char *error_message;
p = str;
q = device;
@@ -4788,6 +4802,15 @@
}
vlan-nb_host_devs++;
} else
+if (!strcmp(device, capture)) {
+error_message = pcap_add_capture(vlan_id, (char*)get_param_value(buf, sizeof(buf), file, p));
+if (error_message) {
+fprintf(stderr, %s\n, error_message);
+free(error_message);
+return -1;
+}
+ret = 0;
+} else
{
fprintf(stderr, Unknown network device: %s\n, device);
return -1;
@@ -4799,6 +4822,152 @@
return ret;
}
+/* VLAN Packet capture */
+
+static void pcap_receive(void *opaque, const uint8_t *buf, int size) {
+PCAPStateInfo *pcap_state;
+
+pcap_state = (PCAPStateInfo*)opaque;
+
+pcap_state-packet_header.timestamp_sec = time(NULL);
+if (pcap_state-packet_header.timestamp_sec == pcap_state-last_packet_time) {
+if (pcap_state-packet_header.timestamp_usec 100)
+++pcap_state-packet_header.timestamp_usec;
+} else {
+pcap_state-packet_header.timestamp_usec = 0;
+pcap_state-last_packet_time = pcap_state-packet_header.timestamp_sec;
+}
+
+pcap_state-packet_header.orig_len = size;
+pcap_state-packet_header.saved_len = (size MAX_CAPTURED_PACKET_SIZE) ? MAX_CAPTURED_PACKET_SIZE : size;
+write(pcap_state-fh, pcap_state-packet_header, sizeof(PCAPPacketHeader));
+write(pcap_state-fh, buf, pcap_state-packet_header.saved_len);
+}
+
+/* Add capture to a given VLAN. */
+/* Returns NULL on success, the error message in case of an error. */
+/* If an error message is returned, the caller must free it */
+char* pcap_add_capture(int vlan_id, const char *filename)
+{
+VLANState *vlan;
+VLANClientState *vlan_client;
+char *error_message;
+PCAPStateInfo *pcap_state;
+
+if (NULL == filename)
+filename = DEFAULT_CAPTURE_FILENAME;
+
+for(vlan = first_vlan; vlan != NULL; vlan = vlan-next)
+if (vlan_id == vlan-id)
+break;
+if (!vlan) {
+asprintf(error_message, Error locating VLAN %d to attach for capture., vlan_id);
+return error_message;
+}
+
+//check if already capturing
+vlan_client = vlan-first_client;
+while (NULL != vlan_client) {
+if (pcap_receive == vlan_client-fd_read) {
+asprintf(error_message, VLAN %d is already capturing.
+Only one capture per VLAN is possible., vlan_id);
+return error_message;
+}
+vlan_client = vlan_client-next;
+}
+
+//not capturing, try to start / attach it
+pcap_state = qemu_mallocz(sizeof(PCAPStateInfo));
+if (!pcap_state)
+return pcap_memory_error;
+vlan_client = qemu_new_vlan_client(vlan, pcap_receive, NULL, pcap_state);
+if (!vlan_client) {
+free(pcap_state);
+return pcap_memory_error;
+}
+
+pcap_state-fh = open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY, 0644);
+if (pcap_state-fh 0) {
+free(pcap_state);
+free(vlan_client);
+
+asprintf(error_message, Failed to open capture file \%s\: %d\n, filename, errno);
+return error_message;
+}
+
+
Re: [Qemu-devel] [PPC] FPIMM macro and mtfsfi instruction
Hi Jocelyn,
Thanks for the quickly answer, but I got a wrong result again.
The actual version of mtfsfi translate.c:l2048 does not seem update the good
flag.
The programmer environnement manual 32bits gives if Rc = 1 affected : copy of
FX,FEX,VX,OX flags of FPSCR into CR1 of CR. Here, I only see the update of
xer_so in CR.
Could you confirm my opinion ?
Regards,
Claude
/* mtfsfi */
GEN_HANDLER(mtfsfi, 0x3F, 0x06, 0x04, 0x006f0800, PPC_FLOAT)
{
[...]
if (unlikely(Rc(ctx-opcode) != 0)) {
gen_op_load_fpcc();
gen_op_set_Rc0();
}
[...]
}
On Mon, 2007-12-17 at 15:52 +0100, claude vittoria wrote:
Hi everybody,
I think that I get a wrong result with mtfsfi instruction.
I think to get a solution, see below.
Could you confirm my opinion ?
Seems there have been (once again) a confusion between IBM bit notation
(0 is MSB...) and standard one. You're right, FPIMM should be taken
using EXTRACT_HELPER(FPIMM, 12, 4);
Thanks for the report.
translate.c
l344:EXTRACT_HELPER(crbD, 21, 5);
...
l375:EXTRACT_HELPER(FPIMM, 20, 4); ==FPIMM must be (FPIMM, 12, 4) or
crbB 1 for mtfsfi; IMM is bits[16-19] of the instruction in PPC
programming environnement 32bit (p8-135). IMM is not one bit before crbD.
...
[...]
--
Jocelyn Mayer [EMAIL PROTECTED]
Re: [Qemu-devel] qemu-forum.ipi.fi down?
Robert Nestor wrote: It seems qemu-forum.ipi.fi is down. Is there an alternate place one can obtain source snapshots or browse the user forums? It should be back online once again (and it has been almost all the time). The reason you haven't been able to reach it was my mistake. When the server moved, ip-addr wasn't updated to dns. I just edited my /etc/hosts to include line 80.64.9.36 qemu-forum.ipi.fi and forget the issue. dns-record is now updated Pablo
[Qemu-devel] PATCH: block-vvfat.c: fix number_of_entries for filename of length [13]
Hi,
when the length of a LFN is a multiple of 13 (ie 26 bytes), no
padding (0x or 0x) is added.
[ Linux vfat fs follows this policy: in namei.c:xlat_to_uni
*longlen = *outlen;
if (*outlen % 13) {
*op++ = 0;
*op++ = 0;
*outlen += 1;
if (*outlen % 13) {
fill = 13 - (*outlen % 13);
for (i = 0; i fill; i++) {
*op++ = 0xff;
*op++ = 0xff;
}
*outlen += fill;
}
}
]
This patch fixes this issue.
Tristan.
qemu.diff
Description: Binary data
Re: [Qemu-devel] [PATCH 2/2 v2][UPDATED] Direct IDE I/O
Le mardi 18 décembre 2007 à 00:03 +, Paul Brook a écrit : 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. Thank you for your comments. I had some doubts on this patch too. I will not resend it. I will resend only the first one corrected with comments from Fabrice (malloc()/free()). Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] xen / qemu convergence ?
andrzej zaborowski writes (Re: [Qemu-devel] xen / qemu convergence ?): There's currently no way in qemu to map a chunk of host memory to guest memory 1:1 if it's not in phys_ram_base, so all video adapters in qemu do that. Mapped memory that's part of phys_ram_base also gets dirty pages tracking for free. A way to map any arbitrary host address to guest RAM would be useful for cases like the vmware-svga where no dirty tracking is needed if the SDL framebuffer is made directly accessible to guest. Right. The Xen versions of the vga emulators don't map the vga ram into the guest's address space wholesale. Accesses to the vga ram all use the I/O callbacks through the traditional vga memory window. To improve the performance there's (in as-yet-unreleased versions of Xen) a Xen-specific shadow memory arrangement which tracks the guest's writes. (I haven't looked into that in detail.) (And of course in the Xen case, there is no host memory corresponding to ordinary guest ram.) Cirrus and stdvga code in qemu appears to do exactly the same thing, I'm not sure why there is a difference between the two in Xen. It's just a mistake: the Cirrus emulator had been changed to save its private memory, but the corresponding required change to stdvga had been overlooked. Paul Brook writes (Re: [Qemu-devel] xen / qemu convergence ?): 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 see, yes. I've no idea what you're talking about when you say it's taking up virtual address space. I meant that it allocates part of the space indexed by ram_addr_t but on rereading the code I think that's not visible to the guest and is just used for qemu's own bookkeeping so I was mistaken. Thanks, Ian.
[Qemu-devel] [PATCH] fix cmpxchg8b translation
The cmpxchg8b opcode is only valid if the nnn bits in the mod/rm byte are 001, otherwise an #UD should be generated. The attached patch fixes this. Bernhard Kauer Index: target-i386/translate.c --- target-i386/translate.c 8 Nov 2007 14:25:03 - 1.74 +++ target-i386/translate.c 18 Dec 2007 12:14:08 - @@ -3887,7 +3887,7 @@ case 0x1c7: /* cmpxchg8b */ modrm = ldub_code(s-pc++); mod = (modrm 6) 3; -if (mod == 3) +if ((mod == 3) || ((modrm 0x38) != 0x8)) goto illegal_op; gen_jmp_im(pc_start - s-cs_base); if (s-cc_op != CC_OP_DYNAMIC)
[Qemu-devel] Re: [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync icache for morearchitectures
Hollis Blanchard wrote: On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote: Hollis Blanchard wrote: A comment to explain why the icache needs flushing only in the KVM case would be useful. Other than that I'm fine with it. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] AFAIK Plain qemu does not directly execute guest code on the processor, so the icache is not an issue for it. Qemu itself has the flush_icache_range function only as helper for the dynamic code generation. But we may now write executable guest code with our intercepted mmio handling that is directly executed when switching back to the guest context, therefore we need that invalidation in the kvm case. For the case that I'm overlooking something in plain qemu, so that it might need it too I add qemu-devel@nongnu.org for comments from there, but currently I think to have it in #ifdef USE_KVM is the right way. P.S. Hollis did you mean you would like to see a comment in the code where that call takes place? Yes! Hopefully much shorter than this email... :-P comment added, rebased and resent together with a updated mmio callback simplification patch - I hope I didn't overlook a response to the mmio callback thread again this time ;-) -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 [EMAIL PROTECTED] [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
[Qemu-devel] [PATCH] SVM enabled processor should provide cpuid Fn8000_000A
An SVM enabled processor should provide the CPUID extended leaf Fn8000_000A
(see AMD documentation #25481). The attached patch add this feature.
Bernhard Kauer
Index: target-i386/helper.c
===
RCS file: /sources/qemu/qemu/target-i386/helper.c,v
retrieving revision 1.97
diff -u -r1.97 helper.c
--- target-i386/helper.c 9 Dec 2007 23:39:22 - 1.97
+++ target-i386/helper.c 18 Dec 2007 12:40:06 -
@@ -1751,6 +1819,12 @@
ECX = 0;
EDX = 0;
break;
+case 0x800A:
+EAX = 0x0001;
+EBX = 0;
+ECX = 0;
+EDX = 0;
+ break;
default:
/* reserved values: zero */
EAX = 0;
Index: target-i386/helper2.c
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.60
diff -u -r1.60 helper2.c
--- target-i386/helper2.c 9 Dec 2007 02:43:19 - 1.60
+++ target-i386/helper2.c 18 Dec 2007 12:40:06 -
@@ -150,7 +150,7 @@
.ext2_features = (PPRO_FEATURES 0x0183F3FF) |
CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
.ext3_features = CPUID_EXT3_SVM,
-.xlevel = 0x8008,
+.xlevel = 0x800A,
},
#endif
{
Re: [Qemu-devel] qemu-forum.ipi.fi down?
Pablo Virolainen [EMAIL PROTECTED] wrote: Robert Nestor wrote: It seems qemu-forum.ipi.fi is down. Is there an alternate place one can obtain source snapshots or browse the user forums? It should be back online once again (and it has been almost all the time). The reason you haven't been able to reach it was my mistake. When the server moved, ip-addr wasn't updated to dns. I just edited my /etc/hosts to include line 80.64.9.36 qemu-forum.ipi.fi and forget the issue. dns-record is now updated Looks good from this side of the atlantic. Thank you. Ben
[Qemu-devel] [PATCH v3] Add cache parameter to -drive
This patch adds a new parameter to -drive
Using cache=off with -drive will open the disk image file using
O_DIRECT.
By default, cache is set to on to keep original behavior of qemu.
v3 modify hw/sd.c to allocate buffer on init and not on each
blk_read()/blk_write()
and add cache= in qemu-doc.texi.
example:
-drive file=my_disk.qcow2,cache=off
---
block-raw-posix.c |8 +++
block-raw-win32.c |4 +++
block.c |2 -
block.h |1
hw/fdc.c |7 +-
hw/ide.c | 18 +
hw/scsi-disk.c|3 +-
hw/sd.c | 56 ++
osdep.c | 20 +++
osdep.h |1
qemu-doc.texi |2 +
vl.c | 28 +++
12 files changed, 110 insertions(+), 40 deletions(-)
Index: qemu/block.c
===
--- qemu.orig/block.c 2007-12-18 10:58:14.0 +0100
+++ qemu/block.c2007-12-18 11:01:01.0 +0100
@@ -380,7 +380,7 @@ int bdrv_open2(BlockDriverState *bs, con
/* Note: for compatibility, we open disk image files as RDWR, and
RDONLY as fallback */
if (!(flags BDRV_O_FILE))
-open_flags = BDRV_O_RDWR;
+open_flags = BDRV_O_RDWR | (flags BDRV_O_DIRECT);
else
open_flags = flags ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
ret = drv-bdrv_open(bs, filename, open_flags);
Index: qemu/block.h
===
--- qemu.orig/block.h 2007-12-18 10:58:14.0 +0100
+++ qemu/block.h2007-12-18 11:01:01.0 +0100
@@ -44,6 +44,7 @@ typedef struct QEMUSnapshotInfo {
use a disk image format on top of
it (default for
bdrv_file_open()) */
+#define BDRV_O_DIRECT 0x0020
#ifndef QEMU_IMG
void bdrv_info(void);
Index: qemu/hw/fdc.c
===
--- qemu.orig/hw/fdc.c 2007-12-18 10:58:14.0 +0100
+++ qemu/hw/fdc.c 2007-12-18 11:01:01.0 +0100
@@ -382,7 +382,7 @@ struct fdctrl_t {
uint8_t cur_drv;
uint8_t bootsel;
/* Command FIFO */
-uint8_t fifo[FD_SECTOR_LEN];
+uint8_t *fifo;
uint32_t data_pos;
uint32_t data_len;
uint8_t data_state;
@@ -598,6 +598,11 @@ fdctrl_t *fdctrl_init (qemu_irq irq, int
fdctrl = qemu_mallocz(sizeof(fdctrl_t));
if (!fdctrl)
return NULL;
+fdctrl-fifo = qemu_memalign(512, FD_SECTOR_LEN);
+if (fdctrl-fifo == NULL) {
+qemu_free(fdctrl);
+return NULL;
+}
fdctrl-result_timer = qemu_new_timer(vm_clock,
fdctrl_result_timer, fdctrl);
Index: qemu/hw/ide.c
===
--- qemu.orig/hw/ide.c 2007-12-18 10:58:14.0 +0100
+++ qemu/hw/ide.c 2007-12-18 11:01:01.0 +0100
@@ -365,7 +365,7 @@ typedef struct IDEState {
EndTransferFunc *end_transfer_func;
uint8_t *data_ptr;
uint8_t *data_end;
-uint8_t io_buffer[MAX_MULT_SECTORS*512 + 4];
+uint8_t *io_buffer;
QEMUTimer *sector_write_timer; /* only used for win2k install hack */
uint32_t irq_count; /* counts IRQs when using win2k install hack */
/* CF-ATA extended error */
@@ -2377,17 +2377,24 @@ struct partition {
static int guess_disk_lchs(IDEState *s,
int *pcylinders, int *pheads, int *psectors)
{
-uint8_t buf[512];
+uint8_t *buf;
int ret, i, heads, sectors, cylinders;
struct partition *p;
uint32_t nr_sects;
+buf = qemu_memalign(512, 512);
+if (buf == NULL)
+return -1;
ret = bdrv_read(s-bs, 0, buf, 1);
-if (ret 0)
+if (ret 0) {
+qemu_free(buf);
return -1;
+}
/* test msdos magic */
-if (buf[510] != 0x55 || buf[511] != 0xaa)
+if (buf[510] != 0x55 || buf[511] != 0xaa) {
+qemu_free(buf);
return -1;
+}
for(i = 0; i 4; i++) {
p = ((struct partition *)(buf + 0x1be)) + i;
nr_sects = le32_to_cpu(p-nr_sects);
@@ -2408,9 +2415,11 @@ static int guess_disk_lchs(IDEState *s,
printf(guessed geometry: LCHS=%d %d %d\n,
cylinders, heads, sectors);
#endif
+qemu_free(buf);
return 0;
}
}
+qemu_free(buf);
return -1;
}
@@ -2425,6 +2434,7 @@ static void ide_init2(IDEState *ide_stat
for(i = 0; i 2; i++) {
s = ide_state + i;
+s-io_buffer = qemu_memalign(512, MAX_MULT_SECTORS*512 + 4);
if (i == 0)
s-bs = hd0;
else
Index: qemu/hw/scsi-disk.c
===
--- qemu.orig/hw/scsi-disk.c2007-12-18 10:58:14.0 +0100
+++
Re: [PATCH] Re: [Qemu-devel] QEMU keyboard issue with Gujin-2.2
Etienne Lorrain wrote:
Hello,
I have digged further my problem of keyboard problem when the mouse is
activated
using qemu (i.e. dummy char present in the keyboard buffer), and can say that
this patch solves completely the problem:
$ diff -urp qemu-0.9.0-init qemu-0.9.0
diff -urp qemu-0.9.0-init/hw/pckbd.c qemu-0.9.0/hw/pckbd.c
--- qemu-0.9.0-init/hw/pckbd.c 2007-02-05 23:01:54.0 +
+++ qemu-0.9.0/hw/pckbd.c 2007-10-16 20:32:40.0 +0100
@@ -202,7 +202,7 @@ static void kbd_write_command(void *opaq
#endif
switch(val) {
case KBD_CCMD_READ_MODE:
-kbd_queue(s, s-mode, 0);
+kbd_queue(s, s-mode, 1);
break;
case KBD_CCMD_WRITE_MODE:
case KBD_CCMD_WRITE_OBUF:
This patch (which is present in qemu-cvs) kills the mouse in suse linux 9.1.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 2/2 v2][UPDATED] Direct IDE I/O
Paul Brook wrote: 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. But that is true on real hardware as well, I think. The guest cannot expect atomicity if it dmas into the memory it is accessing. Also, it would be a rare guest that accesses memory while dma is active. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] qemu vl.c
andrzej zaborowski wrote: Attached is a small patch to do exactly this. The rearming in main_loop_wait() can also be made conditional but I don't think there would be a real gain. Testing with KVM will be appreciated. Regards Time in grub is completely off, Linux calibrate_delay() complains, 'sleep 1' doesn't return, but FC6 x86-64 boots. (this is with your patch on top of the re-applied patch I reverted earlier). -- error compiling committee.c: too many arguments to function
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
[Qemu-devel] Re: multicast and the eepro100 driver
Stefan Weil [EMAIL PROTECTED] writes: eepro100.c is my work, so maybe I can help you. First of all: there exists a newer version of eepro100.c which fixes some bugs of the CVS version and largely improves support for big endian hosts and targets. Get it from http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=filerev=0sc=0 I am still working on this new version, because support for big endian hosts is still untested. If you define macro DEBUG_EEPRO100 in eepro100.c, you will get debugging messages which show the frames sent and received. Multicast frames should be received, but I never tested this, so maybe there is a bug, and I know that I did not implement all functions needed for multicast. Hello, I just tried your new version of eepro100.c and can confirm that multicast reception does work with this version. Found one bug (which does not prevent it from working): The length of the multicast list seems have a byte/number confusion. I get: EE100 set_multicast_list multicast list, 0 entries EE100 set_multicast_list multicast list, 0 entries EE100 set_multicast_list multicast list, 6 entries EE100 set_multicast_list multicast entry 01 00 5e 00 00 01 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast list, 12 entries EE100 set_multicast_list multicast entry 01 00 5e 00 00 01 EE100 set_multicast_list multicast entry 01 00 5e 00 00 06 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast list, 18 entries EE100 set_multicast_list multicast entry 01 00 5e 00 00 01 EE100 set_multicast_list multicast entry 01 00 5e 00 00 05 EE100 set_multicast_list multicast entry 01 00 5e 00 00 06 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 EE100 set_multicast_list multicast entry 00 00 00 00 00 00 This patch fixes this: --- /home/bjorn/tmp/eepro100.c 2007-12-18 14:52:48.0 +0100 +++ /usr/local/src/qemu-0.9.0+20070816/hw/eepro100.c2007-12-18 15:37:40.0 +0100 @@ -905,7 +903,7 @@ TRACE(OTHER, logout(configuration: %s\n, nic_dump(s-configuration[0], 16))); break; case CmdMulticastList: -set_multicast_list(s, s-tx.tbd_array_addr BITS(13, 0)); +set_multicast_list(s, (s-tx.tbd_array_addr BITS(13, 0)) / 6); break; case CmdTx: tx_command(s); Thanks for your work on this! Bjørn -- How can you say that old people are inherently superior to unborn people
Re: [Qemu-devel] [Patch 1/2] switch support v2
Laurent Vivier wrote: Le lundi 17 décembre 2007 à 09:40 -1000, Armin a écrit : Laurent Vivier wrote: Hi, if you just want to configure which bank to use with pflash, perhaps you can do something like: qemu -drive if=pflash,unit=0 to use the first bank, and qemu -drive if=pflash,unit=1 to use the second bank. Yes, that might work for the flash case but does not address other switches settings. In my case, the Mainstone has two rotary switches that define which frequency to boot up in. But I don't think qemu able to emulate frequency ? So it should be useless. I am sure that is true and my example might be very week in the above case. I think if a board we are trying to emulate has boot time configurations governed by jumpers or switches for enabling or disabling certain hardware devices , then having a runtime solution seems more appropriate. It seems silly to have to rebuild to qemu if one wants to switch device A to be uart #2 from an IrdA device when using -switches 1=on could do the same. regards, Armin
Re: [Qemu-devel] [Patch 1/2] switch support v2
Le mardi 18 décembre 2007 à 08:40 -1000, Armin a écrit : Laurent Vivier wrote: Le lundi 17 décembre 2007 à 09:40 -1000, Armin a écrit : Laurent Vivier wrote: Hi, if you just want to configure which bank to use with pflash, perhaps you can do something like: qemu -drive if=pflash,unit=0 to use the first bank, and qemu -drive if=pflash,unit=1 to use the second bank. Yes, that might work for the flash case but does not address other switches settings. In my case, the Mainstone has two rotary switches that define which frequency to boot up in. But I don't think qemu able to emulate frequency ? So it should be useless. I am sure that is true and my example might be very week in the above case. I think if a board we are trying to emulate has boot time configurations governed by jumpers or switches for enabling or disabling certain hardware devices , then having a runtime solution seems more appropriate. It seems silly to have to rebuild to qemu if one wants to switch device A to be uart #2 from an IrdA device when using -switches 1=on could do the same. Well, my opinion is not really important here, but I think -switches 1=on is too low level... using the meaning could be more user-friendly, something like -deviceA uart2. Regards, Laurent -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] [Patch 1/2] switch support v2
Laurent Vivier wrote: Le mardi 18 décembre 2007 à 08:40 -1000, Armin a écrit : Laurent Vivier wrote: Le lundi 17 décembre 2007 à 09:40 -1000, Armin a écrit : Laurent Vivier wrote: Hi, if you just want to configure which bank to use with pflash, perhaps you can do something like: qemu -drive if=pflash,unit=0 to use the first bank, and qemu -drive if=pflash,unit=1 to use the second bank. Yes, that might work for the flash case but does not address other switches settings. In my case, the Mainstone has two rotary switches that define which frequency to boot up in. But I don't think qemu able to emulate frequency ? So it should be useless. I am sure that is true and my example might be very week in the above case. I think if a board we are trying to emulate has boot time configurations governed by jumpers or switches for enabling or disabling certain hardware devices , then having a runtime solution seems more appropriate. It seems silly to have to rebuild to qemu if one wants to switch device A to be uart #2 from an IrdA device when using -switches 1=on could do the same. Well, my opinion is not really important here, but I think -switches 1=on is too low level... using the meaning could be more user-friendly, something like -deviceA uart2. Sure your opinion matters, I can get an idea stuck in my little brain and not see the trees in the forest. -device, that got me thinking... Lets say I have a mips port that has one PCI slot on it. I could get a listing of PCI cards supported by this port and select one for use by that PCI slot. This could be extended for local bus (i.e switches jumpers) , PCMCIA and SD slots. Regards, Armin
Re: [Qemu-devel] qemu vl.c
Avi Kivity wrote:
Time in grub is completely off, Linux calibrate_delay() complains,
'sleep 1' doesn't return, but FC6 x86-64 boots.
(this is with your patch on top of the re-applied patch I reverted earlier).
Now I have updated my kvm checkout, and I immediately got trouble
booting the guest. So it seems something has changed since I made my
first patch.
What I could find is that the env variable in host_alarm_handler() is
always NULL now? Then the expiry flag has to be set outside of that
conditional, or alarms will never expire.
Also, an optimization of the new rearming in qemu_mod_timer() is that it
should not be done if we are currently running the expired timers. It
will be done after all the running is over, anyway.
Attached is a reworked patch with these changes, it should apply against
your kvm git master (i.e. do not re-apply the reverted one).
Anders.
diff --git a/qemu/vl.c b/qemu/vl.c
index 28c5df4..000df7e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -850,6 +850,7 @@ struct qemu_alarm_timer {
};
#define ALARM_FLAG_DYNTICKS 0x1
+#define ALARM_FLAG_EXPIRED 0x2
static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
{
@@ -1061,6 +1062,12 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
ts-expire_time = expire_time;
ts-next = *pt;
*pt = ts;
+
+/* Rearm if necessary */
+if ((alarm_timer-flags ALARM_FLAG_EXPIRED) == 0
+ pt == active_timers[ts-clock-type]) {
+qemu_rearm_alarm_timer(alarm_timer);
+}
}
int qemu_timer_pending(QEMUTimer *ts)
@@ -1095,7 +1102,6 @@ static void qemu_run_timers(QEMUTimer **ptimer_head, int64_t current_time)
/* run the callback (the timer list can be modified) */
ts-cb(ts-opaque);
}
-qemu_rearm_alarm_timer(alarm_timer);
}
int64_t qemu_get_clock(QEMUClock *clock)
@@ -1215,6 +1221,8 @@ static void host_alarm_handler(int host_signum)
#endif
CPUState *env = next_cpu;
+alarm_timer-flags |= ALARM_FLAG_EXPIRED;
+
if (env) {
/* stop the currently executing cpu because a timer occured */
cpu_interrupt(env, CPU_INTERRUPT_EXIT);
@@ -7726,6 +7734,11 @@ void main_loop_wait(int timeout)
qemu_run_timers(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock));
+if (alarm_timer-flags ALARM_FLAG_EXPIRED) {
+alarm_timer-flags = ~(ALARM_FLAG_EXPIRED);
+qemu_rearm_alarm_timer(alarm_timer);
+}
+
/* Check bottom-halves last in case any of the earlier events triggered
them. */
qemu_bh_poll();
Re: [Qemu-devel] Bug report
On Tue, Dec 18, 2007 at 04:52:47PM +, Paul Brook wrote: - 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. Not a bug, indeed, but a feature request. :-) If you want random data if should be fairly trivial to achieve this in your OS loader. Yes, once I found out that this was about using uninitialized memory it was easy to trigger. But coming to that conclusion took a long time, because testing on real hardware requires rebooting and such, and it's not so easy to get dumps of processor registers. I've streamlined the process quite a bit, but debugging inside qemu is still much easier than on a real machine. Therefore anything which makes code run when it shouldn't is worth making stricter IMO, if only through a commandline option (--os-test, or something, to switch on all such options together). - The timing of the ports are impossibly fast. This is also a thing which makes kernel debugging harder. It's fine if the timing isn't correct as far as I'm concerned. But if it never reports the ports as busy at all, important parts of kernel code are never executed, and thus never tested within qemu. - 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 I understand, and I don't have a problem with that. 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. The cool thing about an emulator is that in theory it would be possible to have a truely reproducible setup. So I can send you an image file plus a qemu command line, and you can reproduce whatever I want you to see (usually a kernel crash, I suppose). On real hardware it is very well possible that this approach doesn't work: the kernel may behave completely different on your system. If qemu also behaves different on your system than on mine, that's not a bug, but it is a missed opportunity IMO. :-) Of course if it's a lot of work to implement it, I can understand that other things have more priority. But I hope to convince you that it would be a useful feature. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: [Qemu-devel] An architectural question
Hi... First of all I want to apologize for this mail and hope that I won't wast to much of your valuable time hacking on Qemu ;-). My goal is to implement a tracing system in Qemu, which would suspend the emulation at certain points (determined by linear addresses), dump some information from the memory and resume the execution. Sounds like you are in the same path like Argos (http://www.few.vu.nl/argos/). Have you give it a check? My first attempt was to hijack the breakpoint system, by doing the following: I've placed a breakpoint at the address of the instruction I wanted to trace and inside of the main_loop function when the EXCP_DEBUG exception occurred I performed the logging after which I called vm_start to resume the operation. However the performance was abyssal... yeah, I can imagine that... :) even simply dumping generated host opcode will make qemu run slower... My next idea would be to replace the opcode generated for the debug point with a procedure call (which would, instead of stopping the emulation, perform the logging and let the emulation go on its way). I've implemented a prototype for this by placing the address of the callback procedure inside of the CPUState structure (given that this structure is accessible to the code fragments), however it segfaults. How do you implement it? as qemu _op_xxx function? have you made it as helper? My questions would be: - What would be the most optimal way to implement this? (Something that would allow the OS to run at a usable speed inside of the emulated machine...) have you tested simply by hooking gdb into qemu's gdb monitor and watch certain memory address (range)? Regarding your kqemu related questionsI am still investigating the source code since long time ago. I got impression that it is doing somekind of paravirtualization where guest is given separate process address space. Every memory access is trapped by kqemu that acts as hypervisor (think of Xen) and kqemu build shadow page table so subsequent access to the same address can be done faster by looking up to this table. So if you create hook there, i think the code must be put in...ehm..how do I say it technically... trampolin pages? it's a page that mapped on both address space (guest and qemu). Whenever the hook is hit, you switch back to qemu's original address space and run anything you need to do. Then switch back to guest address space and continue the virtualized guest. For complete understanding, read kqemu-tech.html included in kqemu tarball. Perhaps you can understand it way better than me. I'm still learning about qemu internals too... regards, Mulyadi.
Re: [Qemu-devel] qemu-forum.ipi.fi down?
Hi.. Just personal question, could you bring back the daily CVS snapshot tarball which was usually posted at front page of Qemu forum? regards, Mulyadi.
