[Qemu-devel] qemu/hw slavio_serial.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/25 08:48:16 Modified files: hw : slavio_serial.c Log message: Fix buffer mux handling for unconnected serial ports CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_serial.c?cvsroot=qemur1=1.27r2=1.28
[Qemu-devel] qemu/target-sparc cpu.h op_helper.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/25 12:43:10 Modified files: target-sparc : cpu.h op_helper.c Log message: More MMU registers (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemur1=1.58r2=1.59 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.57r2=1.58
[Qemu-devel] qemu/hw iommu.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/25 12:44:09 Modified files: hw : iommu.c Log message: Set initial value of AFSR register properly (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/iommu.c?cvsroot=qemur1=1.19r2=1.20
Re: [Qemu-devel] USB performance Question
Does anyone have a comment about this? It would be interesting to know where the USB development is going as it is extremely promising and the only small obstacle (i.m.o) for full feature device access. The only remaining barrier is speed which should be improved. I can look at the code if someone can point me to where in the sources the USB interface is. thanks [EMAIL PROTECTED] wrote: I could get very complicated USB devices to work under Qemu with Windows as guest, Linux as host. This is pretty amazing development and I must congratulate the Qemu developers. The only problem is the USB speed. I get only about 10kbit/s max! This is measured by downloading a 1MByte scientific camera image. Is this the expected USB speed at the moment or is there anything I can do to improve speed? Thanks
Re: [Qemu-devel] [PATCH] Handle cpu_model in copy_cpu()
On Sat, Nov 24, 2007 at 11:30:28PM +0200, Kirill A. Shutemov wrote: copy_cpu() has been broken since cpu_model added to parameters list of cpu_init(). This patch fix copy_cpu() by storing cpu_model string in CPUState structure on cpu_init and use this string in copy_cpu(). Please excuse my layman's question: why does each cpu need its own copy of the string, and not just point to the same const char *cpu_model? The reason I'm asking is that +char cpu_model_str[32]; might be too short for the feature-reach i386 cpu model string, and that +strcpy(env-cpu_model_str, cpu_model); is not safe when this is mind. Regards, Dan.
[Qemu-devel] [PATCH] Allow setting the vendor_id string with x86's -cpu option
Having AuthenticAMD hard-coded is nice, but allowing the user to impersonate
whatever CPU she wants is even nicer.
Also, an English typo (due to me) is corrected.
Dan.
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -254,8 +254,17 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def-stepping = stepping;
+} else if (!strcmp(featurestr, vendor)) {
+if (strlen(val) != 12) {
+fprintf(stderr, vendor string must be 12 chars long\n);
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def-vendor1 = *(uint32_t *)val;
+x86_cpu_def-vendor2 = *(uint32_t *)(val + 4);
+x86_cpu_def-vendor3 = *(uint32_t *)(val + 8);
} else {
-fprintf(stderr, unregnized feature %s\n, featurestr);
+fprintf(stderr, unrecognized feature %s\n, featurestr);
x86_cpu_def = 0;
goto error;
}
Re: [Qemu-devel] [PATCH] Handle cpu_model in copy_cpu()
On [Sun, 25.11.2007 15:04], Dan Kenigsberg wrote:
On Sat, Nov 24, 2007 at 11:30:28PM +0200, Kirill A. Shutemov wrote:
copy_cpu() has been broken since cpu_model added to parameters list of
cpu_init(). This patch fix copy_cpu() by storing cpu_model string in
CPUState structure on cpu_init and use this string in copy_cpu().
Please excuse my layman's question: why does each cpu need its own copy
of the string, and not just point to the same const char *cpu_model?
It's a good idea. Thanks. Updated patch:
diff --git a/cpu-defs.h b/cpu-defs.h
index 139dca2..5e0f046 100644
--- a/cpu-defs.h
+++ b/cpu-defs.h
@@ -146,6 +146,8 @@ typedef struct CPUTLBEntry {
void *next_cpu; /* next CPU sharing TB cache */ \
int cpu_index; /* CPU index (informative) */\
/* user data */ \
-void *opaque;
+void *opaque; \
+\
+const char *cpu_model_str;
#endif
diff --git a/exec.c b/exec.c
index 046e967..3fe340a 100644
--- a/exec.c
+++ b/exec.c
@@ -1317,9 +1317,7 @@ void cpu_abort(CPUState *env, const char *fmt, ...)
CPUState *cpu_copy(CPUState *env)
{
-#if 0
-/* XXX: broken, must be handled by each CPU */
-CPUState *new_env = cpu_init();
+CPUState *new_env = cpu_init(env-cpu_model_str);
/* preserve chaining and index */
CPUState *next_cpu = new_env-next_cpu;
int cpu_index = new_env-cpu_index;
@@ -1327,9 +1325,6 @@ CPUState *cpu_copy(CPUState *env)
new_env-next_cpu = next_cpu;
new_env-cpu_index = cpu_index;
return new_env;
-#else
-return NULL;
-#endif
}
#if !defined(CONFIG_USER_ONLY)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 038025d..a27602d 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -182,6 +182,7 @@ CPUARMState *cpu_arm_init(const char *cpu_model)
if (!env)
return NULL;
cpu_exec_init(env);
+env-cpu_model_str = cpu_model;
env-cp15.c0_cpuid = id;
cpu_reset(env);
return env;
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 67658e2..968d9dd 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -99,6 +99,7 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
if (!env)
return NULL;
cpu_exec_init(env);
+env-cpu_model_str = cpu_model;
/* init various static tables */
if (!inited) {
diff --git a/target-m68k/helper.c b/target-m68k/helper.c
index f6b0cd6..c639648 100644
--- a/target-m68k/helper.c
+++ b/target-m68k/helper.c
@@ -126,11 +126,13 @@ CPUM68KState *cpu_m68k_init(const char *cpu_model)
return NULL;
cpu_exec_init(env);
+env-cpu_model_str = cpu_model;
+
if (cpu_m68k_set_model(env, cpu_model) 0) {
cpu_m68k_close(env);
return NULL;
}
-
+
cpu_reset(env);
return env;
}
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 55e6290..374eebd 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -6754,6 +6754,7 @@ CPUMIPSState *cpu_mips_init (const char *cpu_model)
env-cpu_model = def;
cpu_exec_init(env);
+env-cpu_model_str = cpu_model;
cpu_reset(env);
return env;
}
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index cb9b778..dbbde12 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -2987,6 +2987,7 @@ CPUPPCState *cpu_ppc_init (const char *cpu_model)
if (!env)
return NULL;
cpu_exec_init(env);
+env-cpu_model_str = cpu_model;
cpu_ppc_register_internal(env, def);
cpu_ppc_reset(env);
return env;
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 1e373ce..a7e46fb 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -3506,6 +3506,7 @@ CPUSPARCState *cpu_sparc_init(const char *cpu_model)
if (!env)
return NULL;
cpu_exec_init(env);
+env-cpu_model_str = cpu_model;
env-version = def-iu_version;
env-fsr = def-fpu_version;
#if !defined(TARGET_SPARC64)
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
Re: [Qemu-devel] USB performance Question
I am in the middle of coding EHCI (USB 2.0) host controller emulation. It is supposed to support faster device speeds (480 Mbit/sec instead of USB 1.1 speeds - 1.5 or 12Mbit/sec). I will post it on the list when it basicly supports simple devices such as disk-on-key. Currently I still have some major problems with the scheduling of async and periodic frame lists. I will check your comment regarding the speed and see what can be done. Anway, if you want to try to solve the issue yourself, the relevant code is in usb-linux.c (Linux host USB redirector) and the USB UHCI/OHCI controller emulations (hw/usb-uhci.c or hw/usb-ohci.c). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 3:01 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Does anyone have a comment about this? It would be interesting to know where the USB development is going as it is extremely promising and the only small obstacle (i.m.o) for full feature device access. The only remaining barrier is speed which should be improved. I can look at the code if someone can point me to where in the sources the USB interface is. thanks [EMAIL PROTECTED] wrote: I could get very complicated USB devices to work under Qemu with Windows as guest, Linux as host. This is pretty amazing development and I must congratulate the Qemu developers. The only problem is the USB speed. I get only about 10kbit/s max! This is measured by downloading a 1MByte scientific camera image. Is this the expected USB speed at the moment or is there anything I can do to improve speed? Thanks
Re: [Qemu-devel] USB performance Question
Thanks Arnon. USB1 works really great even for complex streaming cameras! Although it is just very very slow. As mentioned I only get about 10kbit/s! which is something I dont understand why. I would have expected 1Mbit/s and could live with that. If there are any test you want me to do please dont hesitate. Cant wait for your USB2 implementation. Great effort! Arnon Gilboa wrote: I am in the middle of coding EHCI (USB 2.0) host controller emulation. It is supposed to support faster device speeds (480 Mbit/sec instead of USB 1.1 speeds - 1.5 or 12Mbit/sec). I will post it on the list when it basicly supports simple devices such as disk-on-key. Currently I still have some major problems with the scheduling of async and periodic frame lists. I will check your comment regarding the speed and see what can be done. Anway, if you want to try to solve the issue yourself, the relevant code is in usb-linux.c (Linux host USB redirector) and the USB UHCI/OHCI controller emulations (hw/usb-uhci.c or hw/usb-ohci.c). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 3:01 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Does anyone have a comment about this? It would be interesting to know where the USB development is going as it is extremely promising and the only small obstacle (i.m.o) for full feature device access. The only remaining barrier is speed which should be improved. I can look at the code if someone can point me to where in the sources the USB interface is. thanks [EMAIL PROTECTED] wrote: I could get very complicated USB devices to work under Qemu with Windows as guest, Linux as host. This is pretty amazing development and I must congratulate the Qemu developers. The only problem is the USB speed. I get only about 10kbit/s max! This is measured by downloading a 1MByte scientific camera image. Is this the expected USB speed at the moment or is there anything I can do to improve speed? Thanks
[Qemu-devel] qemu cpu-all.h qemu-tech.texi fpu/softfloat.c f...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/25 18:40:21 Modified files: . : cpu-all.h qemu-tech.texi fpu: softfloat.c softfloat.h target-sparc : cpu.h exec.h fop_template.h op.c op_helper.c op_mem.h translate.c Log message: 128-bit float support for user mode CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.78r2=1.79 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-tech.texi?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.h?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemur1=1.59r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/exec.h?cvsroot=qemur1=1.22r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/fop_template.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.44r2=1.45 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.58r2=1.59 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_mem.h?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.82r2=1.83
[Qemu-devel] qemu/hw mainstone.c omap.c sd.c tsc210x.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/25 18:46:17 Modified files: hw : mainstone.c omap.c sd.c tsc210x.c Log message: Scale TSC2102 touchscreen pressure value more realistically (still could be better). PalmOS 5.2.1 now fully boots. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mainstone.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tsc210x.c?cvsroot=qemur1=1.5r2=1.6
[Qemu-devel] pflash_register question
Hello, I see there are two instances of pflash_register() , one for pflash_cfi01.c and the other in pflash_cfi02.c. In order to get the proper one, I assume we use link order? - Armin
Re: [Qemu-devel] pflash_register question
On 25/11/2007, Armin [EMAIL PROTECTED] wrote: I see there are two instances of pflash_register() , one for pflash_cfi01.c and the other in pflash_cfi02.c. In order to get the proper one, I assume we use link order? No, ofcourse we will need to rename one of them. To be honest, I missed the fact that the functions collide when I merged pflash_cfi01.c. Regards
[Qemu-devel] Mainstone re-org
I though of this after my last patch, so my apologizes for the extra work.
I pulled the FPGA code out since it will be used by many other devices
on the Mainstone. I do not want to bloat the main file.
I am working on flash support now.
feedback and comments welcome.
Kind regards,
- Armin
Index: qemu/hw/mainstone.c
===
--- qemu.orig/hw/mainstone.c
+++ qemu/hw/mainstone.c
@@ -14,245 +14,7 @@
#include net.h
#include devices.h
#include boards.h
-
-#define MST_ETH_PHYS 0x1300
-#define MST_FPGA_PHYS 0x0800
-
-/* Mainstone FPGA for extern irqs */
-#define FPGA_GPIO_PIN 0
-#define MST_NUM_IRQS 16
-#define MST_BASE MST_FPGA_PHYS
-#define MST_LEDDAT1 0x10
-#define MST_LEDDAT2 0x14
-#define MST_LEDCTRL 0x40
-#define MST_GPSWR 0x60
-#define MST_MSCWR1 0x80
-#define MST_MSCWR2 0x84
-#define MST_MSCWR3 0x88
-#define MST_MSCRD 0x90
-#define MST_INTMSKENA 0xc0
-#define MST_INTSETCLR 0xd0
-#define MST_PCMCIA0 0xe0
-#define MST_PCMCIA1 0xe4
-
-/* IRQ definitions */
-#define ETHERNET_IRQ 3
-
-typedef struct mst_irq_state {
-target_phys_addr_t target_base;
-qemu_irq *parent;
-qemu_irq *pins;
-
-uint32_t prev_level;
-uint32_t leddat1;
-uint32_t leddat2;
-uint32_t ledctrl;
-uint32_t gpswr;
-uint32_t mscwr1;
-uint32_t mscwr2;
-uint32_t mscwr3;
-uint32_t mscrd;
-uint32_t intmskena;
-uint32_t intsetclr;
-uint32_t pcmcia0;
-uint32_t pcmcia1;
-} mst_irq_state;
-
-static void
-mst_fpga_update_gpio(mst_irq_state *s)
-{
-uint32_t level, diff;
-int bit;
-level = s-prev_level ^ s-intsetclr;
-
-for (diff = s-prev_level ^ level; diff; diff ^= 1 bit) {
-bit = ffs(diff) - 1;
-qemu_set_irq(s-pins[bit], (level bit) 1 );
-}
-s-prev_level = level;
-}
-
-static void
-mst_fpga_set_irq(void *opaque, int irq, int level)
-{
-mst_irq_state *s = (mst_irq_state *)opaque;
-
-if (level)
-s-prev_level |= 1u irq;
-else
-s-prev_level = ~(1u irq);
-
-if(s-intmskena (1u irq)) {
-s-intsetclr = 1u irq;
-qemu_set_irq(s-parent[0], level);
-}
-}
-
-static uint32_t
-mst_fpga_readb(void *opaque, target_phys_addr_t addr)
-{
-mst_irq_state *s = (mst_irq_state *) opaque;
-addr -= s-target_base;
-
-switch (addr) {
-case MST_LEDDAT1:
-return s-leddat1;
-case MST_LEDDAT2:
-return s-leddat2;
-case MST_LEDCTRL:
-return s-ledctrl;
-case MST_GPSWR:
-return s-gpswr;
-case MST_MSCWR1:
-return s-mscwr1;
-case MST_MSCWR2:
-return s-mscwr2;
-case MST_MSCWR3:
-return s-mscwr3;
-case MST_MSCRD:
-return s-mscrd;
-case MST_INTMSKENA:
-return s-intmskena;
-case MST_INTSETCLR:
-return s-intsetclr;
-case MST_PCMCIA0:
-return s-pcmcia0;
-case MST_PCMCIA1:
-return s-pcmcia1;
-default:
-printf(Mainstone - mst_fpga_readb: Bad register offset
-REG_FMT \n, addr);
-}
-return 0;
-}
-
-static void
-mst_fpga_writeb(void *opaque, target_phys_addr_t addr, uint32_t value)
-{
-mst_irq_state *s = (mst_irq_state *) opaque;
-addr -= s-target_base;
-value = 0x;
-
-switch (addr) {
-case MST_LEDDAT1:
-s-leddat1 = value;
-break;
-case MST_LEDDAT2:
-s-leddat2 = value;
-break;
-case MST_LEDCTRL:
-s-ledctrl = value;
-break;
-case MST_GPSWR:
-s-gpswr = value;
-break;
-case MST_MSCWR1:
-s-mscwr1 = value;
-break;
-case MST_MSCWR2:
-s-mscwr2 = value;
-break;
-case MST_MSCWR3:
-s-mscwr3 = value;
-break;
-case MST_MSCRD:
-s-mscrd = value;
-break;
-case MST_INTMSKENA: /* Mask interupt */
-s-intmskena = (value 0xFEEFF);
-mst_fpga_update_gpio(s);
-break;
-case MST_INTSETCLR: /* clear or set interrupt */
-s-intsetclr = (value 0xFEEFF);
-break;
-case MST_PCMCIA0:
-s-pcmcia0 = value;
-break;
-case MST_PCMCIA1:
-s-pcmcia1 = value;
-break;
-default:
-printf(Mainstone - mst_fpga_writeb: Bad register offset
-REG_FMT \n, addr);
-}
-}
-
-CPUReadMemoryFunc *mst_fpga_readfn[] = {
-mst_fpga_readb,
-mst_fpga_readb,
-mst_fpga_readb,
-};
-CPUWriteMemoryFunc *mst_fpga_writefn[] = {
-mst_fpga_writeb,
-mst_fpga_writeb,
-mst_fpga_writeb,
-};
-
-static void
-mst_fpga_save(QEMUFile *f, void *opaque)
-{
-struct mst_irq_state *s = (mst_irq_state *) opaque;
-
-qemu_put_be32s(f, s-prev_level);
-qemu_put_be32s(f, s-leddat1);
-qemu_put_be32s(f, s-leddat2);
-qemu_put_be32s(f, s-ledctrl);
-qemu_put_be32s(f, s-gpswr);
-qemu_put_be32s(f, s-mscwr1);
-qemu_put_be32s(f, s-mscwr2);
-qemu_put_be32s(f, s-mscwr3);
-qemu_put_be32s(f, s-mscrd);
-
Re: [Qemu-devel] pflash_register question
andrzej zaborowski wrote: On 25/11/2007, Armin [EMAIL PROTECTED] wrote: I see there are two instances of pflash_register() , one for pflash_cfi01.c and the other in pflash_cfi02.c. In order to get the proper one, I assume we use link order? No, ofcourse we will need to rename one of them. To be honest, I missed the fact that the functions collide when I merged pflash_cfi01.c. Regards Many thanks
[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/25 20:27:36 Modified files: target-sparc : translate.c Log message: Fix floating point register decoding CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.83r2=1.84
Re: [Qemu-devel] [PATCH][UPDATE3] Add -drive parameter
On 11/19/07, Laurent Vivier [EMAIL PROTECTED] wrote: This is an update with Qemu CVS tree and comments from Blue Swirl. This patch introduces a new parameter allowing to define drives. The new parameter is -drive: -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][index=i][,cyls=c,heads=h,secs=s[,trans=t]][snapshot=on|off] where: file is the disk image type is the interface type (ide, scsi, sd, mtd, floppy, pflash) n is the bus number of the given type m is the unit number on the given bus d is the type of the media (disk, cdrom) c,h,s,t are the parameters usually given by -hdachs snapshot allows to enable or not the snapshot for this disk i is an index number within the given type (replace bus,unit) -cdrom file is an alias for -drive file=file,index=2,media=cdrom -hda file is an alias for -drive file=file,index=0,media=disk -hdb file is an alias for -drive file=file,index=1,media=disk -hdc file is an alias for -drive file=file,index=2,media=disk -hdd file is an alias for -drive file=file,index=3,media=disk -hda file -hdachs a,b,c is an alias for -drive file=file,index=0,cyls=a,heads=b,secs=c You can also define a cdrom on the slace of ide0 with: -drive file=file,if=ide,index=1,media=cdrom You can define an empty cdrom: -drive if=ide,index=1,media=cdrom -drive file=file,if=scsi,bus=0,unit=6 allows to connect the disk image file to the scsi bus 0 with the unit id 6. if there is no SCSI disk, the SCSI interface is not created. It also defines the default interface type to scsi for targets realview, SS-5, SS-10, versatilepb, versatileab to keep old behavior, where -hda is a SCSI disk. -fda file is an alias for -drive file=file,index=0,if=floppy -fdb file is an alias for -drive file=file,index=1,if=floppy -pflash file is an alias for -drive file=file,if=pflash -mtdblock file is an alias for -drive file=file,if=mtd -sd file becomes the alias of -drive file=file,if=sd -drive file=a -drive file=b will be interpreted like -hda a -hdb b Any objections to committing this patch? To me it looks fine, but I have tested only Sparc.
