[Qemu-devel] ES1370 problems with Win98SE
Hello. First, let me say that I realize this is not exactly the place for this. Non-developer problems with Qemu should go on the Qemu forum... But they're down right now, so please bear with me here. I apologize for taking up all you developers' time. I have a Windows Vista host (I know, mistake # 1) running Win98SE as a guest. I launch QEMU with QEMU Manager instead of the command line. The only problem I have is the sound. Win98SE correctly recognizes the SB16 emulated card and it works... But there's a lot of interference in the wave sound (haven't tried midi yet). Not to say that the SB16 emulation is bad or anything, it's probably that Vista's revamped sound system is screwing things up. But anyway, I went into Qemu manager and disabled the SB16 emulation and activated the ES1370 emulation... But Win98 will not recognize the emulated ES1370 card, it doesn't even see it. I tried downloading the corresponding driver from Creative's site, and while the driver appeared to install correctly, Win98 still does not see the card. What am I doing wrong?
Re: [Qemu-devel] Removal of some target CPU macros
On Thu, 2007-11-08 at 14:09 +0100, Tristan Gingold wrote: > Two side comments: Hi, > > Note that most (all ?) embedded Freescale PowerPC microcontrollers > > implement those extensions and that some ones are greatly interrested > > with having an usable emulation avaible for those CPUs. > > Has anyone started to implement spe ? Large parts of the SPE extensions are implemented, most fixed-point operations (but the multiply and add family) and I think almost all floating-point operations (the flags are not properly emulated, for now). But there's a lack of a CPU model that would really use it. It could be made available very easily for a test CPU for user-mode only, as it is now. The MMU model used on Freescale cores is not implemented yet, then the full-system emulation would not be possible for now. > > - someone provide an open-source hypervisor, compatible with the ones > > used on real machines, that would allow at least Linux to be able > > to run > > on a CPU with hypervisor mode available. > > Does xen/ppc satisfy your requirement ? > Maybe Hollis will comment. I don't know really. I guess it may do for the more urgent need which is to have a fully "transparent" hypervisor that would enable the OS to access all resources. I won't bet it could be a replacement for IBM hypervisor software as the full specifications of this software have still not be fully released (the PPAR document, which describes the whole hypervisor features is still a draft). But it's a good idea, I may take a look of what it could provide. -- J. Mayer <[EMAIL PROTECTED]> Never organized
[Qemu-devel] [PATCH] multiboot support
Hi, this patch adds very simple multiboot support for x86 as defined in http://www.gnu.org/software/grub/manual/multiboot/ using the -kernel switch. There is no support for modules or command line parsing, as it would be required by XEN or HURD, but simple OSs already work when used in conjunction with this patch. Adding module support should be as simple as writing the modules into RAM and setting some information fields in the bootinfo structure (if anyone's interested in booting more than linux without a full-blown bootloader). The only one I have tested so far is the boot2 darwin bootloader modified to work using multiboot by David F. Elliott, which worked fine bringing up first parts of a stock osx kernel. I believe this patch does not break anything and is safe to be applied, whereas comments are (as always) welcome though. Cheers, Alex qemu-multiboot.patch Description: Binary data
[Qemu-devel] qemu configure linux-user/main.c linux-user/sig...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/08 18:05:37 Modified files: . : configure linux-user : main.c signal.c syscall_defs.h target-mips: exec.h helper.c mips-defs.h op.c op_helper.c op_mem.c op_template.c translate.c translate_init.c Log message: Clean out the N32 macros from target-mips, and introduce MIPS ABI specific defines for linux-user. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.168&r2=1.169 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.143&r2=1.144 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.48&r2=1.49 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemu&r1=1.43&r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.41&r2=1.42 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.57&r2=1.58 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.84&r2=1.85 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.70&r2=1.71 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_mem.c?cvsroot=qemu&r1=1.15&r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_template.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.111&r2=1.112 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&r1=1.26&r2=1.27
Re: [Qemu-devel] fake device to access to host fs
On Nov 8, 2007, at 5:35 PM, Eduardo Felipe wrote: Have a look to the vvfat block device. Thanks, I was not aware of it. I think it will fill my requirements.
[Qemu-devel] qemu audio/.cvsignore slirp/.cvsignore
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/08 16:44:36 Added files: audio : .cvsignore slirp : .cvsignore Log message: More .cvsignore. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/audio/.cvsignore?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/.cvsignore?cvsroot=qemu&rev=1.1
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/08 16:44:01 Modified files: target-mips: translate.c Log message: Formatting fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.110&r2=1.111
[Qemu-devel] qemu .cvsignore
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/08 16:43:05 Modified files: . : .cvsignore Log message: .cvsignore dependency files. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/.cvsignore?cvsroot=qemu&r1=1.22&r2=1.23
[Qemu-devel] qemu/hw ide.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/08 16:38:17 Modified files: hw : ide.c Log message: Revert "Last AIO Patch" as requested by Fabrice, it is incomplete and breaks other (non-Windows) systems. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.69&r2=1.70
Re: [Qemu-devel] fake device to access to host fs
2007/11/8, Tristan Gingold <[EMAIL PROTECTED]>: > > Hi, > > has anyone already implemented a fake device to access to the host FS ? > > I am planning to implement one soon, but if it is already available... > > Thanks, > Tristan. Hi, Have a look to the vvfat block device. Regards, Edu
Re: [Qemu-devel] fake device to access to host fs
Tristan Gingold wrote: Hi, has anyone already implemented a fake device to access to the host FS ? 9p in Linux has a virtio transport. I've just published a PCI virtio layer and have an initial implementation for QEMU. My plan is to combine 9p, virtio, and a 9p server in QEMU to allow a "hostfs" for QEMU. Of course, this only solves the problem for Linux but that's all I really care about. Regards, Anthony Liguori I am planning to implement one soon, but if it is already available... Thanks, Tristan.
[Qemu-devel] [PATCH] remove unused parameters from QEMUMachineInitFunc
It appears that fd_filename and snapshot are not needed/used by machine init functions (QEMUMachineInitFunc). This patch removes them. Index: qemu/vl.h === --- qemu.orig/vl.h 2007-11-08 16:36:36.0 +0100 +++ qemu/vl.h 2007-11-08 16:37:04.0 +0100 @@ -790,8 +790,7 @@ #ifndef QEMU_TOOL typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size, - const char *boot_device, - DisplayState *ds, const char **fd_filename, int snapshot, + const char *boot_device, DisplayState *ds, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model); Index: qemu/hw/an5206.c === --- qemu.orig/hw/an5206.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/an5206.c 2007-11-08 16:37:04.0 +0100 @@ -27,8 +27,8 @@ /* Board init. */ -static void an5206_init(int ram_size, int vga_ram_size, const char *boot_device, - DisplayState *ds, const char **fd_filename, int snapshot, +static void an5206_init(int ram_size, int vga_ram_size, + const char *boot_device, DisplayState *ds, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) { Index: qemu/hw/etraxfs.c === --- qemu.orig/hw/etraxfs.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/etraxfs.c 2007-11-08 16:37:04.0 +0100 @@ -107,8 +107,8 @@ } static -void bareetraxfs_init (int ram_size, int vga_ram_size, const char *boot_device, - DisplayState *ds, const char **fd_filename, int snapshot, +void bareetraxfs_init (int ram_size, int vga_ram_size, + const char *boot_device, DisplayState *ds, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) { Index: qemu/hw/integratorcp.c === --- qemu.orig/hw/integratorcp.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/integratorcp.c 2007-11-08 16:37:04.0 +0100 @@ -464,7 +464,6 @@ static void integratorcp_init(int ram_size, int vga_ram_size, const char *boot_device, DisplayState *ds, - const char **fd_filename, int snapshot, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) { Index: qemu/hw/mcf5208.c === --- qemu.orig/hw/mcf5208.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/mcf5208.c 2007-11-08 16:37:04.0 +0100 @@ -199,7 +199,6 @@ static void mcf5208evb_init(int ram_size, int vga_ram_size, const char *boot_device, DisplayState *ds, - const char **fd_filename, int snapshot, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) { Index: qemu/hw/mips_malta.c === --- qemu.orig/hw/mips_malta.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/mips_malta.c 2007-11-08 16:37:04.0 +0100 @@ -740,8 +740,8 @@ } static -void mips_malta_init (int ram_size, int vga_ram_size, const char *boot_device, - DisplayState *ds, const char **fd_filename, int snapshot, +void mips_malta_init (int ram_size, int vga_ram_size, + const char *boot_device, DisplayState *ds, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) { Index: qemu/hw/mips_mipssim.c === --- qemu.orig/hw/mips_mipssim.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/mips_mipssim.c 2007-11-08 16:37:04.0 +0100 @@ -94,8 +94,8 @@ } static void -mips_mipssim_init (int ram_size, int vga_ram_size, const char *boot_device, - DisplayState *ds, const char **fd_filename, int snapshot, +mips_mipssim_init (int ram_size, int vga_ram_size, + const char *boot_device, DisplayState *ds, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) { Index: qemu/hw/palm.c === --- qemu.orig/hw/palm.c 2007-11-08 16:36:35.0 +0100 +++ qemu/hw/palm.c 2007-11-08 16:37:04.0 +0100 @@ -179,7 +179,6 @@ static void palmte_init(int ram_size, int vga_ram_size,
[Qemu-devel] fake device to access to host fs
Hi, has anyone already implemented a fake device to access to the host FS ? I am planning to implement one soon, but if it is already available... Thanks, Tristan.
Re: [Qemu-devel] PC Bios source code?
andrzej zaborowski wrote: As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. But how can he tell what the original source is? At the minimum the version numbers of all source files in the bochs cvs need to be listed. The .diff contains revision numbers for all files. Only for files that are changed by said .diff. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] PC Bios source code?
On 08/11/2007, Avi Kivity <[EMAIL PROTECTED]> wrote: > Andreas Färber wrote: > > Hi, > > > > Am 08.11.2007 um 02:34 schrieb Jun Koi: > > > >> In pc-bios/ directory, we have bios.bin and bios.diff. As I > >> understand, qemu's bios is modified from bochs bios. But what are the > >> differences between our bios.bin and bochs bios.bin? > >> > >> As there are some differences, where is the source code of our > >> bios.bin?? > > > > As you said yourself, there's also a .diff file. It should contain all > > differences between original source code and modified source code. You > > can apply it to the original source code with patch. > > > > But how can he tell what the original source is? > > At the minimum the version numbers of all source files in the bochs cvs > need to be listed. The .diff contains revision numbers for all files. Regards
Re: [Qemu-devel] PC Bios source code?
Andreas Färber wrote: Hi, Am 08.11.2007 um 02:34 schrieb Jun Koi: In pc-bios/ directory, we have bios.bin and bios.diff. As I understand, qemu's bios is modified from bochs bios. But what are the differences between our bios.bin and bochs bios.bin? As there are some differences, where is the source code of our bios.bin?? As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. But how can he tell what the original source is? At the minimum the version numbers of all source files in the bochs cvs need to be listed. -- error compiling committee.c: too many arguments to function
[Qemu-devel] qemu Makefile.target cpu-exec.c exec.c translat...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/08 14:25:03 Modified files: . : Makefile.target cpu-exec.c exec.c translate-all.c vl.c darwin-user: main.c signal.c linux-user : main.c signal.c target-i386: cpu.h helper2.c translate.c tests : qruncom.c Log message: removed obsolete x86 code copy support CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.217&r2=1.218 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.121&r2=1.122 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.111&r2=1.112 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.354&r2=1.355 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/main.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/signal.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.142&r2=1.143 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.52&r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.55&r2=1.56 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.73&r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/tests/qruncom.c?cvsroot=qemu&r1=1.6&r2=1.7
[Qemu-devel] qemu/target-i386 translate-copy.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/08 14:24:28 Removed files: target-i386: translate-copy.c Log message: removed CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate-copy.c?cvsroot=qemu&r1=1.9&r2=0
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/08 14:01:49 Modified files: linux-user : main.c Log message: removed unused code CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.141&r2=1.142
Re: [Qemu-devel] PC Bios source code?
Hi, Am 08.11.2007 um 02:34 schrieb Jun Koi: In pc-bios/ directory, we have bios.bin and bios.diff. As I understand, qemu's bios is modified from bochs bios. But what are the differences between our bios.bin and bochs bios.bin? As there are some differences, where is the source code of our bios.bin?? As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. HTH, Andreas
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/08 13:56:19 Modified files: linux-user : main.c Log message: added -cpu option for x86 - fixed glibc hack in case the global variables are moved CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.140&r2=1.141
[Qemu-devel] qemu hw/pc.c target-i386/cpu.h target-i386/help...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/08 13:28:47 Modified files: hw : pc.c target-i386: cpu.h helper2.c Log message: added -cpu option for x86 (initial patch by Dan Kenigsberg) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.89&r2=1.90 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.51&r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.54&r2=1.55
RE: [Qemu-devel] No cancel callback for usb-ohci
You may add a flag to USBPacket and raise it upon your ohci_async_cancel_packet. ohci_async_complete_packet will check this flag and do nothing if it is up. Am I missing something? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 12:47 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] No cancel callback for usb-ohci Hi Arnon, On Nov 8, 2007 3:28 PM, Arnon Gilboa <[EMAIL PROTECTED]> wrote: > Seems like an ugly bug (common also to uhci), which I haven't noticed > before. > I guess this scenario has never happened to me. Can you please > describe it? What I'm trying to do is to prevent the lag caused by the USBDEVFS_BULK ioctl and instead send the bulk transfers asynchronously using the USBDEVFS_SUBMITURB ioctl. I'm taking the help of the patch you had sent for isochronous packets. This scenario occurs when the usb bluetooth dongle is added to the linux guest and its interface is brought up. > Call usb_defer_packet with cancel_cb which flags the packet, so the > following usb_packet_complete will be ignored. To call usb_defer_packet, there needs to be a callback function like the usb_msd_cancel_io function used in hw/usb-msd.c: usb_defer_packet(p, usb_msd_cancel_io, s); There doesn't seem to be a similar cancel_cb callback for ohci. An empty stub function prevents this crash, but should it be doing more stuff like the msd one does? Salil > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Salil Bijur > Sent: Thursday, November 08, 2007 8:51 AM > To: qemu-devel@nongnu.org > Subject: [Qemu-devel] No cancel callback for usb-ohci > > Hello, > > There is a call to the function usb_cancel_packet in hw/usb-ohci.c. > However, there is no cancel_cb callback registered for the > ohci->usb_packet resulting in a segmentation fault. > > Are there any plans to implement this cancel callback? > > Thanks, > Salil > > > > >
Re: [Qemu-devel] Removal of some target CPU macros
Two side comments: Note that most (all ?) embedded Freescale PowerPC microcontrollers implement those extensions and that some ones are greatly interrested with having an usable emulation avaible for those CPUs. Has anyone started to implement spe ? - someone provide an open-source hypervisor, compatible with the ones used on real machines, that would allow at least Linux to be able to run on a CPU with hypervisor mode available. Does xen/ppc satisfy your requirement ? Maybe Hollis will comment.
Re: [Qemu-devel] No cancel callback for usb-ohci
Hi Arnon, On Nov 8, 2007 3:28 PM, Arnon Gilboa <[EMAIL PROTECTED]> wrote: > Seems like an ugly bug (common also to uhci), which I haven't noticed > before. > I guess this scenario has never happened to me. Can you please describe > it? What I'm trying to do is to prevent the lag caused by the USBDEVFS_BULK ioctl and instead send the bulk transfers asynchronously using the USBDEVFS_SUBMITURB ioctl. I'm taking the help of the patch you had sent for isochronous packets. This scenario occurs when the usb bluetooth dongle is added to the linux guest and its interface is brought up. > Call usb_defer_packet with cancel_cb which flags the packet, so the > following usb_packet_complete will be ignored. To call usb_defer_packet, there needs to be a callback function like the usb_msd_cancel_io function used in hw/usb-msd.c: usb_defer_packet(p, usb_msd_cancel_io, s); There doesn't seem to be a similar cancel_cb callback for ohci. An empty stub function prevents this crash, but should it be doing more stuff like the msd one does? Salil > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Salil Bijur > Sent: Thursday, November 08, 2007 8:51 AM > To: qemu-devel@nongnu.org > Subject: [Qemu-devel] No cancel callback for usb-ohci > > Hello, > > There is a call to the function usb_cancel_packet in hw/usb-ohci.c. > However, there is no cancel_cb callback registered for the > ohci->usb_packet resulting in a segmentation fault. > > Are there any plans to implement this cancel callback? > > Thanks, > Salil > > > > >
Re: [Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity wrote: Fabrice Bellard wrote: Avi Kivity wrote: Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? Sure. The conversion from sync to async mode done in this patch is incomplete to say the least. Is reverting the patch safe, or will it cause new problems? The patch must be reverted because it implements incorrectly the AIO write case (e.g. nsector is modified before the IO actually takes place). The previous code was at least correct if win2k_install_hack was not enabled and if one considered than the PIO I/Os were instantaneous. Regards, Fabrice.
Re: [Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Fabrice Bellard wrote: Avi Kivity wrote: Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? Sure. The conversion from sync to async mode done in this patch is incomplete to say the least. Is reverting the patch safe, or will it cause new problems? (I'm not sure what "Sure" above refers to) -- error compiling committee.c: too many arguments to function
Re: [kvm-devel] [Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
Fabrice Bellard wrote: Hi, Some remarks: - rename the option to -pcidevice. - Remove the directory passthrough and put the file directly in hw/. Rename the file to something more explicit such as pci_passthrough* - Suppress the files passthrough.h and neo_pci_tree.h - pt_init should be called only if there are really devices. Moreover the code should be disabled for non Linux hosts. Can this support work if KVM is not used for CPU emulation ? Can it work for non x86 targets ? This patchset can work without kvm (although not tested). It can do so using a kernel module that forwards irqs to userspace. I'm not sure it will make it into Linux kernel since it allows userspace irq handling. We actually try to convert the current patch to our in-kernel apic version that won't forward irqs to userspace and hence won't work without kvm. If you're interested in pass through to qemu/kqemu (seems like a cool feature) we can try to support both. Dor. Regards, Fabrice. Amit Shah wrote: > This patch introduces support for device passthrough > from the host to a paravirtualized guest. > > A new command-line option, -passthrough is added. > For example, to invoke it for an Ethernet device sitting at > PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: > > -passthrough Ethernet/04:08.0-18 > > The host driver is to be removed before doing the passthrough. >
RE: [Qemu-devel] No cancel callback for usb-ohci
Seems like an ugly bug (common also to uhci), which I haven't noticed before. I guess this scenario has never happened to me. Can you please describe it? Call usb_defer_packet with cancel_cb which flags the packet, so the following usb_packet_complete will be ignored. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 8:51 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] No cancel callback for usb-ohci Hello, There is a call to the function usb_cancel_packet in hw/usb-ohci.c. However, there is no cancel_cb callback registered for the ohci->usb_packet resulting in a segmentation fault. Are there any plans to implement this cancel callback? Thanks, Salil
[Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity a écrit : > Aurelien Jarno wrote: >> Well the IDE code hasn't changed a lot recently, so I checked the CVS >> history and easily (first test) found the commit that causes the problem: >> >> Last AIO patch, by Vladimir N. Oleynik. >> >> http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65 >> >> > > Have we learned something about this issue? Should I revert the patch > from kvm? Should qemu? > >From my side, I haven't found time to debug the problem. Instead I am reverting this patch locally each time I install qemu or kvm. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] [PATCH 1/3] Add args to -cdrom to define where is connected the cdrom
Laurent Vivier wrote: Le jeudi 08 novembre 2007 à 00:32 +0100, Fabrice Bellard a écrit : Laurent Vivier wrote: Thiemo Seufer a écrit : Laurent Vivier wrote: Daniel P. Berrange a écrit : On Sun, Oct 28, 2007 at 11:43:33PM +0100, [EMAIL PROTECTED] wrote: From: Laurent Vivier <[EMAIL PROTECTED](none)> This patch allows to define where is connected the CDROM device (bus, unit). It extends the "-cdrom" syntax to add these paramaters: -cdrom file[,if=type][,bus=n][,unit=m] where "type" defines the interface (by default, "ide") "n" defines the bus number (by default 1) "m" defines the unit number (by default 0) Having a separately named arg just for CDROMs was always rather odd/unhelpful. I'd suggest that we leave all the -hda,hdb,hdc,-cdrom,-fda,-fdb etc unchanged and use the -disk for setting up all types of disks, floppys, cdroms, etc. It would just require one extra field for the -disk arg: -disk file[,if=type][,bus=n][,unit=m][,mode=mode] where "type" defines the interface. [ide,scsi,fd] (by default, "ide") "n" defines the bus number (by default 1) "m" defines the unit number (by default 0) "mode" defines one of [disk,floppy,cdrom] If we ever up able to emulate other types of SCSI / IDE devices (tape drives, cdr, dvd perhaps) then the 'mode' can easily be extended to cover them. I agree with that. And if everyone agrees I can modify patches to do that... Please go ahead. :-) Well, it is done... is there someone that can comment them ? Or if they are perfect (as usual ;-) ) perhaps it could be included in CVS ? I had rejected a similar patch in the past, but I agree that a -disk command line option is needed. A few remarks: - Add a function in vl.c to add a disk so that all option handlers can call it instead of doing pstrcpy(); nb_disk++. I agree - You replaced the constant "2" in many machines by MAX_IDE_BUS. It is dangerous because each machine has its own constraints. I agree, I'll use MAX_IDE_BUS only for PC. But how can I compute MAX_DISKS if the number of IDE disks vary with target ? What is important is that MAX_IDE_BUS is bigger than the number of IDE disks used by every machine. If the machine does not use them it is less an issue. If you use DriveInfo you no longer have this problem. For the moment it is the sum of all available MAX_* . Should I take an explicit value like "32" or something like ? If you use my suggestion of DriveInfo structure, this problem disappears as you will have a single constant MAX_DISKS that you can set to a fixed value. - Maybe the real option name could be "-drive" to insist on the fact that a drive can be created without a disk in it ! Any more comments ? I agree, and a drive can be something else like a flash or a tape (in the future...). - disk_init() should not modify its argument str. Moreover, maybe having an explicit "file=" argument would be clearer in the case there is no disk in the drive. I'm not sure I understand correctly this one. For the moment "-disk ," allows to declare a drive without media (an empty CDROM drive, for instance). Do you mean we must use "-drive file=a.img" instead of "-disk a.img" and "-drive file=" instead of "-disk ," Yes "-disk file=a.img" or "-disk media=cdrom". But I am open to other suggestion. I was just surprised by the syntax "-disk ,media=cdrom". - While modifying the machine init function, you can suppress the snapshot parameter. OK - In disk_init(), you should factorize the bdrv_new() and bdrv_open() as it is the same for all types. OK. Can I use bdrv_set_geometry_hint() and bdrv_set_translation_hint() before the bdrv_open() ? It seems possible. - It could be simpler to export an array of structs containg a bdrv, each one tagged with if, index and bus. Then each machine could call a function to get the bdrv from the parameters "if", "index" and "bus". For example, look at the NICInfo structure and do the same with a structure DriveInfo... OK If you prefer, you can resubmit a big patch with all the changes. Well, I like to write a lot of little patches ;-) It is easier to review them, isn't it ? But it is as you want. As you wish. Regards, Fabrice.
Re: [Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity wrote: Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? Sure. The conversion from sync to async mode done in this patch is incomplete to say the least. Fabrice.
Re: [Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
Hi, Some remarks: - rename the option to -pcidevice. - Remove the directory passthrough and put the file directly in hw/. Rename the file to something more explicit such as pci_passthrough* - Suppress the files passthrough.h and neo_pci_tree.h - pt_init should be called only if there are really devices. Moreover the code should be disabled for non Linux hosts. Can this support work if KVM is not used for CPU emulation ? Can it work for non x86 targets ? Regards, Fabrice. Amit Shah wrote: This patch introduces support for device passthrough from the host to a paravirtualized guest. A new command-line option, -passthrough is added. For example, to invoke it for an Ethernet device sitting at PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: -passthrough Ethernet/04:08.0-18 The host driver is to be removed before doing the passthrough. Signed-off-by: Amit Shah <[EMAIL PROTECTED]> --- qemu/Makefile |6 +- qemu/Makefile.target |4 +- qemu/exec.c|1 + qemu/hw/apic.c |2 + qemu/hw/passthrough/neo_pci_tree.h | 44 +++ qemu/hw/passthrough/passthrough.c | 604 qemu/hw/passthrough/passthrough.h | 64 qemu/hw/pc.c |3 + qemu/hw/pci.c |5 + qemu/hw/piix_pci.c |6 + qemu/vl.c |6 + tools/pci_barsize.c| 53 tools/pci_mmio.c | 82 + 13 files changed, 876 insertions(+), 4 deletions(-) create mode 100644 qemu/hw/passthrough/neo_pci_tree.h create mode 100644 qemu/hw/passthrough/passthrough.c create mode 100644 qemu/hw/passthrough/passthrough.h create mode 100644 tools/pci_barsize.c create mode 100644 tools/pci_mmio.c diff --git a/qemu/Makefile b/qemu/Makefile index 053c88c..3e599f3 100644 --- a/qemu/Makefile +++ b/qemu/Makefile @@ -37,7 +37,7 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c block-cow.c block-qco dyngen$(EXESUF): dyngen.c $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^ -clean: +clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS cscope.* *.pod *~ */*~ @@ -88,8 +88,8 @@ endif test speed test2: all $(MAKE) -C tests $@ -TAGS: - etags *.[ch] tests/*.[ch] +TAGS: + etags *.[ch] tests/*.[ch] hw/passthrough/*.[ch] cscope: rm -f ./cscope.* diff --git a/qemu/Makefile.target b/qemu/Makefile.target index 65f449e..9a96011 100644 --- a/qemu/Makefile.target +++ b/qemu/Makefile.target @@ -24,7 +24,7 @@ ifeq ($(TARGET_ARCH), sparc64) TARGET_BASE_ARCH:=sparc endif TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH) -VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/audio +VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/hw/passthrough:$(SRC_PATH)/audio CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH) ifdef CONFIG_DARWIN_USER VPATH+=:$(SRC_PATH)/darwin-user @@ -454,6 +454,8 @@ VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o $(AUDIODRV) VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o VL_OBJS+= usb-uhci.o smbus_eeprom.o vmmouse.o vmport.o vmware_vga.o +# passthrough support +VL_OBJS+= passthrough.o CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE endif ifeq ($(TARGET_BASE_ARCH), ppc) diff --git a/qemu/exec.c b/qemu/exec.c index 3e588d5..7a21ca5 100644 --- a/qemu/exec.c +++ b/qemu/exec.c @@ -2484,6 +2484,7 @@ int cpu_register_io_memory(int io_index, if (io_mem_nb >= IO_MEM_NB_ENTRIES) return -1; io_index = io_mem_nb++; + fprintf(stderr, "iomem index %d out of %d\n", io_index, IO_MEM_NB_ENTRIES); } else { if (io_index >= IO_MEM_NB_ENTRIES) return -1; diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c index 60d31fa..5b1bdf4 100644 --- a/qemu/hw/apic.c +++ b/qemu/hw/apic.c @@ -349,6 +349,7 @@ static void apic_eoi(APICState *s) /* XXX: send the EOI packet to the APIC bus to allow the I/O APIC to set the remote IRR bit for level triggered interrupts. */ apic_update_irq(s); +pt_ack_mirq(isrv); } static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, @@ -1122,6 +1123,7 @@ static void ioapic_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t va } else { s->ioredtbl[index] &= ~0xULL; s->ioredtbl[index] |= val; +pt_set_vector(index, (val << 24) >> 24); } ioapic_service(s); } diff --git a/qemu/hw/passthrough/neo_pci_tree.h b/qemu/hw/passthrough/neo_pci_tree.h new file mode 100644 index 000..79adef9 --- /
Re: [Qemu-devel] [PATCH 1/3] Add args to -cdrom to define where is connected the cdrom
Le jeudi 08 novembre 2007 à 00:32 +0100, Fabrice Bellard a écrit : > Laurent Vivier wrote: > > Thiemo Seufer a écrit : > >> Laurent Vivier wrote: > >>> Daniel P. Berrange a écrit : > On Sun, Oct 28, 2007 at 11:43:33PM +0100, [EMAIL PROTECTED] > wrote: > > From: Laurent Vivier <[EMAIL PROTECTED](none)> > > > > This patch allows to define where is connected the CDROM device (bus, > > unit). > > It extends the "-cdrom" syntax to add these paramaters: > > > > -cdrom file[,if=type][,bus=n][,unit=m] > > > > where "type" defines the interface (by default, "ide") > >"n" defines the bus number (by default 1) > >"m" defines the unit number (by default 0) > Having a separately named arg just for CDROMs was always rather > odd/unhelpful. > I'd suggest that we leave all the -hda,hdb,hdc,-cdrom,-fda,-fdb etc > unchanged > and use the -disk for setting up all types of disks, floppys, > cdroms, etc. It > would just require one extra field for the -disk arg: > -disk file[,if=type][,bus=n][,unit=m][,mode=mode] > where "type" defines the interface. [ide,scsi,fd] (by default, > "ide") > "n" defines the bus number (by default 1) > "m" defines the unit number (by default 0) > "mode" defines one of [disk,floppy,cdrom] > If we ever up able to emulate other types of SCSI / IDE devices > (tape drives, > cdr, dvd perhaps) then the 'mode' can easily be extended to cover them. > >>> I agree with that. And if everyone agrees I can modify patches to do > >>> that... > >> > >> Please go ahead. :-) > > > > Well, it is done... is there someone that can comment them ? > > Or if they are perfect (as usual ;-) ) perhaps it could be included in > > CVS ? > > I had rejected a similar patch in the past, but I agree that a -disk > command line option is needed. > > A few remarks: > > - Add a function in vl.c to add a disk so that all option handlers can > call it instead of doing pstrcpy(); nb_disk++. I agree > - You replaced the constant "2" in many machines by MAX_IDE_BUS. It is > dangerous because each machine has its own constraints. I agree, I'll use MAX_IDE_BUS only for PC. But how can I compute MAX_DISKS if the number of IDE disks vary with target ? For the moment it is the sum of all available MAX_* . Should I take an explicit value like "32" or something like ? > > - Maybe the real option name could be "-drive" to insist on the fact > that a drive can be created without a disk in it ! Any more comments ? I agree, and a drive can be something else like a flash or a tape (in the future...). > - disk_init() should not modify its argument str. Moreover, maybe having > an explicit "file=" argument would be clearer in the case there is no > disk in the drive. I'm not sure I understand correctly this one. For the moment "-disk ," allows to declare a drive without media (an empty CDROM drive, for instance). Do you mean we must use "-drive file=a.img" instead of "-disk a.img" and "-drive file=" instead of "-disk ," > - While modifying the machine init function, you can suppress the > snapshot parameter. OK > - In disk_init(), you should factorize the bdrv_new() and bdrv_open() as > it is the same for all types. OK. Can I use bdrv_set_geometry_hint() and bdrv_set_translation_hint() before the bdrv_open() ? > > - It could be simpler to export an array of structs containg a bdrv, > each one tagged with if, index and bus. Then each machine could call a > function to get the bdrv from the parameters "if", "index" and "bus". > For example, look at the NICInfo structure and do the same with a > structure DriveInfo... OK > If you prefer, you can resubmit a big patch with all the changes. Well, I like to write a lot of little patches ;-) It is easier to review them, isn't it ? But it is as you want. > Regards, > > Fabrice. Thank you for your comments, Laurent signature.asc Description: Ceci est une partie de message numériquement signée
[Qemu-devel] Re: [kvm-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
On Thursday 08 November 2007 01:31:32 Hollis Blanchard wrote: > I'm sorry these comments aren't substantive, but please watch your > whitespace... Hi Hollis, Thanks for going through this. We know about these issues; the userspace is kind of messy since it's collected from various sources and we are urging the people who have done this to provide good patches. These aren't ready yet for inclusion, we've sent them out to get comments on the overall solution for PCI passthrough. > On Wed, 2007-11-07 at 21:45 +0200, Amit Shah wrote: > > diff --git a/qemu/Makefile b/qemu/Makefile > > index 053c88c..3e599f3 100644 > > --- a/qemu/Makefile > > +++ b/qemu/Makefile > > @@ -37,7 +37,7 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c > > block-raw.c block-cow.c block-qco > > dyngen$(EXESUF): dyngen.c > > $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^ > > > > -clean: > > +clean: > > # avoid old build problems by removing potentially incorrect old > > files > > rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h > > op-arm.h opc-arm.h gen-op-arm.h > > rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS cscope.* *.pod *~ > > */*~ > > Extra space. > > > @@ -88,8 +88,8 @@ endif > > test speed test2: all > > $(MAKE) -C tests $@ > > > > -TAGS: > > - etags *.[ch] tests/*.[ch] > > +TAGS: > > + etags *.[ch] tests/*.[ch] hw/passthrough/*.[ch] > > > > cscope: > > rm -f ./cscope.* > > Another extra space. > > > diff --git a/qemu/exec.c b/qemu/exec.c > > index 3e588d5..7a21ca5 100644 > > --- a/qemu/exec.c > > +++ b/qemu/exec.c > > @@ -2484,6 +2484,7 @@ int cpu_register_io_memory(int io_index, > > if (io_mem_nb >= IO_MEM_NB_ENTRIES) > > return -1; > > io_index = io_mem_nb++; > > + fprintf(stderr, "iomem index %d out of %d\n", io_index, > > IO_MEM_NB_ENTRIES); > > } else { > > if (io_index >= IO_MEM_NB_ENTRIES) > > return -1; > > Bad indentation. > > I didn't check the rest of your patches for this, so you should skim > them...
[Qemu-devel] [PATCH 2/2] KVM Userspace: IRQ injection into guest
This kernel module injects IRQs specified on the command line via the passthrough parameter This doesn't handle shared interrupts. These patches don't yet work with the in-kernel apic, so you have to use -no-kvm-irqchip. These will soon be overridden by a new mechanism that utilises the in-kernel apic. Signed-off-by: Amit Shah <[EMAIL PROTECTED]> --- Makefile | 10 ++- irqhook/Kbuild |3 + irqhook/Makefile | 25 ++ irqhook/irqhook_main.c | 217 4 files changed, 251 insertions(+), 4 deletions(-) create mode 100644 irqhook/Kbuild create mode 100644 irqhook/Makefile create mode 100644 irqhook/irqhook_main.c diff --git a/Makefile b/Makefile index 776ff01..4ba6221 100644 --- a/Makefile +++ b/Makefile @@ -5,13 +5,13 @@ DESTDIR= rpmrelease = devel -.PHONY: kernel user libkvm qemu bios clean +.PHONY: kernel irqhook user libkvm qemu bios clean -all: $(if $(WANT_MODULE), kernel) user libkvm qemu +all: $(if $(WANT_MODULE), kernel irqhook) user libkvm qemu kcmd = $(if $(WANT_MODULE),,@\#) -qemu kernel user libkvm: +qemu kernel user irqhook libkvm: $(MAKE) -C $@ qemu: libkvm @@ -42,6 +42,7 @@ install-rpm: install: $(kcmd)make -C kernel DESTDIR="$(DESTDIR)" install + $(kcmd)make -C irqhook DESTDIR="$(DESTDIR)" install make -C libkvm DESTDIR="$(DESTDIR)" install make -C qemu DESTDIR="$(DESTDIR)" install @@ -62,13 +63,14 @@ srpm: tar czf SOURCES/user.tar.gz user tar czf SOURCES/libkvm.tar.gz libkvm tar czf SOURCES/kernel.tar.gz kernel + tar czf SOURCES/irqhook.tar.gz irqhook tar czf SOURCES/scripts.tar.gz scripts cp Makefile configure kvm_stat SOURCES rpmbuild --define="_topdir $$(pwd)" -bs $(tmpspec) $(RM) $(tmpspec) clean: - for i in $(if $(WANT_MODULE), kernel) user libkvm qemu; do \ + for i in $(if $(WANT_MODULE), kernel irqhook) user libkvm qemu; do \ make -C $$i clean; \ done rm -f config.mak user/config.mak diff --git a/irqhook/Kbuild b/irqhook/Kbuild new file mode 100644 index 000..9af75a4 --- /dev/null +++ b/irqhook/Kbuild @@ -0,0 +1,3 @@ +EXTRA_CFLAGS := -I$(src)/include +obj-m := irqhook.o +irqhook-objs := irqhook_main.o diff --git a/irqhook/Makefile b/irqhook/Makefile new file mode 100644 index 000..3b1d851 --- /dev/null +++ b/irqhook/Makefile @@ -0,0 +1,25 @@ +include ../config.mak + +KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR)) + +DESTDIR= + +INSTALLDIR = $(patsubst %/build,%/extra,$(KERNELDIR)) + +rpmrelease = devel + +LINUX = ../linux-2.6 + +all:: + $(MAKE) -C $(KERNELDIR) M=`pwd` "$$@" + +#sync: +# rsync --exclude='*.mod.c' "$(LINUX)"/drivers/irqhook/*.[ch] . + +install: + mkdir -p $(DESTDIR)/$(INSTALLDIR) + cp *.ko $(DESTDIR)/$(INSTALLDIR) + /sbin/depmod -a + +clean: + $(MAKE) -C $(KERNELDIR) M=`pwd` $@ diff --git a/irqhook/irqhook_main.c b/irqhook/irqhook_main.c new file mode 100644 index 000..812b714 --- /dev/null +++ b/irqhook/irqhook_main.c @@ -0,0 +1,217 @@ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define irqh_VERSION "0.0.1" +#define irqh_MODULE_NAME "irqhook" +#define irqh_DRIVER_NAME irqh_MODULE_NAME " HW IRQ hook " irqh_VERSION + +// based on earlier proprietary Tutis code; this modified version goes under GPL +MODULE_AUTHOR("Nir Peleg - Tutis"); +MODULE_DESCRIPTION("IRQ hook driver"); +MODULE_LICENSE("GPL"); + +//#define irqh_DEBUG /* define to enable copious debugging info */ + +#ifdef irqh_DEBUG +#define DPRINTK(fmt, args...) printk("<1>" "%s: " fmt, __FUNCTION__ , ## args) +#else +#define DPRINTK(fmt, args...) +#endif + +#define ERROR(fmt, args...) printk("<1>" "%s: " fmt, __FUNCTION__ , ## args) + +static spinlock_t irqh_lock; +static wait_queue_head_t irqh_proc_list; + +enum {NINTR = 256}; + +static DECLARE_BITMAP(pending, NINTR); +static DECLARE_BITMAP(handled, NINTR); + +#define irqh_on(which, bit)test_bit(bit, which) +#define irqh_set(which, bit) set_bit(bit, which) +#define irqh_clear(which, bit) clear_bit(bit, which) +#define irqh_ffs(which)find_first_bit(which, NINTR) + +static irqreturn_t +irqh_interrupt(int irq, void *p) +{ + unsigned long flags; + + DPRINTK("interrupt: %d\n", irq); + if (!irqh_on(handled, irq)) + return IRQ_HANDLED; + spin_lock_irqsave(&irqh_lock, flags); + irqh_set(pending, irq); + wake_up_interruptible(&irqh_proc_list); + spin_unlock_irqrestore(&irqh_lock, flags); + disable_irq_nosync(irq); + return IRQ_HANDLED; +} + +static ssize_t +irqh_dev_write(struct file *fp, const char *buf, size_t size, loff_t *offp) +{ + int n, device, func, devfn; + char arg[32], *cp, *cp1; + struct pci_dev *pdp = 0; + + DPRINTK("ENTER\n"); + if ((fp->f_mode & FMODE_WRITE) == 0 || s
[Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
This patch introduces support for device passthrough from the host to a paravirtualized guest. A new command-line option, -passthrough is added. For example, to invoke it for an Ethernet device sitting at PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: -passthrough Ethernet/04:08.0-18 The host driver is to be removed before doing the passthrough. Signed-off-by: Amit Shah <[EMAIL PROTECTED]> --- qemu/Makefile |6 +- qemu/Makefile.target |4 +- qemu/exec.c|1 + qemu/hw/apic.c |2 + qemu/hw/passthrough/neo_pci_tree.h | 44 +++ qemu/hw/passthrough/passthrough.c | 604 qemu/hw/passthrough/passthrough.h | 64 qemu/hw/pc.c |3 + qemu/hw/pci.c |5 + qemu/hw/piix_pci.c |6 + qemu/vl.c |6 + tools/pci_barsize.c| 53 tools/pci_mmio.c | 82 + 13 files changed, 876 insertions(+), 4 deletions(-) create mode 100644 qemu/hw/passthrough/neo_pci_tree.h create mode 100644 qemu/hw/passthrough/passthrough.c create mode 100644 qemu/hw/passthrough/passthrough.h create mode 100644 tools/pci_barsize.c create mode 100644 tools/pci_mmio.c diff --git a/qemu/Makefile b/qemu/Makefile index 053c88c..3e599f3 100644 --- a/qemu/Makefile +++ b/qemu/Makefile @@ -37,7 +37,7 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c block-cow.c block-qco dyngen$(EXESUF): dyngen.c $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^ -clean: +clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS cscope.* *.pod *~ */*~ @@ -88,8 +88,8 @@ endif test speed test2: all $(MAKE) -C tests $@ -TAGS: - etags *.[ch] tests/*.[ch] +TAGS: + etags *.[ch] tests/*.[ch] hw/passthrough/*.[ch] cscope: rm -f ./cscope.* diff --git a/qemu/Makefile.target b/qemu/Makefile.target index 65f449e..9a96011 100644 --- a/qemu/Makefile.target +++ b/qemu/Makefile.target @@ -24,7 +24,7 @@ ifeq ($(TARGET_ARCH), sparc64) TARGET_BASE_ARCH:=sparc endif TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH) -VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/audio +VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/hw/passthrough:$(SRC_PATH)/audio CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH) ifdef CONFIG_DARWIN_USER VPATH+=:$(SRC_PATH)/darwin-user @@ -454,6 +454,8 @@ VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o $(AUDIODRV) VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o VL_OBJS+= usb-uhci.o smbus_eeprom.o vmmouse.o vmport.o vmware_vga.o +# passthrough support +VL_OBJS+= passthrough.o CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE endif ifeq ($(TARGET_BASE_ARCH), ppc) diff --git a/qemu/exec.c b/qemu/exec.c index 3e588d5..7a21ca5 100644 --- a/qemu/exec.c +++ b/qemu/exec.c @@ -2484,6 +2484,7 @@ int cpu_register_io_memory(int io_index, if (io_mem_nb >= IO_MEM_NB_ENTRIES) return -1; io_index = io_mem_nb++; + fprintf(stderr, "iomem index %d out of %d\n", io_index, IO_MEM_NB_ENTRIES); } else { if (io_index >= IO_MEM_NB_ENTRIES) return -1; diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c index 60d31fa..5b1bdf4 100644 --- a/qemu/hw/apic.c +++ b/qemu/hw/apic.c @@ -349,6 +349,7 @@ static void apic_eoi(APICState *s) /* XXX: send the EOI packet to the APIC bus to allow the I/O APIC to set the remote IRR bit for level triggered interrupts. */ apic_update_irq(s); +pt_ack_mirq(isrv); } static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask, @@ -1122,6 +1123,7 @@ static void ioapic_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t va } else { s->ioredtbl[index] &= ~0xULL; s->ioredtbl[index] |= val; +pt_set_vector(index, (val << 24) >> 24); } ioapic_service(s); } diff --git a/qemu/hw/passthrough/neo_pci_tree.h b/qemu/hw/passthrough/neo_pci_tree.h new file mode 100644 index 000..79adef9 --- /dev/null +++ b/qemu/hw/passthrough/neo_pci_tree.h @@ -0,0 +1,44 @@ +/* + +Some data structures to save the result of the PCI probing. + +Copyright (c) 2007, Neocleus: Guy Zana, Alex Novik + +**/ + +#ifndef __XC_NEO_PCI_TREE_H__ +#define __XC_NEO_PCI_TREE_H__ + +#include + +typedef __u8 u8; +typedef __u