Re: [Qemu-devel] [PATCH] qemu: generate signals on tap I/O
Anders Melchiorsen a écrit :
Aurelien Jarno [EMAIL PROTECTED] writes:
The patch below from KVM improves network transfers in a huge way.
wget in a MIPS target now gives me a transfer speed of up to 120
Mbits/s with an e1000 emulated card.
Without I/O signals, qemu is relying on periodic timer events to poll
the I/O. That seems wrong, even though it works reasonably well
because timers are so frequent. In KVM, timers are less frequent, and
it does not work quite as well.
Here is a quick try at a more elaborate patch.
It attaches a signal to all[1] file descriptors that will be used in
select(). Also, it uses a dedicated SIGIO handler rather than
piggybacking on the alarm handler, so alarm I/O is changed to use
SIGALRM.
I copied the handler function from the alarm case, quite frankly I do
not quite understand what is going on. Also, I left _WIN32 out, since
I have no idea how signals work there.
I have just given a tried to your patch, which looks indeed more
complete. I have made some performance measurement
(qemu-system-mips64el, 2.6.24 5kc kernel), I am getting the same
performances as with my patches on the network side, and a very small
improvement ( 3%) on the hard disk performance, but it can also be
noise (though the measurements looked quite stable).
Anybody to commit this patch?
diff --git a/vl.c b/vl.c
index c87e8bc..ff8ceef 100644
--- a/vl.c
+++ b/vl.c
@@ -1148,6 +1148,25 @@ static int timer_load(QEMUFile *f, void *opaque, int
version_id)
return 0;
}
+#ifndef _WIN32
+static void host_io_handler(int host_signum)
+{
+CPUState *env = next_cpu;
+
+if (env) {
+/* stop the currently executing cpu because io occured */
+cpu_interrupt(env, CPU_INTERRUPT_EXIT);
+#ifdef USE_KQEMU
+if (env-kqemu_enabled) {
+kqemu_cpu_interrupt(env);
+}
+#endif
+}
+
+event_pending = 1;
+}
+#endif
+
#ifdef _WIN32
void CALLBACK host_alarm_handler(UINT uTimerID, UINT uMsg,
DWORD_PTR dwUser, DWORD_PTR dw1, DWORD_PTR
dw2)
@@ -1240,7 +1259,20 @@ static uint64_t qemu_next_deadline(void)
#define RTC_FREQ 1024
-static void enable_sigio_timer(int fd)
+static void enable_sigio(int fd)
+{
+struct sigaction act;
+
+sigfillset(act.sa_mask);
+act.sa_flags = 0;
+act.sa_handler = host_io_handler;
+
+sigaction(SIGIO, act, NULL);
+fcntl(fd, F_SETFL, O_ASYNC);
+fcntl(fd, F_SETOWN, getpid());
+}
+
+static void enable_sigalrm(int fd)
{
struct sigaction act;
@@ -1249,8 +1281,9 @@ static void enable_sigio_timer(int fd)
act.sa_flags = 0;
act.sa_handler = host_alarm_handler;
-sigaction(SIGIO, act, NULL);
+sigaction(SIGALRM, act, NULL);
fcntl(fd, F_SETFL, O_ASYNC);
+fcntl(fd, F_SETSIG, SIGALRM);
fcntl(fd, F_SETOWN, getpid());
}
@@ -1287,7 +1320,7 @@ static int hpet_start_timer(struct qemu_alarm_timer *t)
if (r 0)
goto fail;
-enable_sigio_timer(fd);
+enable_sigalrm(fd);
t-priv = (void *)(long)fd;
return 0;
@@ -1325,7 +1358,7 @@ static int rtc_start_timer(struct qemu_alarm_timer *t)
return -1;
}
-enable_sigio_timer(rtc_fd);
+enable_sigalrm(rtc_fd);
t-priv = (void *)(long)rtc_fd;
@@ -5481,6 +5514,10 @@ int qemu_set_fd_handler2(int fd,
return -1;
ioh-next = first_io_handler;
first_io_handler = ioh;
+#ifndef _WIN32
+enable_sigio(fd);
+#endif
+
found:
ioh-fd = fd;
ioh-fd_read_poll = fd_read_poll;
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] Re: [PATCH] linux-user/mmap v3: Testsuite + bugfixes
On Sat, Feb 23, 2008 at 10:58:12AM +0200, Felipe Contreras wrote: On Fri, Feb 22, 2008 at 5:32 PM, Edgar E. Iglesias [EMAIL PROTECTED] wrote: Hi, This is the third version of the linux-user/mmap bugfix patches: * Let the native mmap choose addresses for unfixed mappings. * For file mappings, correct mapping of pages beyond EOF. * Adds a small testsuite for linux-user/mmap. Tested with test-mmap for CRIS, MIPS, ARM and i386, simulated on linux-i686 hosts. Felipe, I think the problems you are seeing are related to large mmaps failing. By letting the native mmap choose the addresses for unfixed mmaps, I hope your segfaults will go away. This patch does fix the weird issues I was having. Does the test checks for the issues I had? Hello Felipe, Sorry for the delays. No, the checks won't find regressions with this particular issue. I'll try to write something when I get a chance. Thanks for all the help debugging this. Best regards -- Edgar E. Iglesias Axis Communications AB
Re: [Qemu-devel] [PATCH] allow update of MSR_EFER_SVM
On Wed, Feb 27, 2008 at 06:03:49PM +0100, Alexander Graf wrote: MSR_EFER_SVM is not defined in my qemu version. What does the bit change if set? The AMD vol2 reads like this: Secure Virtual Machine Enable (SVME) Bit. Bit 12. Enables the SVM extensions. When this bit is zero, the SVM instructions cause #UD exceptions. The bit was called MSR_EFER_SVME_MASK in svm.h before, I renamed it in the attached patch to MSR_EFER_SVME to match the style of the other definitions in cpu.h. BTW, triggering the above mentioned #UD is missing in the code... Bernhard Kauer Index: target-i386/helper.c === RCS file: /sources/qemu/qemu/target-i386/helper.c,v retrieving revision 1.101 diff -u -r1.101 helper.c --- target-i386/helper.c 3 Feb 2008 03:26:30 - 1.101 +++ target-i386/helper.c 29 Feb 2008 09:33:41 - @@ -2802,6 +2802,8 @@ update_mask |= MSR_EFER_FFXSR; if (env-cpuid_ext2_features CPUID_EXT2_NX) update_mask |= MSR_EFER_NXE; + if (env-cpuid_ext3_features CPUID_EXT3_SVM) + update_mask |= MSR_EFER_SVME; env-efer = (env-efer ~update_mask) | (val update_mask); } Index: target-i386/svm.h === RCS file: /sources/qemu/qemu/target-i386/svm.h,v retrieving revision 1.1 diff -u -r1.1 svm.h --- target-i386/svm.h 23 Sep 2007 15:30:28 - 1.1 +++ target-i386/svm.h 29 Feb 2008 09:33:41 - @@ -179,7 +179,7 @@ #define SVM_CPUID_FEATURE_SHIFT 2 #define SVM_CPUID_FUNC 0x800a -#define MSR_EFER_SVME_MASK (1ULL 12) +#define MSR_EFER_SVME (1ULL 12) #define SVM_SELECTOR_S_SHIFT 4 #define SVM_SELECTOR_DPL_SHIFT 5
Re: [Qemu-devel] [PATCH] allow update of MSR_EFER_SVM
On Feb 29, 2008, at 10:41 AM, Bernhard Kauer wrote: On Wed, Feb 27, 2008 at 06:03:49PM +0100, Alexander Graf wrote: MSR_EFER_SVM is not defined in my qemu version. What does the bit change if set? The AMD vol2 reads like this: Secure Virtual Machine Enable (SVME) Bit. Bit 12. Enables the SVM extensions. When this bit is zero, the SVM instructions cause #UD exceptions. The bit was called MSR_EFER_SVME_MASK in svm.h before, I renamed it in the attached patch to MSR_EFER_SVME to match the style of the other definitions in cpu.h. BTW, triggering the above mentioned #UD is missing in the code... Could you please add the #UD check to the vm* helpers too? It's not that many and I don't see a point in implementing this half-heartedly. Keep in mind that updating the bit should fail within a virtual machine. Alex
Re: RE : [Qemu-devel] Atheros Wireless Device Emulation
Hi... I really appreciate the patch's author for his work. Thanks for sharing! regards, Mulyadi.
Re: [Qemu-devel] [PATCH] allow update of MSR_EFER_SVM
On Fri, Feb 29, 2008 at 11:20:24AM +0100, Alexander Graf wrote: Keep in mind that updating the bit should fail within a virtual machine. I found the following sentence in the manual: The effect of turning off EFER.SVME while a guest is running is undefined; therefore, the VMM should always prevent guests from writing EFER. Therefore i think the wrmsr-code is just fine, as it is in my patch. Bernhard Kauer
[Qemu-devel] Re: Qemu-devel Digest, Vol 59, Issue 88
On Friday 29 February 2008 19:22:53 Sylvain Petreolle wrote: Look at pci.c.rej. Because of the lines of the recent e1000 pci card inclusion, patch refuses to apply it. Its just a matter of resynch... ok thanks. will take a look at it!
[Qemu-devel] RE : Re: Qemu-devel Digest, Vol 59, Issue 88
Look at pci.c.rej.
Because of the lines of the recent e1000 pci card inclusion,
patch refuses to apply it.
Its just a matter of resynch...
--- Clemens Kolbitsch [EMAIL PROTECTED] a écrit :
On Friday 29 February 2008 01:20:10 [EMAIL PROTECTED] wrote:
The emulation works beautifully on windows Xp Pro SP2 guest and official
Atheros drivers, no installation problems at all.
Nice job !
Some infos about the patch:
- 2 lines added to pci.c
you have to take recent e1000 inclusion to make it apply cleanly on CVS
- added function declaration to pci.h
- patched Makefile.target (2 lines)
VL_OBJS = OBJS, now VL_OBJS are gone
- added files qemu/hw/atheros_wlan_.*.[ch]
- took 2 files from wireshark to generate CRC32 checksums
- took 3 files from ath5k
--- licence people, please have a look if that is ok!!
Enabling emulation:
Keep up the good work !
I'd love to add it to CVS. Checked out the repository, but I don't really
know
what you mean with take recenent e1000 inclusion. Could you clarify that a
little? Looked at (e.g.) ne2000.c and rtl8139.c and it's just like my code, I
guess...
Kind regards,
Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
Free music you can listen to everywhere : http://www.jamendo.com***
*** 636,641
pci_i82559er_init(bus, nd, devfn);
} else if (strcmp(nd-model, rtl8139) == 0) {
pci_rtl8139_init(bus, nd, devfn);
} else if (strcmp(nd-model, pcnet) == 0) {
pci_pcnet_init(bus, nd, devfn);
} else if (strcmp(nd-model, ?) == 0) {
--- 636,643
pci_i82559er_init(bus, nd, devfn);
} else if (strcmp(nd-model, rtl8139) == 0) {
pci_rtl8139_init(bus, nd, devfn);
+ } else if (strncmp(nd-model, atheros_wlan, 12) == 0) {
+ pci_Atheros_WLAN_init(bus, nd, devfn);
} else if (strcmp(nd-model, pcnet) == 0) {
pci_pcnet_init(bus, nd, devfn);
} else if (strcmp(nd-model, ?) == 0) {
Re: [Qemu-devel] [PATCH] Let ESP SCSI adapter to be usable outside sun4m
On 2/24/08, Hervé Poussineau [EMAIL PROTECTED] wrote: Hi, At the moment, ESP SCSI adapter can only be used inside sun4m machines. Attached patch moves the declaration outside sun4m.h, so other machines can also use it. I've moved the declaration to devices.h because I found no better place to put it. If you know a better place, please tell me :) Good idea, but the patch breaks compiling other targets than Sparc32, because the DMA functions are not defined. Before we have the generic DMA, it may be possible to add #defines to use other DMA controllers' functions. Or the correct access functions could be registered at init time for small performance penalty.
[Qemu-devel] qemu/hw fdc.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 08/02/29 19:24:00 Modified files: hw : fdc.c Log message: Give names to magic numbers (Hervé Poussineau) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/fdc.c?cvsroot=qemur1=1.37r2=1.38
[Qemu-devel] qemu/hw sun4m.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 08/02/29 19:26:20 Modified files: hw : sun4m.c Log message: Fix sun4m machine if MAX_FD != 2 (Hervé Poussineau) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.84r2=1.85
[Qemu-devel] qemu/tcg/x86_64 tcg-target.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 08/02/29 19:36:08 Modified files: tcg/x86_64 : tcg-target.c Log message: Fix compiler warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemur1=1.3r2=1.4
Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Fri, Feb 29, 2008 at 2:33 AM, Arnon Gilboa [EMAIL PROTECTED] wrote: In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With usb_ehci_init(pci_bus, piix3_devfn + 2); With these changes.. I can't add the usb devices anymore to a Windows XP (32 bit). This is the command i use to start kvm: /usr/local/bin/kvm/qemu-system-x86_64 -localtime -m 512 -usb -hda win32xp.img To add usb device i normally go to the qemu console and type: info usbhost find the number for my device i want to connect to usb_add host:03f0:01cda But with your patch, when i try to add a usb device i get: Could not add 'USB device host:03f0:01cda' Since i'm using EHCI emulation, do i need to add usb devices in a different way? Or should it work exactly the same way? Thanks, Jerry Note my comments on the original post: -tested on XP guest -does not support ISO transfers -timing issues -Original Message- From: Gerb Stralko [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 9:46 PM To: Arnon Gilboa Cc: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation Attached is a repost of the preliminary patch implementing USB 2.0 EHCI emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. Waiting for your comments, Arnon Thanks, Jerry
Re: [Qemu-devel] qemu-system-amd64 (0.9.1) and freebsd guest - irq patch (pointer)
In article [EMAIL PROTECTED] you write: I reported this bug and gave a patch. http://www.nabble.com/forum/ViewPost.jtp?post=14921171 Hmm, any particular reason this hasn't been committed yet? Just wondering... Juergen
