Re: [Qemu-devel] time for 0.8.3/0.9?
I agree. There will be a new release in January. Fabrice. Hetz Ben Hamo wrote: Hi, The last release of QEMU was 0.8.2 from 6 months ago, Since then, quite a lot of features has been added to CVS and lots of things were fixed.. So I was wondering, isn't it time to start prepare for a new release? (I think it should be called 0.9.0, fabrice will probably disagree :) ). Thanks, Hetz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add -option-rom option to allow loading of PCI option ROMs
Hi,
OK for the -option-rom option. Later it would be better to handle it at
the NIC level, but it is more complicated (some BIOS patches would be
needed to remap the PCI ROM at the right address for example).
I think the -boot n option should be merged in QEMU too. Some people
need it to make tests.
Regarding VMI, I began some work in this area with kqemu but I did not
manage to find time to finish it (VMI in QEMU would enable to run Linux
VMs with performance levels close to Xen at the expense of a patched
kernel).
Regards,
Fabrice.
Anthony Liguori wrote:
Howdy,
The following patch adds an -option-rom option to allow loading of PCI
option ROMs. This is useful for loading things like etherboot or VMI.
For instance, using an etherboot ROM[1] from http://rom-o-matic.net/,
one can use the following command line to PXE boot QEMU:
qemu -hda ~/mydisk.img -option-rom ~/eb-5.4.2-winbond940.zrom
This is also useful for loading a VMI option ROM for experimenting with
paravirtualization. Not terribly useful ATM of course.
BTW, I have another patch that would add the etherboot ROMs to the QEMU
distribution for all the NICs and then plumb up -boot n to allow PXE
booting. Is there any interest in a patch like this? This would
increase the QEMU distribution size by 96k.
[1]
http://rom-o-matic.net/5.4.2/build.php?version=5.4.2F=arch=i386nic=ns830:winbond940%20--%20[0x1050,0x0940]ofmt=Binary%20ROM%20Image(.zrom)A=Get%20ROM
Regards,
Anthony Liguori
diff -r 0a200f17f93e hw/pc.c
--- a/hw/pc.c Sat Dec 23 16:28:52 2006 -0600
+++ b/hw/pc.c Sat Dec 23 16:28:54 2006 -0600
@@ -451,7 +451,7 @@ static void pc_init1(int ram_size, int v
{
char buf[1024];
int ret, linux_boot, initrd_size, i;
-unsigned long bios_offset, vga_bios_offset;
+unsigned long bios_offset, vga_bios_offset, option_rom_offset;
int bios_size, isa_bios_size;
PCIBus *pci_bus;
int piix3_devfn = -1;
@@ -518,6 +518,23 @@ static void pc_init1(int ram_size, int v
cpu_register_physical_memory(0x10 - isa_bios_size,
isa_bios_size,
(bios_offset + bios_size - isa_bios_size) | IO_MEM_ROM);
+
+option_rom_offset = 0;
+for (i = 0; i nb_option_roms; i++) {
+ int offset = bios_offset + bios_size + option_rom_offset;
+ int size;
+
+ size = load_image(option_rom[i], phys_ram_base + offset);
+ if ((size + option_rom_offset) 0x1) {
+ fprintf(stderr, Too many option ROMS\n);
+ exit(1);
+ }
+ cpu_register_physical_memory(0xd + option_rom_offset,
+size, offset | IO_MEM_ROM);
+ option_rom_offset += size + 2047;
+ option_rom_offset -= (option_rom_offset % 2048);
+}
+
/* map all the bios at the top of memory */
cpu_register_physical_memory((uint32_t)(-bios_size),
bios_size, bios_offset | IO_MEM_ROM);
diff -r 0a200f17f93e qemu-doc.texi
--- a/qemu-doc.texi Sat Dec 23 16:28:52 2006 -0600
+++ b/qemu-doc.texi Sat Dec 23 16:28:54 2006 -0600
@@ -325,6 +325,10 @@ Use it when installing Windows 2000 to a
Use it when installing Windows 2000 to avoid a disk full bug. After
Windows 2000 is installed, you no longer need this option (this option
slows down the IDE transfers).
+
[EMAIL PROTECTED] -option-rom file
+Load the contents of file as an option ROM. This option is useful to load
+things like EtherBoot.
@end table
diff -r 0a200f17f93e vl.c
--- a/vl.c Sat Dec 23 16:28:52 2006 -0600
+++ b/vl.c Sat Dec 23 16:29:15 2006 -0600
@@ -169,6 +169,8 @@ int fd_bootchk = 1;
int fd_bootchk = 1;
int no_reboot = 0;
int daemonize = 0;
+const char *option_rom[MAX_OPTION_ROMS];
+int nb_option_roms;
/***/
/* x86 ISA bus support */
@@ -6213,6 +6215,7 @@ void help(void)
#ifndef _WIN32
-daemonize daemonize QEMU after initializing\n
#endif
+ -option-rom rom load a file, rom, into the option ROM space\n
\n
During emulation, the following keys are useful:\n
ctrl-alt-f toggle full screen\n
@@ -6295,6 +6298,7 @@ enum {
QEMU_OPTION_no_reboot,
QEMU_OPTION_daemonize,
QEMU_OPTION_disk,
+QEMU_OPTION_option_rom,
};
typedef struct QEMUOption {
@@ -6377,6 +6381,7 @@ const QEMUOption qemu_options[] = {
{ no-acpi, 0, QEMU_OPTION_no_acpi },
{ no-reboot, 0, QEMU_OPTION_no_reboot },
{ daemonize, 0, QEMU_OPTION_daemonize },
+{ option-rom, HAS_ARG, QEMU_OPTION_option_rom },
{ NULL },
};
@@ -7130,6 +7135,14 @@ int main(int argc, char **argv)
case QEMU_OPTION_daemonize:
daemonize = 1;
break;
+ case QEMU_OPTION_option_rom:
+ if (nb_option_roms = MAX_OPTION_ROMS) {
+
Re: [Qemu-devel] USB EHCI development nearing completion
Another point is that I won't accept a GPL license for such a device. LGPL or BSD would be better. Regards, Fabrice. Hetz Ben Hamo wrote: Hi Mark, Well, there aren't any written rules but most people who contribute sends some proof of concept diff'ed patch (appliable to QEMU CVS for example) (you can look at the experimental 3D patch few weeks ago), and then the talks begins, while others would look how portable your code to other platforms/OS's.. Thanks, Hetz On 12/24/06, Mark B [EMAIL PROTECTED] wrote: Dear list, Just a quick note to let you know I have almost finished an implementation of an EHCI host controller for USB (usb-ehci.c) for qemu. I am testing with an XP guest and so far I have a mass storage flash key, a mouse and a tablet working. I haven't yet implemented isochronous or split transactions though. It doesn't do companion controller hand-offs for low or full speed devices either but Windows XP doesn't mind that I am attaching low/full speed devices through EHCI (I believe Linux guests won't like this). I have asked the company I am working for to give me permission to GPL the module and so far they are agreeable. So I am planning to clean up and have an initial version for check in early in the new year. If anyone has any inputs, please do let me know. I'm new to qemu development so am not sure of checkin etiquette, etc. Pointers in that regard appreciated too. Cheers, Mark ___ 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] FC6 compat compiler fix
On 12/8/06, Jason Wessel [EMAIL PROTECTED] wrote: When using the gcc34 compiler in FC6 QEMU will not build. It seems that linux/compiler.h is not actually used for anything, as it continues to build fine on other linux varients. Don't know if compiler.h is needed or not, but I got it to compile using ./configure --cc=gcc34 -I/usr/src/kernels/$(uname -r)-$(uname -p)/include ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] x86_64 problems Opensuse 10.2 - some results during my tests
Doing some more tests with Qemu and 64bit support gives the following picture: I always boot the Opensuse 10.2 64bit installation DVD. If I switch off kqemu completely with the -no-kqemu option the system installation starts, albeit slow :-) . The tests with only user mode kqemu enabled (no -kernel-kqemu option specified) lead to crashes: After the first screen pops up I switch to VESA mode. The kernel starts and then crashes during loading basic drivers (see below). I also tried with std-vga mode, same behavior. Also other resolutions didn't change the behavior (except that they show splash screens). Using Cirrus emulation: [EMAIL PROTECTED]:~/opensuse qemu-system-x86_64 -hda suse10.2.img -m 384 -cdrom openSUSE-10.2-GM-DVD-x86_64.iso -boot d RAX=2b5bd3959a00 RBX=7fffd7a15b00 RCX=0017 RDX=0600 RSI= RDI=2b5bd3959a00 RBP=7fffd7a15d60 RSP=7fffd7a15a88 R8 =0600 R9 =2b5bd32afbe0 R10=0812 R11=00010206 R12=2b5bd30b19b8 R13=2b5bd3959a00 R14=7fffd7a15e28 R15=0002 RIP=2b5bd30a7dbe RFL=00010206 [-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES = CS =0033 00affa00 SS =002b 00cff200 DS = FS = GS = LDT= 8000 TR =0040 810001006000 206f 8900 GDT= 805d2000 0080 IDT= 8052a000 0fff CR0=8005003b CR2=2b5bd3959a00 CR3=1626e000 CR4=06e0 Unsupported return value: 0x crashed during loading basic drivers ... (using VESA resolution, standard installation) If I use -kernel-kqemu it seems that Qemu goes into a loop. At least it burns all available CPU for a long time until I stop/kill Qemu. Regards, Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] PPC32 Trace Exception and Trap instruction
Please add this patch to CVS.
The patch has two purposes:
1) The NIP needs to be updated for a tw instruction.
I found that when executing protected mode traps
the PC was always set to the begining of the code
generation block instead of the instruction the trap
occurred on.
The usual PPC breakpoint instruction is:
7d 82 10 08 twger2,r2 (Trap when rA = rB)
2) Single stepping was fixed up earlier in the year
for using a debugger connected to the QEMU
gdb stub. Now it is enabled for connecting a
runtime single stepping with the trace trap so you
can use ptrace() or even debug KGDB.
signed-off-by: [EMAIL PROTECTED]
Thanks,
Jason.
Index: qemu/target-ppc/helper.c
===
--- qemu.orig/target-ppc/helper.c
+++ qemu/target-ppc/helper.c
@@ -1113,8 +1113,6 @@ void do_interrupt (CPUState *env)
}
goto store_next;
case EXCP_TRACE: /* 0x0D00 */
-/* XXX: TODO */
-cpu_abort(env, Trace exception is not implemented yet !\n);
goto store_next;
case EXCP_PERF: /* 0x0F00 */
/* XXX: TODO */
Index: qemu/target-ppc/translate.c
===
--- qemu.orig/target-ppc/translate.c
+++ qemu/target-ppc/translate.c
@@ -1956,6 +1956,8 @@ GEN_HANDLER(tw, 0x1F, 0x04, 0xFF, 0x
{
gen_op_load_gpr_T0(rA(ctx-opcode));
gen_op_load_gpr_T1(rB(ctx-opcode));
+/* Update the nip since this might generate a trap exception */
+gen_op_update_nip(ctx-nip);
gen_op_tw(TO(ctx-opcode));
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] PPC32 Trace Exception and Trap instruction
Excellent, I had encountered that bug earlier on when trying to debug
using workbench.
Are you guys developing a BSP for qemu?
I have a partially working one.
Ely Soto
Jason Wessel [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/27/2006 11:05 AM
Please respond to
qemu-devel@nongnu.org
To
qemu-devel@nongnu.org
cc
Subject
[Qemu-devel] [PATCH] PPC32 Trace Exception and Trap instruction
Please add this patch to CVS.
The patch has two purposes:
1) The NIP needs to be updated for a tw instruction.
I found that when executing protected mode traps
the PC was always set to the begining of the code
generation block instead of the instruction the trap
occurred on.
The usual PPC breakpoint instruction is:
7d 82 10 08 twger2,r2 (Trap when rA = rB)
2) Single stepping was fixed up earlier in the year
for using a debugger connected to the QEMU
gdb stub. Now it is enabled for connecting a
runtime single stepping with the trace trap so you
can use ptrace() or even debug KGDB.
signed-off-by: [EMAIL PROTECTED]
Thanks,
Jason.
Index: qemu/target-ppc/helper.c
===
--- qemu.orig/target-ppc/helper.c
+++ qemu/target-ppc/helper.c
@@ -1113,8 +1113,6 @@ void do_interrupt (CPUState *env)
}
goto store_next;
case EXCP_TRACE: /* 0x0D00 */
-/* XXX: TODO */
-cpu_abort(env, Trace exception is not implemented yet !\n);
goto store_next;
case EXCP_PERF: /* 0x0F00 */
/* XXX: TODO */
Index: qemu/target-ppc/translate.c
===
--- qemu.orig/target-ppc/translate.c
+++ qemu/target-ppc/translate.c
@@ -1956,6 +1956,8 @@ GEN_HANDLER(tw, 0x1F, 0x04, 0xFF, 0x
{
gen_op_load_gpr_T0(rA(ctx-opcode));
gen_op_load_gpr_T1(rB(ctx-opcode));
+/* Update the nip since this might generate a trap exception */
+gen_op_update_nip(ctx-nip);
gen_op_tw(TO(ctx-opcode));
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
-
Notice: This e-mail is intended solely for use of the individual
or entity to which it is addressed and may contain information that
is proprietary, privileged and exempt from disclosure under
applicable law. If the reader is not the intended recipient or
agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly
prohibited. This communication may also contain data subject to
U.S. export laws. If so, that data subject to the International
Traffic in Arms Regulation cannot be disseminated, distributed or
copied to foreign nationals, residing in the U.S. or abroad, absent
the express prior approval of the U.S. Department of State. If
you have received this communication in error, please notify the
sender by reply e-mail and destroy the e-mail message and any
physical copies made of the communication. Thank you.___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu block-raw.c block.c block_int.h qemu-doc.t...
Fabrice, Quick question about this patch (August 19, 2006) The ENOMEDIUM variable is dummy'd up for Windows in vl.h. I found that Solaris doesn't have an ENOMEDIUM variable, and I've been able to get block.c to compile correctly by adding this to vl.h. Before I go submitting anything, I just wanted to understand if I was heading in the right direction. thanks, Ben Fabrice Bellard [EMAIL PROTECTED] wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Fabrice Bellard bellard 06/08/19 11:45:59 Modified files: . : block-raw.c block.c block_int.h qemu-doc.texi vl.h Log message: better support of host drives CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.33r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/block_int.h?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.103r2=1.104 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.142r2=1.143 ___ 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] Add -option-rom option to allow loading of PCI option ROMs
Fabrice Bellard wrote: Hi, OK for the -option-rom option. Later it would be better to handle it at the NIC level, but it is more complicated (some BIOS patches would be needed to remap the PCI ROM at the right address for example). Ok. I think the -boot n option should be merged in QEMU too. Some people need it to make tests. Okay, I'll post that patch. Regarding VMI, I began some work in this area with kqemu but I did not manage to find time to finish it (VMI in QEMU would enable to run Linux VMs with performance levels close to Xen at the expense of a patched kernel). I had a VMI ROM working with an older version of VMI. I've got some time this week so I've been trying to do the same thing with the newer VMI spec. I'd like to at least get a pass through ROM working and then start playing around with stuff like moving some of the device emulation into the ROM. This would be most useful for something like KVM where the PIO latency is a major bottleneck. Eventually, it would be nice to use it to run the guest in ring 1 on bare metal of course. I do agree that with VMI QEMU should be competitive with Xen. Regards, Anthony Liguori Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add -boot n option for x86 using PXE
Howdy,
The following patch enables -boot n for x86 using etherboot PXE ROMs.
It depends on my previous -option-rom patch.
Essentially, if -boot n is specified, the set of NICs is searched and
the patch looks for a ROM named pxe-model.bin in the BIOS path. When
one is found, it is added as an option rom.
Besides applying this patch, three ROMs will have to be added to
pc-bios/. I'd suggest getting them from http://www.rom-o-matic.net.
You'll need ROMs for:
pcnet32:pcnet32 -- [0x1022,0x2000]
ns8390:winbond940 -- [0x1050,0x0940]
rtl8139:rtl8139 -- [0x10ec,0x8139]
And they should be named:
pxe-pcnet.bin
pxe-ne2k_pci.bin
pxe-rtl8139.bin
Right now, I have it limited to TARGET_I386 as I'm not sure whether
other platforms support PXE booting. I also think this is a little
hacky so if anyone has a better suggestion I'd appreciate hearing it.
Regards,
Anthony Liguori
diff -r a46a54f7808d Makefile
--- a/Makefile Sat Dec 23 16:29:19 2006 -0600
+++ b/Makefile Sat Dec 23 16:29:21 2006 -0600
@@ -79,7 +79,8 @@ install: all $(if $(BUILD_DOCS),install-
$(INSTALL) -m 755 -s $(TOOLS) $(DESTDIR)$(bindir)
mkdir -p $(DESTDIR)$(datadir)
for x in bios.bin vgabios.bin vgabios-cirrus.bin ppc_rom.bin \
- video.x openbios-sparc32 linux_boot.bin; do \
+ video.x openbios-sparc32 linux_boot.bin pxe-ne2k_pci.bin \
+ pxe-rtl8139.bin pxe-pcnet.bin; do \
$(INSTALL) -m 644 $(SRC_PATH)/pc-bios/$$x $(DESTDIR)$(datadir); \
done
ifndef CONFIG_WIN32
diff -r a46a54f7808d pc-bios/README
--- a/pc-bios/README Sat Dec 23 16:29:19 2006 -0600
+++ b/pc-bios/README Sat Dec 23 16:29:21 2006 -0600
@@ -14,3 +14,9 @@
- OpenBIOS (http://www.openbios.org/) is a free (GPL v2) portable
firmware implementation. The goal is to implement a 100% IEEE
1275-1994 (referred to as Open Firmware) compliant firmware.
+
+- The PXE roms come from Rom-o-Matic etherboot 5.4.2.
+ pcnet32:pcnet32 -- [0x1022,0x2000]
+ ns8390:winbond940 -- [0x1050,0x0940]
+ rtl8139:rtl8139 -- [0x10ec,0x8139]
+ http://rom-o-matic.net/
diff -r a46a54f7808d qemu-doc.texi
--- a/qemu-doc.texi Sat Dec 23 16:29:19 2006 -0600
+++ b/qemu-doc.texi Sat Dec 23 16:29:21 2006 -0600
@@ -219,9 +219,9 @@ Use @var{file} as CD-ROM image (you cann
@option{-cdrom} at the same time). You can use the host CD-ROM by
using @file{/dev/cdrom} as filename (@pxref{host_drives}).
[EMAIL PROTECTED] -boot [a|c|d]
-Boot on floppy (a), hard disk (c) or CD-ROM (d). Hard disk boot is
-the default.
[EMAIL PROTECTED] -boot [a|c|d|n]
+Boot on floppy (a), hard disk (c), CD-ROM (d), or Etherboot (n). Hard disk boot
+is the default.
@item -disk ide,img=file[,hdx=a..dd][,type=disk|cdrom]
Use @var{file} as the IDE disk/CD-ROM image. The defaults are: hdx=a,type=disk
diff -r a46a54f7808d vl.c
--- a/vl.c Sat Dec 23 16:29:19 2006 -0600
+++ b/vl.c Sat Dec 23 16:29:52 2006 -0600
@@ -6111,7 +6111,7 @@ void help(void)
-hda/-hdb file use 'file' as IDE hard disk 0/1 image\n
-hdc/-hdd file use 'file' as IDE hard disk 2/3 image\n
-cdrom file use 'file' as IDE cdrom image (cdrom is ide1 master)\n
- -boot [a|c|d] boot on floppy (a), hard disk (c) or CD-ROM (d)\n
+ -boot [a|c|d|n] boot on floppy (a), hard disk (c), CD-ROM (d), or network (n)\n
-disk ide,img=file[,hdx=a..dd][,type=disk|cdrom] \n
defaults are: hdx=a,type=disk \n
-disk scsi,img=file[,sdx=a..g][,type=disk|cdrom][,id=n] \n
@@ -6910,7 +6910,7 @@ int main(int argc, char **argv)
case QEMU_OPTION_boot:
boot_device = optarg[0];
if (boot_device != 'a'
-#ifdef TARGET_SPARC
+#if defined(TARGET_SPARC) || defined(TARGET_I386)
// Network boot
boot_device != 'n'
#endif
@@ -7231,6 +7231,28 @@ int main(int argc, char **argv)
exit(1);
}
+#ifdef TARGET_I386
+if (boot_device == 'n') {
+ for (i = 0; i nb_nics; i++) {
+ const char *model = nd_table[i].model;
+ char buf[1024];
+ if (model == NULL)
+ model = ne2k_pci;
+ snprintf(buf, sizeof(buf), %s/pxe-%s.bin, bios_dir, model);
+ if (get_image_size(buf) 0) {
+ option_rom[nb_option_roms] = strdup(buf);
+ nb_option_roms++;
+ break;
+ }
+ }
+ if (i == nb_nics) {
+ fprintf(stderr, No valid PXE rom found for network device\n);
+ exit(1);
+ }
+ boot_device = 'c'; /* to prevent confusion by the BIOS */
+}
+#endif
+
/* init the memory */
phys_ram_size = ram_size + vga_ram_size + bios_size;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] USB EHCI development nearing completion
Thank you Fabrice and co. LGPL or BSD should be fine - I don't have any preference on the license. I could not find the experimental 3D patch - it seems to have expired. But I uploaded a diff patch anyway to 4shared at this location: http://www.4shared.com/file/7986451/d1222873/ehci.html This is an early proof of concept with a good bit of tidying up yet to be done. It is not yet for public release either. But of course comments and other feedback are welcome. Mark -Original Message- From: Fabrice Bellard [mailto:[EMAIL PROTECTED] Sent: 27 December 2006 13:39 To: qemu-devel@nongnu.org Cc: [EMAIL PROTECTED] Subject: Re: [Qemu-devel] USB EHCI development nearing completion Another point is that I won't accept a GPL license for such a device. LGPL or BSD would be better. Regards, Fabrice. Hetz Ben Hamo wrote: Hi Mark, Well, there aren't any written rules but most people who contribute sends some proof of concept diff'ed patch (appliable to QEMU CVS for example) (you can look at the experimental 3D patch few weeks ago), and then the talks begins, while others would look how portable your code to other platforms/OS's.. Thanks, Hetz On 12/24/06, Mark B [EMAIL PROTECTED] wrote: Dear list, Just a quick note to let you know I have almost finished an implementation of an EHCI host controller for USB (usb-ehci.c) for qemu. I am testing with an XP guest and so far I have a mass storage flash key, a mouse and a tablet working. I haven't yet implemented isochronous or split transactions though. It doesn't do companion controller hand-offs for low or full speed devices either but Windows XP doesn't mind that I am attaching low/full speed devices through EHCI (I believe Linux guests won't like this). I have asked the company I am working for to give me permission to GPL the module and so far they are agreeable. So I am planning to clean up and have an initial version for check in early in the new year. If anyone has any inputs, please do let me know. I'm new to qemu development so am not sure of checkin etiquette, etc. Pointers in that regard appreciated too. Cheers, Mark ___ 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] USB EHCI development nearing completion
On Wednesday 27 December 2006 21:21, Mark B wrote: Thank you Fabrice and co. LGPL or BSD should be fine - I don't have any preference on the license. I could not find the experimental 3D patch - it seems to have expired. But I uploaded a diff patch anyway to 4shared at this location: http://www.4shared.com/file/7986451/d1222873/ehci.html This is an early proof of concept with a good bit of tidying up yet to be done. It is not yet for public release either. But of course comments and other feedback are welcome. Have you looked at Chromium (http://chromium.sourceforge.net/) It looks like what they've already achieved what you're trying to implement. It just needs a qemu specific transport implementation. It already has multiple transport backends to support TCP/IP and FiberChannel. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] boot a preinstalled winxp on linux/x86: writing a patch...
hi all, I tried to boot my preinstalled winxp with # qemu -boot c -hda /dev/hda that's what happens: - qemu load grub, and I select to boot winxp (grub says chainloader +1, then boot) - qemu starts to load winxp, with a winxp boot screen - qemu fails and reboots it seems qemu stops loading winxp when /dev/hda ends and /dev/hda1 starts. I could build a patch to fix it, but before start studing qemu source, I'd like to ear from you - yes, if it was easy you guru already would have done it! tia, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
