Re: [Qemu-devel] QEMU/pc and scsi disks
Anthony Liguori wrote: 1. Any option should be settable either in the config file or command line. In other words, the user should not be forced to use a config file. This is useful for management programs who keep all options in an internal database, and for users who can experiment via a ^P edit edit edit . I think we should still provide the ability to set the most common options via the command line. I'm also fine with specifying single options on the command line. I suspect though that being able to do -config - is more useful for management tools than building large strings of command line options. Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And for migration, you have to regenerate it, since some options may have changed (cdrom media). Of course the config file is very useful for a user maintaining a few virtual machines on their own, but when qemu is part of a longer food chain, I think it's just a complication. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add -name option
Anthony Liguori wrote:
This option helps differentiate between guests when running more than
one instance of QEMU. It adds a string to the SDL window title and to
the VNC server title.
Having a name associated with a guest is also terribly useful for
management tools as it gives a standard way to identify guests to the
user.
-vnc_write_u32(vs, 4);
-vnc_write(vs, "QEMU", 4);
+if (qemu_name)
+ size = snprintf(buf, sizeof(buf), "QEMU (%s)", qemu_name);
+else
+ size = snprintf(buf, sizeof(buf), "QEMU");
+
Perhaps in the modern style:
snprintf("%s - QEMU", sizeof, qemu_name)
?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problem Running QEMU, and passing new commands
> Hi, > I have successfully integrated the statistical simulation package > SimPoint with QEMU. > I am curious where I would edit QEMU to look for such commands, some > point in the code where I can see what command is passed to QEMU, and > do something such as > "if strcmp(command, "start_simpoint") == 0" take a look a the monitor.c file in the root directory. "register" your function with the static term_cmd_t term_cmds[] and take a look at the other commands for an example. > qemu-img create -f qcow c.img 3G > ./i386-softmmu/qemu -hda c.img -L ./pc-bios/ -nographic with this you just create an empty disk and try to boot it. - i guess this is similar to trying to boot an empty disk in a real system. the -nographic switch prevents you from seeing the "unknown boot device" error that is presented to you by the bios. so do as with real hardware and install an operating system on that c.img you just created (i'm fairly sure that is mentioned in the good documentation provided on the qemu homepage ;-)) > and it loads up to the (qemu) prompt. However, at that point > everything freezes. I am running QEMU on a linux host with a dual > 64-bit AMD processors, and doing this over an SSH connection. you might try the -vnc option, you can then don't need -nographic nomore and can check the system via any common vncclient. > > If anyone has any advice on how I can get QEMU to boot to the point > where I can enter commands, and how I can monitor these commands > within the source code, I would very much appreciate the assistance. i hope the above mentioned helped at least in parts and is not completely wrong. if others think so please corret me. > ~Shane Brennan > UC Santa Cruz cheers m. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Proposal: option for CPU selection
Here's a patch that allow the user to specify a specific CPU
model/variant on the command line.
This makes different CPU tests less painfull, as the current code need a
recompilation for this.
This patch only has an actual effect when using the PowerPC target, as I
don't want to break other targets, but would be imho easy to implement
for all targets.
It just adds a -C facultative option to the command line and
a new parameter to the machine->init callback. A machine can then ignore
this parameter or tune the emulated CPU based on the given CPU model.
Any comments will be welcome but I'd like to insist that such an option
would really be useful, at least for testing purposes.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.259
diff -u -d -d -p -r1.259 vl.c
--- vl.c 22 Feb 2007 01:48:01 - 1.259
+++ vl.c 28 Feb 2007 09:42:43 -
@@ -6339,6 +6339,7 @@ void help(void)
"\n"
"Standard options:\n"
"-M machine select emulated machine (-M ? for list)\n"
+ "-C cpu select CPU (-C ? for list)\n"
"-fda/-fdb file use 'file' as floppy disk 0/1 image\n"
"-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"
@@ -6471,6 +6472,7 @@ enum {
QEMU_OPTION_h,
QEMU_OPTION_M,
+QEMU_OPTION_C,
QEMU_OPTION_fda,
QEMU_OPTION_fdb,
QEMU_OPTION_hda,
@@ -6546,6 +6548,7 @@ const QEMUOption qemu_options[] = {
{ "help", 0, QEMU_OPTION_h },
{ "M", HAS_ARG, QEMU_OPTION_M },
+{ "C", HAS_ARG, QEMU_OPTION_C },
{ "fda", HAS_ARG, QEMU_OPTION_fda },
{ "fdb", HAS_ARG, QEMU_OPTION_fdb },
{ "hda", HAS_ARG, QEMU_OPTION_hda },
@@ -6851,6 +6854,7 @@ int main(int argc, char **argv)
int parallel_device_index;
const char *loadvm = NULL;
QEMUMachine *machine;
+const char *cpu_model;
char usb_devices[MAX_USB_CMDLINE][128];
int usb_devices_index;
int fds[2];
@@ -6888,6 +6892,7 @@ int main(int argc, char **argv)
register_machines();
machine = first_machine;
+cpu_model = NULL;
initrd_filename = NULL;
for(i = 0; i < MAX_FD; i++)
fd_filename[i] = NULL;
@@ -6979,6 +6984,17 @@ int main(int argc, char **argv)
exit(1);
}
break;
+case QEMU_OPTION_C:
+/* hw initialization will check this */
+if (optarg[0] == '?') {
+#if defined(TARGET_PPC) || defined(TARGET_PPC64)
+ppc_cpu_list(stdout, &fprintf);
+#endif
+exit(1);
+} else {
+cpu_model = optarg;
+}
+break;
case QEMU_OPTION_initrd:
initrd_filename = optarg;
break;
@@ -7553,7 +7569,7 @@ int main(int argc, char **argv)
machine->init(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
- kernel_filename, kernel_cmdline, initrd_filename);
+ kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
/* init USB devices */
if (usb_enabled) {
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.189
diff -u -d -d -p -r1.189 vl.h
--- vl.h 20 Feb 2007 00:05:08 - 1.189
+++ vl.h 28 Feb 2007 09:42:44 -
@@ -695,7 +695,7 @@ typedef void QEMUMachineInitFunc(int ram
int boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename);
+ const char *initrd_filename, const char *cpu_model);
typedef struct QEMUMachine {
const char *name;
@@ -709,6 +709,10 @@ int qemu_register_machine(QEMUMachine *m
typedef void SetIRQFunc(void *opaque, int irq_num, int level);
typedef void IRQRequestFunc(void *opaque, int level);
+#if defined(TARGET_PPC) || defined(TARGET_PPC64)
+void ppc_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt, ...));
+#endif
+
/* ISA bus */
extern target_phys_addr_t isa_mem_base;
Index: hw/integratorcp.c
===
RCS file: /sources/qemu/qemu/hw/integratorcp.c,v
retrieving revision 1.11
diff -u -d -d -p -r1.11 integratorcp.c
--- hw/integratorcp.c 16 Jan 2007 18:54:31 - 1.11
+++ hw/integratorcp.c 28 Feb 2007 09:42:44 -
@@ -516,7 +516,7 @@ static void integratorcp_init(int ram_si
static void integratorcp926_init(int ram_size, int vga_ram_size,
int boot_device, DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
-const char *initrd_filen
Re: [Qemu-devel] QEMU/pc and scsi disks
On Sunday 04 March 2007 09:28, Avi Kivity wrote: > Anthony Liguori wrote: > >> 1. Any option should be settable either in the config file or > >> command line. In other words, the user should not be forced to use a > >> config file. This is useful for management programs who keep all > >> options in an internal database, and for users who can experiment via > >> a ^P edit edit edit . > > > > I think we should still provide the ability to set the most common > > options via the command line. I'm also fine with specifying single > > options on the command line. I suspect though that being able to do > > -config - is more useful for management tools than building large > > strings of command line options. > > Out of curiosity, why? If the options are store in some database, as is > likely, surely it is easier to generate a longish command line than to > generate a unique name for a file, remove it if it already exists, write > out the data, launch qemu, and clean up the file later? And for > migration, you have to regenerate it, since some options may have > changed (cdrom media). You're going to start hitting commandline length limits fairly rapidly (Windows in particular has a fairly low limit). Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
Paul Brook wrote: Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And for migration, you have to regenerate it, since some options may have changed (cdrom media). You're going to start hitting commandline length limits fairly rapidly (Windows in particular has a fairly low limit). Well, at list on linux, the limit is sane (1024 or 10240?). -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
On Sunday 04 March 2007 11:48, Avi Kivity wrote: > Paul Brook wrote: > >> Out of curiosity, why? If the options are store in some database, as is > >> likely, surely it is easier to generate a longish command line than to > >> generate a unique name for a file, remove it if it already exists, write > >> out the data, launch qemu, and clean up the file later? And for > >> migration, you have to regenerate it, since some options may have > >> changed (cdrom media). > > > > You're going to start hitting commandline length limits fairly rapidly > > (Windows in particular has a fairly low limit). > > Well, at list on linux, the limit is sane (1024 or 10240?). IIRC linux has a ~32k commandline limit. I wouldn't be surprised if configs end up exceeding that. If you're running on linux then creating a temporary file is also trivial[1]. Paul [1] see mkstemp(3) and tmpfile(3). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Bugs. Patches. Feedback.
I want to help qemu project, but some patches which I post to the mail list have ignored. I guess that a open source project should have faster feedback. Subject of posts which have still ignored: [PATCH] syscall mincore [PATCH] syscall uselib [BUG] [PATCH] Syscall gethostname fix [BUG] [PATCH] Syscalls recv and recvfrom fix [PATCH] Syscall clock_gettime and clock_getres implementaion I'm working on qemu package in ALT Linux Sisyphus. I have got more than 30 patches and I'm interesting in to be some of them in upstream. Thanks for qemu. It's a great project. signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Bugs. Patches. Feedback.
On Sunday 04 March 2007 11:52, Kirill A. Shutemov wrote: > I want to help qemu project, but some patches which I post to the mail > list have ignored. I guess that a open source project should have faster > feedback. Giving some description of the patches might help. Patches with no explanation or justification generally go straight to the bottom of my queue. > [PATCH] syscall uselib This one is almost certainly wrong. I very much doubt the host kernel is going to do anything useful with target binaries. This is a seriously crufty syscall anyway. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
Hi Avi, On Sun, 4 Mar 2007, Avi Kivity wrote: Anthony Liguori wrote: I think we should still provide the ability to set the most common options via the command line. I'm also fine with specifying single options on the command line. I suspect though that being able to do -config - is more useful for management tools than building large strings of command line options. Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And for migration, you have to regenerate it, since some options may have changed (cdrom media). I think Anthony was suggesting that "-config -" would read the config from standard input, avoiding the need for any temporary file, and also avoiding any command-line length limits on any platforms (Win32 is unlikely to accept as much as Linux). Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson < at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
Avi Kivity wrote: Anthony Liguori wrote: 1. Any option should be settable either in the config file or command line. In other words, the user should not be forced to use a config file. This is useful for management programs who keep all options in an internal database, and for users who can experiment via a ^P edit edit edit . I think we should still provide the ability to set the most common options via the command line. I'm also fine with specifying single options on the command line. I suspect though that being able to do -config - is more useful for management tools than building large strings of command line options. Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And for migration, you have to regenerate it, since some options may have changed (cdrom media). Sorry, I should have been more specific. I mean '-config -' where '-' would indicate reading from stdin. Regards, Anthony Liguori Of course the config file is very useful for a user maintaining a few virtual machines on their own, but when qemu is part of a longer food chain, I think it's just a complication. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add -name option
Avi Kivity wrote:
Anthony Liguori wrote:
This option helps differentiate between guests when running more than
one instance of QEMU. It adds a string to the SDL window title and
to the VNC server title.
Having a name associated with a guest is also terribly useful for
management tools as it gives a standard way to identify guests to the
user.
-vnc_write_u32(vs, 4);-vnc_write(vs, "QEMU", 4);
+if (qemu_name) +size = snprintf(buf, sizeof(buf), "QEMU
(%s)", qemu_name);
+else
+size = snprintf(buf, sizeof(buf), "QEMU");
+
Perhaps in the modern style:
snprintf("%s - QEMU", sizeof, qemu_name)
So right now we have:
QEMU
QEMU - Press Ctrl+Alt to exit grab
My patch would add:
QEMU (WinXP Home)
QEMU (WinXP Home) - Press Ctrl+Alt to exit grab
You're suggesting:
WinXP Home - QEMU
WinXP Home - QEMU - Press Ctrl+Alt to exit grab
I like yours for the first title but the SDL grab version seems a little
strange. That's why I stuck it in ()s in the first place.
Anyone else have ideas?
Regards,
Anthony Liguori
?
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add -name option
Anthony Liguori wrote: So right now we have: QEMU QEMU - Press Ctrl+Alt to exit grab My patch would add: QEMU (WinXP Home) QEMU (WinXP Home) - Press Ctrl+Alt to exit grab You're suggesting: WinXP Home - QEMU WinXP Home - QEMU - Press Ctrl+Alt to exit grab I like yours for the first title but the SDL grab version seems a little strange. That's why I stuck it in ()s in the first place. Anyone else have ideas? Maybe WinXP Home - QEMU (press Ctrl+Alt to exit grab) WinXP Home (press Ctrl + Alt to exit grab) - QEMU or even WinXP Home - QEMU with detection that the mouse is being furiously moved on its pad, coupled with the motion sensor indicating the machine is being kicked. -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU/pc and scsi disks
Chris Wilson wrote: Hi Avi, On Sun, 4 Mar 2007, Avi Kivity wrote: Anthony Liguori wrote: I think we should still provide the ability to set the most common options via the command line. I'm also fine with specifying single options on the command line. I suspect though that being able to do -config - is more useful for management tools than building large strings of command line options. Out of curiosity, why? If the options are store in some database, as is likely, surely it is easier to generate a longish command line than to generate a unique name for a file, remove it if it already exists, write out the data, launch qemu, and clean up the file later? And for migration, you have to regenerate it, since some options may have changed (cdrom media). I think Anthony was suggesting that "-config -" would read the config from standard input, avoiding the need for any temporary file, and also avoiding any command-line length limits on any platforms (Win32 is unlikely to accept as much as Linux). Ah, I missed the '-'. Thanks. Indeed it's quite easy to feed a config file from memory into qemu. -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Proposal: option for CPU selection
OK. Except that I would prefer "-cpu" instead of "-C". Regards, Fabrice. J. Mayer wrote: Here's a patch that allow the user to specify a specific CPU model/variant on the command line. This makes different CPU tests less painfull, as the current code need a recompilation for this. This patch only has an actual effect when using the PowerPC target, as I don't want to break other targets, but would be imho easy to implement for all targets. It just adds a -C facultative option to the command line and a new parameter to the machine->init callback. A machine can then ignore this parameter or tune the emulated CPU based on the given CPU model. Any comments will be welcome but I'd like to insist that such an option would really be useful, at least for testing purposes. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add -name option
On Sun, Mar 04, 2007 at 11:11:15AM -0600, Anthony Liguori wrote:
> Avi Kivity wrote:
> >Anthony Liguori wrote:
> >>This option helps differentiate between guests when running more than
> >>one instance of QEMU. It adds a string to the SDL window title and
> >>to the VNC server title.
> >>
> >>Having a name associated with a guest is also terribly useful for
> >>management tools as it gives a standard way to identify guests to the
> >>user.
> >>
> >>
> >>-vnc_write_u32(vs, 4);-vnc_write(vs, "QEMU", 4);
> >>+if (qemu_name) +size = snprintf(buf, sizeof(buf), "QEMU
> >>(%s)", qemu_name);
> >>+else
> >>+size = snprintf(buf, sizeof(buf), "QEMU");
> >>+
> >
> >Perhaps in the modern style:
> >
> > snprintf("%s - QEMU", sizeof, qemu_name)
>
> So right now we have:
>
> QEMU
> QEMU - Press Ctrl+Alt to exit grab
>
> My patch would add:
>
> QEMU (WinXP Home)
> QEMU (WinXP Home) - Press Ctrl+Alt to exit grab
>
> You're suggesting:
>
> WinXP Home - QEMU
> WinXP Home - QEMU - Press Ctrl+Alt to exit grab
>
> I like yours for the first title but the SDL grab version seems a little
> strange. That's why I stuck it in ()s in the first place.
>
> Anyone else have ideas?
Take 'QEMU' out of the title as it doesn't really give any useful info
compared to the name of the OS. If the user doesn't specify an explicit
name it can use the generic 'QEMU' as title, otherwise leave it out.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] EFI BIOS
Hi, There is now an EFI BIOS for QEMU thanks to Tristan Gingold. It is available from the download section of the web site (http://bellard.org/qemu/efi-bios.tar.bz2). It can only be used with the CVS version of QEMU. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] EFI BIOS
Hmm, What guest platform/OS supports it? Not XP or Vista iirc... Thanks, Hetz On 3/5/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: Hi, There is now an EFI BIOS for QEMU thanks to Tristan Gingold. It is available from the download section of the web site (http://bellard.org/qemu/efi-bios.tar.bz2). It can only be used with the CVS version of QEMU. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Skepticism is the lazy person's default position. Visit my blog (hebrew) for things that (sometimes) matter: http://wp.dad-answers.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] EFI BIOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hetz Ben Hamo wrote: > Hmm, What guest platform/OS supports it? Not XP or Vista iirc... Linux and MacOSX for sure; I suppose BSD too. - -- Flavio Visentin GPG Key: http://www.zipman.it/gpgkey.asc There are only 10 types of people in this world: those who understand binary, and those who don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF60pzusUmHkh1cnoRAmfGAJ96mUiSh5iAv+xmEmVAXmnXz8mLXgCfSejT EnSQ1XvfYxd2pY6t8xdau/s= =UD/2 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] EFI BIOS
Hi, On 3/4/07, Hetz Ben Hamo <[EMAIL PROTECTED]> wrote: Hmm, What guest platform/OS supports it? Not XP or Vista iirc... MacIntels all have EFI BIOS. All Itanium machines have them too, so all OS that support Itanium support EFI. Guillaume ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Automatically eject CD-ROM disk in Linux host system
Hi, I wrote a patch to automatically eject a physical CD-ROM disk when: * Issue "eject" command in monitor console, or * Issue "eject" command in Linux guest system, or * In Windows guest system, press the right mouse button above CD-ROM icon, then select "eject". This is patch is based on QEMU 0.8.2 in Xen 3.0.3, and works on Linux host system. Thanks Xiaoyang eject_cdrom.patch Description: eject_cdrom.patch ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Proposal: option for CPU selection
On Sun, 2007-03-04 at 19:18 +0100, Fabrice Bellard wrote: > OK. Except that I would prefer "-cpu" instead of "-C". OK; I choosed -C for "symetry" with the machine selection option (-M) but -cpu is OK for me... > J. Mayer wrote: > > Here's a patch that allow the user to specify a specific CPU > > model/variant on the command line. > > This makes different CPU tests less painfull, as the current code need a > > recompilation for this. > > This patch only has an actual effect when using the PowerPC target, as I > > don't want to break other targets, but would be imho easy to implement > > for all targets. > > It just adds a -C facultative option to the command line and > > a new parameter to the machine->init callback. A machine can then ignore > > this parameter or tune the emulated CPU based on the given CPU model. > > > > Any comments will be welcome but I'd like to insist that such an option > > would really be useful, at least for testing purposes. -- J. Mayer <[EMAIL PROTECTED]> Never organized ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] FreeBSD Support
Hi, On 03/03/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote: andrzej zaborowski wrote: > Hi, > > On 20/02/07, Christopher Olsen <[EMAIL PROTECTED]> wrote: > >Ok FreeBSD Support round one.. > > > >Be gentle this is my first attempt at working with the rest of this > >community.. > > > >Files it modifies and the reasons are as follows > > > >configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does > >not need -ltr > >Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr > > See http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00166.html > - I believe this is a more appropriate way to select -lrt. The solaris part there looked a bit inconsistent, is the appended version ok? It works for FreeBSD, I think it's Ok. Regards, Andrew ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
