Re: [Qemu-devel] qemu and configuration file?
I shouldn't write posts at 7-8am should be s/Certainly better every/Certainly better than every/ s/broken and compatible/broken and incompatible/ sry :) , you probably understood anyway what i meant ... martin martin wrote: If we'd go for a config file at all with such a complicated structure, i see no reasons why to choose anything else than xml for it. We have tons of xml libs that can be used for gui's (think perl, tk, python etc...). Certainly better every dude writing it's own XuPeRpArSeR that will be broken and compatible after a major change in qemu ... Another choice would be the pure rc (just 'item = value' lines) without any supersmart blocks. xml style or rc style, please no hack in betweeen :) martin ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
If we'd go for a config file at all with such a complicated structure, i see no reasons why to choose anything else than xml for it. We have tons of xml libs that can be used for gui's (think perl, tk, python etc...). Certainly better every dude writing it's own XuPeRpArSeR that will be broken and compatible after a major change in qemu ... Another choice would be the pure rc (just 'item = value' lines) without any supersmart blocks. xml style or rc style, please no hack in betweeen :) martin Giuseppe Della Bianca wrote: Hi. My idea is this: - qemu start - set up of the hardcode parameters - reading of the configuration file and set up of the parameters - set up of the parameters of command line Example of configuration file: [general] [vlan0] ip= x.y.x.w mac= l:m:n:o [/vlan0] [/general] [suse.img] [vlan3] mac= h:j:k:l [/vlan3] [/suse.img] [win.img] [vlan2] mac= z:x:c:v [/vlan2] [/win.img] Result: - full compatibility with every version of qemu - more flexibility - possibility to set up the hardcode parameters - possibility of parameters personalized for every image One similar thing, with smaller flexibility, is possible without modify qemu and using one series of bash script. Comments are welcomes (at least one "it does not interest to us"). Regards. Gdb ___ 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] qemu and configuration file?
On 1/3/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > > If I find 1 free hour tomorrow I'll post a POC. > > POC=Piece Of Crap??? ;-) I can only hope he meant Proof Of Concept :) -- "I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science." Donald Knuth ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
Hi, On Tue, 3 Jan 2006, Flavio Visentin wrote: > It would be useful for automatic startup of the VMs by init scripts. > OTOH it's very simple to create a config file parser with > perl/python/bash who can wrap around qemu options. It is simpler to write the bash script right away, especially if you know init scripts. > If I find 1 free hour tomorrow I'll post a POC. POC=Piece Of Crap??? ;-) Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Brook wrote: > Config file support without a decent GUI seem rather pointless. > The big advantage of doing it as a shell script is it's dead easy to hack to > include whatever custom magical features people want. It would be useful for automatic startup of the VMs by init scripts. OTOH it's very simple to create a config file parser with perl/python/bash who can wrap around qemu options. If I find 1 free hour tomorrow I'll post a POC. - -- Flavio Visentin | \|||/ |@/0.0\@ | \ - / +--oOOo---oOOo-- There are only 10 types of people in this world: those who understand binary, and those who don't. GPG Key: http://www.zipman.it/gpgkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuvpousUmHkh1cnoRAgvHAJ0eHmaCxf0q1od+El+v/goRS9XsbwCfYdVm 8M59yryja9pnmrNJff1etLI= =wcb1 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
> Result: > - full compatibility with every version of qemu > - more flexibility > - possibility to set up the hardcode parameters > - possibility of parameters personalized for every image > > One similar thing, with smaller flexibility, is possible > without modify qemu and using one series of bash script. > > Comments are welcomes (at least one "it does not interest to us"). I'd go for the shell script. If enough people like it I'm sure it could be included with qemu. Config file support without a decent GUI seem rather pointless. The big advantage of doing it as a shell script is it's dead easy to hack to include whatever custom magical features people want. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and configuration file?
Hi. My idea is this: - qemu start - set up of the hardcode parameters - reading of the configuration file and set up of the parameters - set up of the parameters of command line Example of configuration file: [general] [vlan0] ip= x.y.x.w mac= l:m:n:o [/vlan0] [/general] [suse.img] [vlan3] mac= h:j:k:l [/vlan3] [/suse.img] [win.img] [vlan2] mac= z:x:c:v [/vlan2] [/win.img] Result: - full compatibility with every version of qemu - more flexibility - possibility to set up the hardcode parameters - possibility of parameters personalized for every image One similar thing, with smaller flexibility, is possible without modify qemu and using one series of bash script. Comments are welcomes (at least one "it does not interest to us"). Regards. Gdb ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re: [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints
Hi Mulyadi,
The problem that you are running into here is that sys_uname has been
replaced by sys_newuname in kernel/sys.c. When I put a breakpoint in
this function, everything works correctly when I run uname in the
virtual machine.
I'm not sure I exactly understand your concern that breakpoints could
be missed. When you set the breakpoint, tb_invalidate_phys_page_range
is called, invalidating the translation block block for the address
where you are placing the breakpoint. At this point, the next time that
the address is hit, translate.c:gen_intermediate_code will have to be
called, and the breakpoint will be hit. Let me know if I've missed
something here.
Thanks,
AndreOn 1/1/06, Mulyadi Santosa <[EMAIL PROTECTED]> wrote:
Hello Andre...> Not a problem. I only started using qemu a month ago, so it took me a> while to get oriented in the code and understand what was going on. I> must say that I've been really impressed with qemu so far.
There was an interesting case I had found recently. In Linux kernel fori386 arch, you will see that sys_uname is placed to return kernelversion/name. Funny thing is, even if I use your patch (against qemu
0.7.1) and I put a breakpoint at sys_uname and issue "uname" at bashprompt, the Qemu VM doesn't stop. Can you kindly check it?NB: Please see target-i386/translate.c, there you will see lines like
these (around line 6306):if (env->nb_breakpoints > 0) {for(j = 0; j < env->nb_breakpoints; j++) {if
(env->breakpoints[j] == pc_ptr) {gen_debug(dc,
pc_ptr - dc->cs_base);break;}}}What I understand from this code is, VM is stop if breakpoint addressmatches with pc_ptr, which tb->pc and AFAIK that is the start address
of the translation block. So in other word, in some cases Qemu mightstill miss the breakpoint (does it explain the sys_uname case?) PleaseCMIIWregardsMulyadi
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Shutting down the unused bug tracker
Fabrice didn't know that this existed since recently. I had commented on setting up bugzilla, but I found the savanna bts later. I think it should stay open and start being used. Currently everything is done over the mailinglist (some stuff via irc). I think that should change. - Mick Adam Kennedy wrote: I've put this into a seperate email for thread purposes. It appears you have a bug tracker running on Savannah that people have people have been submitting bugs into for 2 years, but that nobody has actually been handling. Of the 59 bug reports in the tracking system, none have been assigned, prioritised, or closed. I would highly recommend shutting this down if you are not using it, as it may be causing people to falsely believe they have reported bugs, when they should have reported them to this (or the -user) mailing list. Adam K ___ 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
[Qemu-devel] [PATCH] ide id updates
Hi,
Some changes to the ata/atapi identify code and default values:
- Store the drive id in the IDEState, so we can reliably set and query
new values. Right now doing things like:
# hdparm -Xudma2 /dev/hda
# hdparm -i /dev/hda (and check for mode)
doesn't work, as the IDENTIFY command will re-fill default values
everytime.
- Fill in IORDY, dma timings, and mdma modes.
- Don't set both 1 << 14 and 0x4000 for word 93, it's the same thing.
- Fill in supported/set ata specs
- Implement real setting of transfer mode (sub feature 0x03 of
WIN_SETFEATURES) so we can reflect the transfer mode requested by the
OS.
With this patch, Linux correctly identifies and sets DMA mode in the
drive by default.
Fabrice, let me know if you will merge this. I need to post another
little update for the lba48 support patch (needed a cast for hob filling
in ide_set_sector() to work correctly for really big disks), since I
need to rebase that on top of this patch.
Index: hw/ide.c
===
RCS file: /sources/qemu/qemu/hw/ide.c,v
retrieving revision 1.38
diff -u -r1.38 ide.c
--- hw/ide.c6 Aug 2005 09:14:32 - 1.38
+++ hw/ide.c3 Jan 2006 19:35:06 -
@@ -296,6 +296,8 @@
int cylinders, heads, sectors;
int64_t nb_sectors;
int mult_sectors;
+int identify_set;
+uint16_t identify_data[256];
SetIRQFunc *set_irq;
void *irq_opaque;
int irq;
@@ -414,6 +416,11 @@
unsigned int oldsize;
char buf[20];
+if (s->identify_set) {
+ memcpy(s->io_buffer, s->identify_data, sizeof(s->identify_data));
+ return;
+}
+
memset(s->io_buffer, 0, 512);
p = (uint16_t *)s->io_buffer;
put_le16(p + 0, 0x0040);
@@ -433,10 +440,10 @@
put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
#endif
put_le16(p + 48, 1); /* dword I/O */
-put_le16(p + 49, 1 << 9 | 1 << 8); /* DMA and LBA supported */
+put_le16(p + 49, (1 << 11) | (1 << 9) | (1 << 8)); /* DMA and LBA
supported */
put_le16(p + 51, 0x200); /* PIO transfer cycle */
put_le16(p + 52, 0x200); /* DMA transfer cycle */
-put_le16(p + 53, 1 | 1 << 2); /* words 54-58,88 are valid */
+put_le16(p + 53, 1 | 1 << 1 | 1 << 2); /* words 54-58,64-70,88 are valid */
put_le16(p + 54, s->cylinders);
put_le16(p + 55, s->heads);
put_le16(p + 56, s->sectors);
@@ -447,15 +454,24 @@
put_le16(p + 59, 0x100 | s->mult_sectors);
put_le16(p + 60, s->nb_sectors);
put_le16(p + 61, s->nb_sectors >> 16);
-put_le16(p + 80, (1 << 1) | (1 << 2));
+put_le16(p + 63, 0x07); /* mdma0-2 supported */
+put_le16(p + 65, 120);
+put_le16(p + 66, 120);
+put_le16(p + 67, 120);
+put_le16(p + 68, 120);
+put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */
+put_le16(p + 81, 0x16); /* conforms to ata5 */
put_le16(p + 82, (1 << 14));
put_le16(p + 83, (1 << 14));
put_le16(p + 84, (1 << 14));
put_le16(p + 85, (1 << 14));
put_le16(p + 86, 0);
put_le16(p + 87, (1 << 14));
-put_le16(p + 88, 0x1f | (1 << 13));
-put_le16(p + 93, 1 | (1 << 14) | 0x2000 | 0x4000);
+put_le16(p + 88, 0x3f | (1 << 13)); /* udma5 set and supported */
+put_le16(p + 93, 1 | (1 << 14) | 0x2000);
+
+memcpy(s->identify_data, p, sizeof(s->identify_data));
+s->identify_set = 1;
}
static void ide_atapi_identify(IDEState *s)
@@ -463,6 +479,11 @@
uint16_t *p;
char buf[20];
+if (s->identify_set) {
+ memcpy(s->io_buffer, s->identify_data, sizeof(s->identify_data));
+ return;
+}
+
memset(s->io_buffer, 0, 512);
p = (uint16_t *)s->io_buffer;
/* Removable CDROM, 50us response, 12 byte packets */
@@ -483,11 +504,14 @@
put_le16(p + 66, 0xb4); /* recommended DMA multiword tx cycle time */
put_le16(p + 67, 0x12c); /* minimum PIO cycle time without flow control */
put_le16(p + 68, 0xb4); /* minimum PIO cycle time with IORDY flow control
*/
-
+
put_le16(p + 71, 30); /* in ns */
put_le16(p + 72, 30); /* in ns */
put_le16(p + 80, 0x1e); /* support up to ATA/ATAPI-4 */
+
+memcpy(s->identify_data, p, sizeof(s->identify_data));
+s->identify_set = 1;
}
static void ide_set_signature(IDEState *s)
@@ -1601,13 +1625,36 @@
/* XXX: valid for CDROM ? */
switch(s->feature) {
case 0x02: /* write cache enable */
-case 0x03: /* set transfer mode */
case 0x82: /* write cache disable */
case 0xaa: /* read look-ahead enable */
case 0x55: /* read look-ahead disable */
s->status = READY_STAT | SEEK_STAT;
ide_set_irq(s);
break;
+case 0x03: { /* set transfer mode */
+ uint8_t val = s->nsector & 0x07;
+
+ switch (s->nsector >> 3) {
+ case 0x00: /* pio default */
+ case 0x01: /* pio mode */
+
[Qemu-devel] Re: Pharammaceutical
___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] OpenStep / Busmouse - correct patch
Hi,
>> Hmm, there seems to be a problem with your patch, though I haven't quite
>> figured out what exactly the cause is. When using the -busmouse option,
>> the busmouse_init function is called and seems to register the callbacks
>> for the provided I/O address ranges successfully (return value is 0 from
>> register_ioport_{read,write}) - but the actual callback routines are
>> never being executed, which results in OpenStep not recognizing the
>> busmouse.
>
> I'll investigate.
Got it! Your patch calls busmouse_init() before calling init_ioports() in
vl.c.
I moved the sequence some lines down (below cpu_calibrate_ticks), and
now the mouse works as expected.
malc's remark, however, is correct - the SB16 emulation also uses IRQ 5.
I have to check if OpenStep is able to use a different IRQ for either the
Soundblaster or the busmouse driver...
Btw., networking now works fine using an open source NE2k PCI driver
for OpenStep. I'll post a unified patch later this evening and set up a web
page describing how to install OpenStep in qemu.
Michael
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] OpenStep / Busmouse - correct patch
On Tue, 3 Jan 2006, Johannes Schindelin wrote:
Hi,
On Tue, 3 Jan 2006, [EMAIL PROTECTED] wrote:
The most difficult problem was actually finding documentation on the
busmouse controller ;-).
That always seems to be the biggest problem...
How about this on top (unfortunately untested, since I do not
have a system handy which supports a busmouse):
Hmm, there seems to be a problem with your patch, though I haven't quite
figured out what exactly the cause is. When using the -busmouse option,
the busmouse_init function is called and seems to register the callbacks
for the provided I/O address ranges successfully (return value is 0 from
register_ioport_{read,write}) - but the actual callback routines are
never being executed, which results in OpenStep not recognizing the
busmouse.
I'll investigate.
FWIW. IRQ 5 is already taken by sb16.
--
mailto:[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] OpenStep / Busmouse - correct patch
Hi,
On Tue, 3 Jan 2006, [EMAIL PROTECTED] wrote:
> The most difficult problem was actually finding documentation on the
> busmouse controller ;-).
That always seems to be the biggest problem...
> > How about this on top (unfortunately untested, since I do not
> > have a system handy which supports a busmouse):
>
> Hmm, there seems to be a problem with your patch, though I haven't quite
> figured out what exactly the cause is. When using the -busmouse option,
> the busmouse_init function is called and seems to register the callbacks
> for the provided I/O address ranges successfully (return value is 0 from
> register_ioport_{read,write}) - but the actual callback routines are
> never being executed, which results in OpenStep not recognizing the
> busmouse.
I'll investigate.
Ciao,
Dscho
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] OpenStep / Busmouse - correct patch
Hi,
> On Sun, 1 Jan 2006, [EMAIL PROTECTED] wrote:
>
>> I attached the correct version to this mail. Sorry...
>
> Impressive!
Thanks! The most difficult problem was actually finding documentation
on the busmouse controller ;-).
> How about this on top (unfortunately untested, since I do not
> have a system handy which supports a busmouse):
Hmm, there seems to be a problem with your patch, though I haven't quite
figured out what exactly the cause is. When using the -busmouse option,
the busmouse_init function is called and seems to register the callbacks for
the provided I/O address ranges successfully (return value is 0 from
register_
ioport_{read,write}) - but the actual callback routines are never being
executed, which results in OpenStep not recognizing the busmouse.
regards,
Michael
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
