[Qemu-devel] Re: SEGV with vnc-access
ZIGLIO, Frediano, VF-IT wrote: I found this bug. It's a kvm bug but is related to qemu code. http://sourceforge.net/tracker/index.php?func=detailaid=1621949group_i d=180599atid=893831 It's been fixed in CVS. KVM is based on 0.8.2. Regards, Anthony Liguori bye Frediano ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Create the VMDK snapshot from the QEMUmonitor.
Igor Lvovsky wrote:
Hi Anthony,
I wrote the patch before Fabrice introduced his solution and I didn't look at it before I sent my patch (my mistake).
But you are right; the new snapshot infrastructure can be useful.
I'll modify my code for new approach and I hope Fabrice will accept it.
Excellent.
As for CID, I think that snapshot tag it's something else.
The CID in VMDK is value updated on the first write every time the virtual disk
is opened.
I see.
By the way, I have a question:
I want to use the standard pread()/pwrite() functions instead of
pair:
lseek()
read() / write()
Why do you want to use p{read,write}()? If you are concerned about
performance, you can simply cache the current file offset and only call
lseek() conditionally.
I know that this may do some problem for Windows implementation,
but I can use some kind of define for Windows case.
A question is if it's acceptable.
Normally, guards for Windows specific stuff is okay but if there isn't a
compelling reason to write non-portable code than I'd at least always be
in favor of writing the portable version :-)
Regards,
Anthony Liguori
Regards,
Igor Lvovsky
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Liguori
Sent: Tuesday, December 26, 2006 7:25 PM
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Create the VMDK snapshot from the QEMUmonitor.
Hi Igor,
Out of curiousity, why didn't you use the new snapshot infrastructure
that Fabrice introduced in CVS? Shouldn't the CID just map directly to
a snapshot tag?
Regards,
Anthony Liguori
Igor Lvovsky wrote:
Hi,
This patch completes the previous one and allows the snapshot (VMDK
style) creation from the QEMU monitor (Ctrl+Alt+2).
To clarify, the previous patch implements the snapshot capabilities
according to the Virtual Disk Format 1.0 document.
http://lists.gnu.org/archive/html/qemu-devel/2006-12/msg00311.html
Implemented features:
1. Create snapshot.
2. CID concept to prevent snapshots chain inconsistency.
3. Snapshots read/write capabilities.
The whole chain (base image and snapshots) created by QEMU can be
loaded from the VMware workstation and vice versa.
Igor Lvovsky.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] multiple tun/tap instances no longer working
I recently built cvs, and found that I can no longer have multiple instances of qemu using tun/tap. the invocation of qemu includes, for each instance: -net nic -net tap,script=/etc/qemu-ifup /etc/qemu-ifup: #!/bin/sh sudo /sbin/ifconfig $1 192.168.2.196 sudo brctl addif br0 $1 strace of qemu-system-x86_64: ... open(/dev/net/tun, O_RDWR)= 3 ioctl(3, TUNSETIFF, 0x7fffca661bf0) = -1 EBUSY (Device or resource busy) write(2, warning: could not configure /de..., 72warning: could not configure /dev/net/tun: no virtual network emulation ) = 72 close(3)= 0 write(2, Could not initialize device \'tap..., 34Could not initialize device 'tap' ) = 34 exit_group(1) = ? Process 8206 detached The only thing that has changed is building qemu from cvs yesterday. Prior to that, I had been using cvs from a few weeks ago. I'm not too familiar with qemu source, but I will start looking at some of the commits from the past few weeks for anything. Any ideas? Thanks. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] multiple tun/tap instances no longer working
in vl.c, it looks like tap_open is called with an uninitialized ifname - instead of ifname[0] == '\0', or a valid ifname, it is a bunch of gibberish - in my case, I'm not all that great with gdbg yet, so it might take me a while to figure out where the bad call to tap_open is coming from... On Tuesday 09 January 2007 10:57, Rick Vernam wrote: I recently built cvs, and found that I can no longer have multiple instances of qemu using tun/tap. the invocation of qemu includes, for each instance: -net nic -net tap,script=/etc/qemu-ifup /etc/qemu-ifup: #!/bin/sh sudo /sbin/ifconfig $1 192.168.2.196 sudo brctl addif br0 $1 strace of qemu-system-x86_64: ... open(/dev/net/tun, O_RDWR)= 3 ioctl(3, TUNSETIFF, 0x7fffca661bf0) = -1 EBUSY (Device or resource busy) write(2, warning: could not configure /de..., 72warning: could not configure /dev/net/tun: no virtual network emulation ) = 72 close(3)= 0 write(2, Could not initialize device \'tap..., 34Could not initialize device 'tap' ) = 34 exit_group(1) = ? Process 8206 detached The only thing that has changed is building qemu from cvs yesterday. Prior to that, I had been using cvs from a few weeks ago. I'm not too familiar with qemu source, but I will start looking at some of the commits from the past few weeks for anything. Any ideas? Thanks. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Change the 82371SB PCI-to-ISA bridge into a82371EB
Aurelien Jarno [EMAIL PROTECTED] wrote: This patch changes the 82371SB PCI-to-ISA bridge into a 82371EB. Note that the ACPI controller implemented in QEMU is already a 82371EB. Shouldn't we also change all piix3 names to piix4 ? [qemu]$ find . -type f | xargs grep piix3 | wc -l 18 -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] multiple tun/tap instances no longer working
I'm not too familiar with diff, so if the attached patch is no good, please do
let me know how to correct it.
On Tuesday 09 January 2007 11:57, Rick Vernam wrote:
in vl.c, it looks like tap_open is called with an uninitialized ifname -
instead of ifname[0] == '\0', or a valid ifname, it is a bunch of gibberish
- in my
case,
I'm not all that great with gdbg yet, so it might take me a while to figure
out where the bad call to tap_open is coming from...
On Tuesday 09 January 2007 10:57, Rick Vernam wrote:
I recently built cvs, and found that I can no longer have multiple
instances of qemu using tun/tap.
the invocation of qemu includes, for each instance:
-net nic -net tap,script=/etc/qemu-ifup
/etc/qemu-ifup:
#!/bin/sh
sudo /sbin/ifconfig $1 192.168.2.196
sudo brctl addif br0 $1
strace of qemu-system-x86_64:
...
open(/dev/net/tun, O_RDWR)= 3
ioctl(3, TUNSETIFF, 0x7fffca661bf0) = -1 EBUSY (Device or resource
busy) write(2, warning: could not configure /de..., 72warning: could
not configure /dev/net/tun: no virtual network emulation
) = 72
close(3)= 0
write(2, Could not initialize device \'tap..., 34Could not initialize
device 'tap'
) = 34
exit_group(1) = ?
Process 8206 detached
The only thing that has changed is building qemu from cvs yesterday.
Prior to that, I had been using cvs from a few weeks ago.
I'm not too familiar with qemu source, but I will start looking at some
of the commits from the past few weeks for anything.
Any ideas?
Thanks.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--- qemu/vl.c 2007-01-07 16:04:40.0 -0600
+++ vl.c 2007-01-09 12:16:09.0 -0600
@@ -3885,9 +3885,11 @@
ret = -1;
if (net_tap_fd_init(vlan, fd))
ret = 0;
} else {
-get_param_value(ifname, sizeof(ifname), ifname, p);
+if (get_param_value(ifname, sizeof(ifname), ifname, p) == 0) {
+ ifname[0]='\0';
+}
if (get_param_value(setup_script, sizeof(setup_script), script, p) == 0) {
pstrcpy(setup_script, sizeof(setup_script), DEFAULT_NETWORK_SCRIPT);
}
ret = net_tap_init(vlan, ifname, setup_script);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] weird slirp problems (dns lookups stopped working, and maybe more)
Hi!
I'm not sure why I didn't notice signs of this earlier (using the
Dec 25 snapshot, I'm on FreeBSD), maybe I really only talked to the host
(10.0.2.2) from inside guests. Anyway, after I first saw it yesterday
night, today I sniffed on the external interface and saw dns requests
of a `host google.com' going out to 224.0.0.251, port 5353, instead
of the dns in resolv.conf. Hmm? And when I patched slirp like this:
Index: qemu/slirp/slirp.c
@@ -130,6 +130,7 @@
void slirp_init(void)
{
//debug_init(/tmp/slirp.log, DEBUG_DEFAULT);
+debug_init(/usr/tmp/slirp.log, DEBUG_DEFAULT);
#ifdef _WIN32
{
Index: qemu/slirp/udp.c
@@ -104,6 +104,9 @@
*/
ip = mtod(m, struct ip *);
uh = (struct udphdr *)((caddr_t)ip + iphlen);
+#if 1
+ DEBUG_MISC((dfd, udp_input(), ip_dst.s_addr=0x%x, uh_dport=%d\n,
ntohl(ip-ip_dst.s_addr), ntohs(uh-uh_dport)));
+#endif
/*
* Make mbuf data length reflect UDP length.
it indeed shows slirp is getting the dest ip + port correctly and
then sends them out wrong:
...
m_get...
m = 9bd7800
ip_input...
m = 9bd7800
m_len = 56
udp_input...
m = 9bd7800
iphlen = 20
udp_input(), ip_dst.s_addr=0xa000203, uh_dport=53
sosendto...
so = 9b39b80
m = 9bd7800
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
...
In between I see these which I'm not sure where they are coming from:
...
m_get...
m = 9bd7800
ip_input...
m = 9bd7800
m_len = 74
udp_input...
m = 9bd7800
iphlen = 20
udp_input(), ip_dst.s_addr=0xe0fb, uh_dport=5353
sosendto...
so = 9b39b80
m = 9bd7800
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
m_get...
m = 9bd7000
ip_input...
m = 9bd7000
m_len = 74
udp_input...
m = 9bd7000
iphlen = 20
udp_input(), ip_dst.s_addr=0xe0fb, uh_dport=5353
sosendto...
so = 9b39b80
m = 9bd7000
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7800
ip_slowtimo...
tcp_slowtimo...
ip_slowtimo...
tcp_slowtimo...
And this is my try giving the real dns (which worked yesterday btw):
m_get...
m = 9bd7800
ip_input...
m = 9bd7800
m_len = 56
udp_input...
m = 9bd7800
iphlen = 20
udp_input(), ip_dst.s_addr=0xd9ed958e, uh_dport=53
sosendto...
so = 9b39b80
m = 9bd7800
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
...
I also got a report which stated that for him also tcp stopped working,
while I still can do http://google.com's ip and get the expected page,
and as said I can also ssh (and scp) to the host (10.0.2.2).
Soo, does anyone know slirp enough to have an idea whats going on here?
The puzzling thing is I don't see recent slirp commits that could be
relevant either...
Thanx,
Juergen
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/pc.c hw/sun4m.c
On 1/7/07, Thiemo Seufer [EMAIL PROTECTED] wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/01/07 20:42:14
Modified files:
. : qemu-doc.texi vl.c vl.h
hw : pc.c sun4m.c
Log message:
Revert -disk patch, as requested by Fabrice. The general idea of
this
patch is sound, but the implementation is just too ugly.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.120r2=1.121
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.233r2=1.234
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.165r2=1.166
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.65r2=1.66
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.22r2=1.23
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
That sun4m.c change breaks disk/cdrom attachment to esp scsi.
Please see the patch to make it work again.
--
Kind regards,
Igor V. Kovalenko
Index: hw/sun4m.c
===
RCS file: /cvsroot/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.23
diff -u -r1.23 sun4m.c
--- hw/sun4m.c 7 Jan 2007 20:42:14 - 1.23
+++ hw/sun4m.c 9 Jan 2007 21:23:53 -
@@ -262,6 +262,13 @@
slavio_serial_init(PHYS_JJ_SER, PHYS_JJ_SER_IRQ, serial_hds[1], serial_hds[0]);
fdctrl_init(PHYS_JJ_FLOPPY_IRQ, 0, 1, PHYS_JJ_FDC, fd_table);
main_esp = esp_init(bs_table, PHYS_JJ_ESP, dma);
+
+for (i = 0; i MAX_DISKS; i++) {
+if (bs_table[i]) {
+esp_scsi_attach(main_esp, bs_table[i], i);
+}
+}
+
slavio_misc = slavio_misc_init(PHYS_JJ_SLAVIO, PHYS_JJ_ME_IRQ);
cs_init(PHYS_JJ_CS, PHYS_JJ_CS_IRQ, slavio_intctl);
sparc32_dma_set_reset_data(dma, main_esp, main_lance);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more)
On Tue, Jan 09, 2007 at 09:47:40PM +0100, Juergen Lock wrote: Hi! I'm not sure why I didn't notice signs of this earlier (using the Dec 25 snapshot, I'm on FreeBSD), maybe I really only talked to the host (10.0.2.2) from inside guests. Anyway, after I first saw it yesterday night, today I sniffed on the external interface and saw dns requests of a `host google.com' going out to 224.0.0.251, port 5353, instead of the dns in resolv.conf. [...] In between I see these which I'm not sure where they are coming from: ... m_get... m = 9bd7800 ip_input... m = 9bd7800 m_len = 74 udp_input... m = 9bd7800 iphlen = 20 udp_input(), ip_dst.s_addr=0xe0fb, uh_dport=5353 sosendto... so = 9b39b80 m = 9bd7800 sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251 m_free... m = 9bd7000 ip_slowtimo... tcp_slowtimo... ... Ok, garrison on irc just helped solve this mystery: This (the same) one actually goes out first, before the 10.0.2.3 one (I didn't notice at first), and since slirp reuses the socket because the source ip and port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the dest ip), the second packet with the 10.0.2.3 dest ip (which gets replaced with the hosts's dns) goes out wrong. And the reason this worked previously with the same guest is multicast started working only recently... (Now why tcp stopped working for the other guy I still don't know...) Thanx, Juergen ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Change the 82371SB PCI-to-ISA bridge into a82371EB
On Tue, Jan 09, 2007 at 09:03:01PM +0300, Alexander Voropay wrote:
Aurelien Jarno [EMAIL PROTECTED] wrote:
This patch changes the 82371SB PCI-to-ISA bridge into a 82371EB.
Note that the ACPI controller
implemented in QEMU is already a 82371EB.
Shouldn't we also change all piix3 names to piix4 ?
[qemu]$ find . -type f | xargs grep piix3 | wc -l
18
You are probably right for this device, but note that the USB and the
IDE controller are still PIIX3. And this corresponds to the emulated
devices. Ideally it would be nice to also change them into PIIX4 by
implementing the missing features. Some of the missing features are
really cool, like DMA support in IDE controller.
Please find below a new patch that also changes the name of the ISA
bridge to piix4. That introduces a sequence in the patches, it needs to
be applied after the patch devfn number for the PIIX3 southbridge.
Bye,
Aurelien
This patch changes the 82371SB PCI-to-ISA bridge into a 82371EB. There
are no differences in the implementation, but the Malta platform needs
this device as there are some PCI fixup in the Linux kernel.
This should be supported without problem by the i386 and x86_64 targets
as there is no standard PC hardware. Note that the ACPI controller
implemented in QEMU is already a 82371EB.
diff -Nurd qemu.orig/hw/pc.c qemu/hw/pc.c
--- qemu.orig/hw/pc.c 2007-01-10 01:46:23.0 +0100
+++ qemu/hw/pc.c2007-01-10 01:47:47.0 +0100
@@ -454,7 +454,7 @@
unsigned long bios_offset, vga_bios_offset, option_rom_offset;
int bios_size, isa_bios_size;
PCIBus *pci_bus;
-int piix3_devfn = -1;
+int piix4_devfn = -1;
CPUState *env;
NICInfo *nd;
@@ -599,7 +599,7 @@
if (pci_enabled) {
pci_bus = i440fx_init(i440fx_state);
-piix3_devfn = piix3_init(pci_bus, -1);
+piix4_devfn = piix4_init(pci_bus, -1);
} else {
pci_bus = NULL;
}
@@ -676,7 +676,7 @@
}
if (pci_enabled) {
-pci_piix3_ide_init(pci_bus, bs_table, piix3_devfn + 1);
+pci_piix3_ide_init(pci_bus, bs_table, piix4_devfn + 1);
} else {
for(i = 0; i 2; i++) {
isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
@@ -695,11 +695,11 @@
cmos_init(ram_size, boot_device, bs_table);
if (pci_enabled usb_enabled) {
-usb_uhci_init(pci_bus, piix3_devfn + 2);
+usb_uhci_init(pci_bus, piix4_devfn + 2);
}
if (pci_enabled acpi_enabled) {
-piix4_pm_init(pci_bus, piix3_devfn + 3);
+piix4_pm_init(pci_bus, piix4_devfn + 3);
}
if (i440fx_state) {
diff -Nurd qemu.orig/hw/piix_pci.c qemu/hw/piix_pci.c
--- qemu.orig/hw/piix_pci.c 2007-01-10 01:46:23.0 +0100
+++ qemu/hw/piix_pci.c 2007-01-10 01:48:32.0 +0100
@@ -40,7 +40,7 @@
return s-config_reg;
}
-static void piix3_set_irq(void *pic, int irq_num, int level);
+static void piix4_set_irq(void *pic, int irq_num, int level);
/* return the global irq number corresponding to a given device irq
pin. We could also use the bus number to have a more precise
@@ -162,7 +162,7 @@
I440FXState *s;
s = qemu_mallocz(sizeof(I440FXState));
-b = pci_register_bus(piix3_set_irq, pci_slot_get_pirq, NULL, 0, 4);
+b = pci_register_bus(piix4_set_irq, pci_slot_get_pirq, NULL, 0, 4);
s-bus = b;
register_ioport_write(0xcf8, 4, 4, i440fx_addr_writel, s);
@@ -196,14 +196,14 @@
/* PIIX3 PCI to ISA bridge */
-PCIDevice *piix3_dev;
+PCIDevice *piix4_dev;
/* just used for simpler irq handling. */
#define PCI_IRQ_WORDS ((PCI_DEVICES_MAX + 31) / 32)
static int pci_irq_levels[4];
-static void piix3_set_irq(void *pic, int irq_num, int level)
+static void piix4_set_irq(void *pic, int irq_num, int level)
{
int i, pic_irq, pic_level;
@@ -211,20 +211,20 @@
/* now we change the pic irq level according to the piix irq mappings */
/* XXX: optimize */
-pic_irq = piix3_dev-config[0x60 + irq_num];
+pic_irq = piix4_dev-config[0x60 + irq_num];
if (pic_irq 16) {
/* The pic level is the logical OR of all the PCI irqs mapped
to it */
pic_level = 0;
for (i = 0; i 4; i++) {
-if (pic_irq == piix3_dev-config[0x60 + i])
+if (pic_irq == piix4_dev-config[0x60 + i])
pic_level |= pci_irq_levels[i];
}
pic_set_irq(pic_irq, pic_level);
}
}
-static void piix3_reset(PCIDevice *d)
+static void piix4_reset(PCIDevice *d)
{
uint8_t *pci_conf = d-config;
@@ -273,26 +273,26 @@
return pci_device_load(d, f);
}
-int piix3_init(PCIBus *bus, int devfn)
+int piix4_init(PCIBus *bus, int devfn)
{
PCIDevice *d;
uint8_t *pci_conf;
-d = pci_register_device(bus, PIIX3, sizeof(PCIDevice),
+d = pci_register_device(bus, PIIX4, sizeof(PCIDevice),
devfn, NULL, NULL);
-register_savevm(PIIX3, 0, 2,
Re: [Qemu-devel] Preliminary Malta platform support
Aurelien Jarno a écrit : Hi, I have recently worked on adding support for the Malta platform [1] with a CoreLV CPU in QEMU. Due to lack of time this is currently not finished, but if you want to try, my preliminary patches are now public. It currently only works with a mipsel platform. They are available on http://temp.aurel32.net/ . The patches 1 to 4 correspond to the patches I have just posted. The patch 5 still needs some work, patch 6 is almost ready. See the header of the patches for more information. There was a bug in the PCI IRQ routing, which caused the network to not work correctly. This is now fixed, the patches are at the same locations. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
