[Fwd: [Qemu-devel] RFC: BIOS filename option]
Forwarded Message
> From: J. Mayer <[EMAIL PROTECTED]>
> Reply-To: qemu-devel@nongnu.org
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] RFC: BIOS filename option
> Date: Thu, 04 Oct 2007 05:11:55 +0200
>
> Hi,
>
> This is a proposal to allow the user to select a BIOS file name on the
> command line. The goal is mainly to ease debug, for example when I want
> to try to run a firmware comming from a real machine instead of the
> default one.
> The only change is to add a -bios option, use the given file
> if any or use the default if none were given.
> Maybe the options would be better named as -biosfile Or it maybe a
> good idea to give a full path, not to concatenate the given name with
> the bios_dir prefix...
> Some may find this option is not so useful, as one can specify a
> directory to find the target BIOS. But I feel more confortable keeping
> all BIOS images together at the same place.
>
> Please comment.
Hum, seems like I forgot to attach the patch. Here it is...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.343
diff -u -d -d -p -r1.343 vl.c
--- vl.c 29 Sep 2007 19:24:40 - 1.343
+++ vl.c 4 Oct 2007 03:05:18 -
@@ -143,6 +143,7 @@ int inet_aton(const char *cp, struct in_
#define MAX_IOPORTS 65536
const char *bios_dir = CONFIG_QEMU_SHAREDIR;
+const char *bios_name = NULL;
char phys_ram_file[1024];
void *ioport_opaque[MAX_IOPORTS];
IOPortReadFunc *ioport_read_table[3][MAX_IOPORTS];
@@ -7151,6 +7154,7 @@ enum {
QEMU_OPTION_d,
QEMU_OPTION_hdachs,
QEMU_OPTION_L,
+QEMU_OPTION_bios,
QEMU_OPTION_no_code_copy,
QEMU_OPTION_k,
QEMU_OPTION_localtime,
@@ -7243,6 +7247,7 @@ const QEMUOption qemu_options[] = {
{ "d", HAS_ARG, QEMU_OPTION_d },
{ "hdachs", HAS_ARG, QEMU_OPTION_hdachs },
{ "L", HAS_ARG, QEMU_OPTION_L },
+{ "bios", HAS_ARG, QEMU_OPTION_bios },
{ "no-code-copy", 0, QEMU_OPTION_no_code_copy },
#ifdef USE_KQEMU
{ "no-kqemu", 0, QEMU_OPTION_no_kqemu },
@@ -7889,6 +7895,9 @@ int main(int argc, char **argv)
case QEMU_OPTION_L:
bios_dir = optarg;
break;
+case QEMU_OPTION_bios:
+bios_name = optarg;
+break;
case QEMU_OPTION_S:
autostart = 0;
break;
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.273
diff -u -d -d -p -r1.273 vl.h
--- vl.h 30 Sep 2007 14:44:52 - 1.273
+++ vl.h 4 Oct 2007 03:05:18 -
@@ -129,6 +129,7 @@ uint64_t muldiv64(uint64_t a, uint32_t b
void hw_error(const char *fmt, ...);
extern const char *bios_dir;
+extern const char *bios_name;
extern int vm_running;
extern const char *qemu_name;
Index: hw/mips_malta.c
===
RCS file: /sources/qemu/qemu/hw/mips_malta.c,v
retrieving revision 1.44
diff -u -d -d -p -r1.44 mips_malta.c
--- hw/mips_malta.c 17 Sep 2007 08:09:47 - 1.44
+++ hw/mips_malta.c 4 Oct 2007 03:05:18 -
@@ -791,7 +791,9 @@ void mips_malta_init (int ram_size, int
/* Load a BIOS image unless a kernel image has been specified. */
if (!kernel_filename) {
-snprintf(buf, sizeof(buf), "%s/%s", bios_dir, BIOS_FILENAME);
+if (bios_name == NULL)
+bios_name = BIOS_FILENAME;
+snprintf(buf, sizeof(buf), "%s/%s", bios_dir, bios_name);
ret = load_image(buf, phys_ram_base + bios_offset);
if (ret < 0 || ret > BIOS_SIZE) {
fprintf(stderr,
Index: hw/mips_pica61.c
===
RCS file: /sources/qemu/qemu/hw/mips_pica61.c,v
retrieving revision 1.8
diff -u -d -d -p -r1.8 mips_pica61.c
--- hw/mips_pica61.c 25 Jun 2007 10:57:10 - 1.8
+++ hw/mips_pica61.c 4 Oct 2007 03:05:18 -
@@ -94,7 +94,9 @@ void mips_pica61_init (int ram_size, int
/* load a BIOS image */
bios_offset = ram_size + vga_ram_size;
-snprintf(buf, sizeof(buf), "%s/%s", bios_dir, BIOS_FILENAME);
+if (bios_name == NULL)
+bios_name = BIOS_FILENAME;
+snprintf(buf, sizeof(buf), "%s/%s", bios_dir, bios_name);
bios_size = load_image(buf, phys_ram_base + bios_offset);
if ((bios_size <= 0) || (bios_size > BIOS_SIZE)) {
/* fatal */
Index: hw/mips_r4k.c
===
RCS file: /sources/qemu/qemu/hw/mips_r4k.c,v
retrieving revision 1.47
diff -u -d -d -p -r1.47 mips_r4k.c
--- hw/mips_r4k.c 16 Sep 2007 21:07:54 - 1.47
+++ hw/mips_r4k.c 4 Oct 2007 03:05:18 -
@@ -179,7 +179,9 @@ void mips_r4k_init (int ram_size, int vg
preloaded we also initialize the hardware, since the BIOS wasn't
run. */
bios_offset = ram_size + vga_ram_size;
-
Re: [Qemu-devel] RFC: cleanups in ELF loader
On Mon, 2007-10-01 at 04:35 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > On Sun, 2007-09-30 at 17:09 +0200, J. Mayer wrote:
> > > On Sun, 2007-09-30 at 14:38 +0100, Thiemo Seufer wrote:
> > > > J. Mayer wrote:
> > > > > Following what I've done in the syscalls emulation routines, it
> > > > > appeared
> > > > > to me that there seems to be a lot of confusions between host and
> > > > > target
> > > > > long in the ELF loader.
> > > >
> > > > But the ELF fields are tied to the ELFCLASS of the supported ABI, not to
> > > > the register width of the machine emulation. If anything they should
> > > > become the ELF types.
> > > >
> > > > (Your approach will e.g. break down for MIPS N32, where "long" is
> > > > smaller
> > > > thant the register width, and the ABI uses ELFCLASS32.)
> > >
> > > OK, I will try to rework this.
> >
> > I did check in the linux kernel and it appears that all variables I
> > changed from unsigned long to target_ulong seem to be unsigned long in the
> > kernel. This looks fine for me as they are addresses in the process virtual
> > address space,
> > so they should fit in a target_ulong, whatever the target registers size
> > could be.
>
> As long as eventual sign extensions are done properly this is ok.
> (Some places in the kernel have casts to elf_greg_t for that purpose.)
>
> > What seems bugged to me (but I did not make any change in that part) is
> > the auxiliary vectors generation. This seems to me to be the only place
> > where Linux explicitelly uses elf_addr_t so Qemu should do the same.
> > Then, it seems that my patch is not so bad and should not break anything
> > but is not complete as it does not fix the auxiliary vectors.
> >
> > Do you agree with this, or did I miss something else ?
Following this discussion, I reworked my patch a little bit in order to
use the elf_addr_t type for the aux infos creation. It appears to me
that it functionally changes nothing as elf_addr_t is defined to be
Elf32_OFf / Elf64_Off. But this makes the elf_create_tables function use
the same types as the Linux kernel one.
> The kernel loader (fs/binfmt_elf.c) is somewhat geared towards single
> ABI architectures. PowerPC, MIPS, SPARC etc. have all their own kludge
> (in arch/$ARCH/kernel/binfmt_elf*.c) to redefine some essential bits
> and then #include fs/binfmt_elf.c.
>
> The whole thing looks a bit scary, I'm not sure we should import it in
> Qemu. OTOH it is generally a good idea to stay in sync with the kernel
> implementation.
The thing I see is different is that the n32 ABI redefines elf_greg_t
and elf_caddr_t as 32 bits. Maybe I missed something but those types
seem not to be used by the ELF loader (or maybe I should look in a more
recent kernel ;-) ).
Then, I have seen no apparent issue with the patch and I'm quite sure
that, even if it's not correct for some specific ABI, it would bring no
regression.
The only point where there could be an evident regression is for the ARM
target:
regs->ARM_r10 = infop->start_data;
As start_data were not computed the same way as it's done in the Linux
kernel, I did change this. I hope this is not to break anything for ARM
emulation but I don't know too much of the ARM ABI so I would be glad if
some ones who know could tell me if what I did might really break ARM
binaries registers initialisation.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: elf.h
===
RCS file: /sources/qemu/qemu/elf.h,v
retrieving revision 1.10
diff -u -d -d -p -r1.10 elf.h
--- elf.h 16 Sep 2007 21:07:49 - 1.10
+++ elf.h 4 Oct 2007 03:12:51 -
@@ -1130,6 +1130,7 @@ typedef struct elf64_note {
#define elf_note elf32_note
#define elf_shdr elf32_shdr
#define elf_sym elf32_sym
+#define elf_addr_t Elf32_Off
#ifdef ELF_USES_RELOCA
# define ELF_RELOC Elf32_Rela
@@ -1144,6 +1145,7 @@ typedef struct elf64_note {
#define elf_note elf64_note
#define elf_shdr elf64_shdr
#define elf_sym elf64_sym
+#define elf_addr_t Elf64_Off
#ifdef ELF_USES_RELOCA
# define ELF_RELOC Elf64_Rela
Index: linux-user/elfload.c
===
RCS file: /sources/qemu/qemu/linux-user/elfload.c,v
retrieving revision 1.48
diff -u -d -d -p -r1.48 elfload.c
--- linux-user/elfload.c 27 Sep 2007 04:10:43 - 1.48
+++ linux-user/elfload.c 4 Oct 2007 03:12:51 -
@@ -124,6 +124,7 @@ static inline void init_thread(struct ta
/* XXX: it seems that r0 is zeroed after ! */
regs->ARM_r0 = 0;
/* For uClinux PIC binaries. */
+/* XXX: Linux does this only on ARM with no MMU (do we care ?) */
regs->ARM_r10 = infop->start_data;
}
@@ -516,8 +517,8 @@ static void bswap_sym(struct elf_sym *sy
* to be put directly into the top of new user memory.
*
*/
-static unsigned long copy_elf_strings(int argc,char ** argv, void **page,
- target_ulong p)
+static target_ulong copy_elf_strings(int a
[Qemu-devel] RFC: BIOS filename option
Hi, This is a proposal to allow the user to select a BIOS file name on the command line. The goal is mainly to ease debug, for example when I want to try to run a firmware comming from a real machine instead of the default one. The only change is to add a -bios option, use the given file if any or use the default if none were given. Maybe the options would be better named as -biosfile Or it maybe a good idea to give a full path, not to concatenate the given name with the bios_dir prefix... Some may find this option is not so useful, as one can specify a directory to find the target BIOS. But I feel more confortable keeping all BIOS images together at the same place. Please comment. -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
On Tue, 2007-10-02 at 22:06 +0200, Aurelien Jarno wrote: > Hi, Hi, > As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a > try on QEMU/MIPS, and unfortunately it doesn't work correctly. > > In some cases the kernel schedules an event very near in the future, > which means the timer is scheduled a few cycles only from its current > value. Unfortunately under QEMU, the timer runs too fast compared to the > speed at which instructions are execution. This causes a lockup of the > kernel. This can be triggered by running hwclock --hctosys in the guest > (which is run at boot time by most distributions). Until now, I haven't > found any other way to trigger the bug. [] There seem to have specific problems when using dynticks in Qemu. What I can see is that it makes the PowerPC emulation quite unusable, at least on my PC, which is an amd64 (with a fix CPU frequency), no matter if I run 32 or 64 bits mode. What I can see is that the emulated timer frequency seem to be completely random: the system time, as seen from the target CPU, is running from half of the real time to twice of the real time speed, randomly; launching Qemu twice in the same conditions, on the same machine, will give different speed for the emulated system timer. I also experiment a lot of Qemu freezes: I cannot run the emulated target more than a few minutes before it freezes; sometimes it runs less than 1 second, even not get out of the firmware. It's not the same issue than yours, as the firmware uses no timer and as it's a complete Qemu freeze: even the monitor is frozen. I tried to disactivate dynticks, just commenting the entry in alarm_timers structure. Since then, I can notice that the emulated system clock seems always to be running at the same speed as the host one (not a single second of difference after 2 hours of compilation in the target system...) and that I never had any Qemu freeze anymore since then. Which convinces me that dynticks is the source of the problems... Then, I feel like dynticks in Qemu is an experimental feature that should not be activated as default, as it seems not to be really usable as it is now. I got no idea of what's going wrong in that code, I saw nothing awfull at first sight (I only gave a quick look...) but it makes Qemu unreliable and quite unusable, as far as I can see. [...] -- J. Mayer <[EMAIL PROTECTED]> Never organized
[Qemu-devel] qemu hw/ppc405_uc.c linux-user/main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/04 01:54:45 Modified files: hw : ppc405_uc.c linux-user : main.c Log message: We must reset the PowerPC CPU _after_ registering it, as hardware reset effect is implementation dependant. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_uc.c?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.126&r2=1.127
[Qemu-devel] qemu/target-ppc op_helper_mem.h translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/04 01:50:04 Modified files: target-ppc : op_helper_mem.h translate_init.c Log message: More cache tuning fixes: * fix the tunable cache line size probe for PowerPC 970. * initialize HID5 so cache line is 32 bytes long when running in user-mode only CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper_mem.h?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.39&r2=1.40
[Qemu-devel] qemu/target-ppc cpu.h op_helper.c op_helper.h o...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/04 00:51:58 Modified files: target-ppc : cpu.h op_helper.c op_helper.h op_helper_mem.h op_mem.h translate.c translate_init.c Log message: Make PowerPC cache line size implementation dependant. Implement dcbz tunable cache line size for PowerPC 970. Make hardware reset vector implementation dependant. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.70&r2=1.71 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper_mem.h?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.84&r2=1.85 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.38&r2=1.39
Re: [Qemu-devel] [Patch] VNC: Fix crash with non-resizing clients
2007/10/3, Daniel P. Berrange <[EMAIL PROTECTED]>: > > > The memset calls in that patch are bogus & not correctly fixing the buffer > update problem. You're merely setting the 'old data' to have pixel value > 42 - if the guest OS framebuffer happens to also have aras with pixel > value > of 42 too, the frame buffer will still not correctly update. The root > problem is overly-aggressive update minimization logic in > vnc_update_client. > This is in turn flawed beause the dirty_row aray is trying to encode two > separate concepts - areas which are dirty, and areas which need to be > sent to the client. The latter are a superset of the former, but the code > in vnc_update_client minimizes based on dirtiness, so updates will get > missed out. Setting the old data to 42 merely changes which areas will get > missed updates. Agreed. I just used the same hack that is scattered around several other places to make a patch quickly. The QEMU code in Xen has added a update_row field, separate from the > dirty_row > field. Thus after a resize it can update the entire framebuffer, > regardless > of whether QEMU's copy of the framebuffer is dirty wrt to the guest copy. I think that VNC server needs a deep rework, as several qemu related projects have done, but meanwhile correcting bugs with small non-intrusive patches may be the way to go. Edu.
[Qemu-devel] qemu/target-ppc translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/03 20:27:44 Modified files: target-ppc : translate_init.c Log message: HID0 is a write-clear register on 970 (DBSR). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.37&r2=1.38
[Qemu-devel] qemu/target-ppc helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/10/03 20:19:40 Modified files: target-ppc : helper.c Log message: Enable PowerPC 64 MMU model and exceptions. Cleanups in MMU exceptions generation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.66&r2=1.67
Re: [Qemu-devel] [Patch] VNC: Fix crash with non-resizing clients
On Wed, Oct 03, 2007 at 09:29:59PM +0200, Eduardo Felipe wrote: > Hi, > > 2007/9/25, GUERRAZ Francois <[EMAIL PROTECTED]>: > > > > > > About your VNC problems : I have had problems w/ vnc too (see > > http://qemu-forum.ipi.fi/viewtopic.php?p=10468) but had no answer as > > well... > > > This problem happens when the VNC client doesn't support the DesktopSize > pseudo-encoding. Qemu crashes when the guest resizes down its display and > the VNC client sends a SetPixelFormat afterwards. > > Attached patch should fix this. It also forces a full buffer update after > resize. The memset calls in that patch are bogus & not correctly fixing the buffer update problem. You're merely setting the 'old data' to have pixel value 42 - if the guest OS framebuffer happens to also have aras with pixel value of 42 too, the frame buffer will still not correctly update. The root problem is overly-aggressive update minimization logic in vnc_update_client. This is in turn flawed beause the dirty_row aray is trying to encode two separate concepts - areas which are dirty, and areas which need to be sent to the client. The latter are a superset of the former, but the code in vnc_update_client minimizes based on dirtiness, so updates will get missed out. Setting the old data to 42 merely changes which areas will get missed updates. The QEMU code in Xen has added a update_row field, separate from the dirty_row field. Thus after a resize it can update the entire framebuffer, regardless of whether QEMU's copy of the framebuffer is dirty wrt to the guest copy. 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 -=|
Re: [Qemu-devel] U-Boot patch for qemu -M mips
Vlad Lungu wrote:
> Thiemo Seufer wrote:
>> Vlad Lungu wrote:
>> [snip]
>>
> +long int initdram(int board_type)
> +{
> + /* Sdram is setup by assembler code */
> + /* If memory could be changed, we should return the true value
> here */
> + return MEM_SIZE*1024*1024;
>
Qemu gets the amount of RAM passed via a command line switch, the
qemu-mips emulation sets up a Linux kernel like "command line" in
memory where u-boot could parse it from.
>>> Does it, or just when you pass -kernel to it? I'll check.
>>>
>>
>> Hm, you are right, it does that only for -kernel. Would it make sense
>> to change that in Qemu?
>>
> IDK. Maybe I can probe the RAM size in U-Boot , or if this does not work,
mips_r4k implements no probable memory controller, so this won't work.
> put some info somewhere (RAM, register,
> emulated DIP-dwitch), like RAM size, endianness of the CPU.
Endianness is rather pointless. If your U-Boot binary doesn't explode
immediately you got the right endianness. :-)
Thiemo
[Qemu-devel] [Patch] VNC: Fix crash with non-resizing clients
Hi,
2007/9/25, GUERRAZ Francois <[EMAIL PROTECTED]>:
>
>
> About your VNC problems : I have had problems w/ vnc too (see
> http://qemu-forum.ipi.fi/viewtopic.php?p=10468) but had no answer as
> well...
This problem happens when the VNC client doesn't support the DesktopSize
pseudo-encoding. Qemu crashes when the guest resizes down its display and
the VNC client sends a SetPixelFormat afterwards.
Attached patch should fix this. It also forces a full buffer update after
resize.
Regards,
Edu
*** vnc.c 30 Sep 2007 13:01:15 - 1.25
--- vnc.c 3 Oct 2007 18:44:17 -
@@ -289,15 +289,19 @@
ds->width = w;
ds->height = h;
ds->linesize = w * vs->depth;
-if (vs->csock != -1 && vs->has_resize && size_changed) {
- vnc_write_u8(vs, 0); /* msg id */
- vnc_write_u8(vs, 0);
- vnc_write_u16(vs, 1); /* number of rects */
- vnc_framebuffer_update(vs, 0, 0, ds->width, ds->height, -223);
- vnc_flush(vs);
- vs->width = ds->width;
- vs->height = ds->height;
+if (size_changed) {
+if (vs->csock != -1 && vs->has_resize) {
+vnc_write_u8(vs, 0); /* msg id */
+vnc_write_u8(vs, 0);
+vnc_write_u16(vs, 1); /* number of rects */
+vnc_framebuffer_update(vs, 0, 0, ds->width, ds->height, -223);
+vnc_flush(vs);
+}
+memset(vs->dirty_row, 0xFF, sizeof(vs->dirty_row));
+memset(vs->old_data, 42, ds->linesize * ds->height);
}
+vs->width = ds->width;
+vs->height = ds->height;
}
/* fastest code */
Re: [Qemu-devel] Hard disk support is broken in Windows 98SE guest
On 10/3/07, Leonardo Reiter <[EMAIL PROTECTED]> wrote:
> Index: hw/ide.c
> ===
> RCS file: /cvsroot/qemu/qemu/hw/ide.c,v
> retrieving revision 1.69
> diff -a -u -r1.69 ide.c
> --- hw/ide.c17 Sep 2007 08:09:47 - 1.69
> +++ hw/ide.c3 Oct 2007 18:00:31 -
> @@ -900,7 +900,9 @@
> if(bm == NULL) {
> bm = qemu_mallocz(sizeof(BMDMAState));
> s->bmdma = bm;
> -}
> +} else if (bm->aiocb != NULL)
> +qemu_aio_wait();
> +
> bm->ide_if = s;
> bm->dma_cb = ide_sector_write_aio_cb;
>
>
> The danger here is that the AIO signal came in already by the time we
> call qemu_aio_wait() (but bm->aiocb was not called yet), which is
> pretty unlikely, but I think it could trigger a deadlock.
If you want to try that hack, I think it's probably safer (and more
correct) to use qemu_aio_flush() instead of qemu_aio_wait().
Regards,
Leo Reiter
Re: [Qemu-devel] Hard disk support is broken in Windows 98SE guest
On 10/3/07, Victor Shkamerda <[EMAIL PROTECTED]> wrote:
> Hello,
>
> >>> On 10/2/2007 at 7:43 PM, in message <[EMAIL PROTECTED]>,
> Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> > I don't have such a system for tests. Can you narrow down which CVS
> > commit broke it?
>
> hw/ide.c 1.64 works, version 1.65 doesn't. Only BIOS operations seems to be
> affected, so it may be BIOS fault after all. You can use FreeDOS for testing,
> it doesn't install too.
>
The problem seems to be that the BIOS does not wait for the previous
write to complete before trying the next one. It's not clear to me
whether this needs to be fixed in the BIOS or in hw/ide.c. One
correct fix may be to have ide_sector_write set BUSY_STAT and then let
the AIO callback function set the status to READY_STAT, but this
definitely does not work well with the BOCHS BIOS. Here's a hack that
seems to work, but it's pretty ugly:
Index: hw/ide.c
===
RCS file: /cvsroot/qemu/qemu/hw/ide.c,v
retrieving revision 1.69
diff -a -u -r1.69 ide.c
--- hw/ide.c17 Sep 2007 08:09:47 - 1.69
+++ hw/ide.c3 Oct 2007 18:00:31 -
@@ -900,7 +900,9 @@
if(bm == NULL) {
bm = qemu_mallocz(sizeof(BMDMAState));
s->bmdma = bm;
-}
+} else if (bm->aiocb != NULL)
+qemu_aio_wait();
+
bm->ide_if = s;
bm->dma_cb = ide_sector_write_aio_cb;
The danger here is that the AIO signal came in already by the time we
call qemu_aio_wait() (but bm->aiocb was not called yet), which is
pretty unlikely, but I think it could trigger a deadlock. I don't
think that's correct, but the fact is the BIOS assumes that the write
is done by the time it does another write. That seems to step on the
io_buffer, which is part of the asynchronous write that is pending.
Another solution may be to use a separate buffer for the write, but
then you have a copy and you have to hold on to the memory until the
write finishes. I think ultimately the correct fix is in the BIOS -
perhaps a spinlock on BUSY_STAT like it does after seeks, or something
like that. Maybe someone who knows more about this can comment.
Please note that I am not asking for the above patch to be committed,
just putting it out there as food for thought. It's probably (likely)
the wrong approach.
The reason the old win2k-hack worked, even if the BIOS didn't wait for
the IDE interrupt to write the next buffer, is because the actual host
write() was synchronous and the IO buffer could be safely stepped on
at any point after that. AIO writes have to hold on to the buffer
until they complete (see man page for aio_write).
- Leo Reiter
[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/10/03 17:46:29 Modified files: target-sparc : translate.c Log message: Fix Sparc64 ldfa/stfa and float ops with fpr >= 32 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.72&r2=1.73
Re: Re: [Qemu-devel] using pthread in qemu
On Wednesday 03 October 2007 16:16:55 [EMAIL PROTECTED] wrote: > Hi, > > On 03/10/2007, Clemens Kolbitsch <[EMAIL PROTECTED]> wrote: > > hi! > > i know... i have been told not to use them, but i just HAVE TO for the > > moment :-( > > > > i need to run a second thread inside my hardware module which is not a > > problem as long as i don't use the qcow2 image format. when i switch to > > qcow2, qemu's main thread hangs because the second thread is waiting for > > a semaphore... > > > > does anyone know how to tell the second pthread not to block the primary > > thread?? > > Maybe this thread can be helpful: > http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00090.html yes.. that might have been helpful if I hadn't solved the problem differently (and I'm quite happy to have gotten rid of the pthread code ;-) ) Thanks for the answer, though!!
Re: merge GGI support? [was: Re: [Qemu-devel] [RFC] CRIS target port]
On Wed, Oct 03, 2007 at 08:59:47AM -0500, Anthony Liguori wrote: > andrzej zaborowski wrote: > >Hi, > > > > > >>If the only argument for adding GGI is so that you don't have to install > >>libsdl, then does that mean that we should have an X11, fbdev, etc. > >>backend for people who don't have GGI installed? > >> > > > >I think a GGI back-end would be useful. > > > >I wouldn't mind also having other back-ends even if SDL supports them > >(e.g. there's an Xlib patch for qemu, it is very little code compared > >to vnc.c which you could say duplicates code already present in > >libraries). The situation is the same with audio backends: there's > >oss, alsa and SDL which can do both oss and alsa but works poorly. > > > >Unrelated to this discussion on slow links VNC is much more usable > >with the Xlib patch and Xvnc than through the built-in VNC (I think it > >makes a better decision on what format to use based on the connection > >speed). > > It's probably just the lack of a compressed encoding. There are various optimizations to the VNC server in QEMU Uthat the Xen project did in their fork. On my infinite todo list is an note to take a look at these & see if its worth posting them here for merge. At least one of the changes was to reduce the number of FB updates sent to the client under some circumstances. 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 -=|
Re: merge GGI support? [was: Re: [Qemu-devel] [RFC] CRIS target port]
andrzej zaborowski wrote: Hi, If the only argument for adding GGI is so that you don't have to install libsdl, then does that mean that we should have an X11, fbdev, etc. backend for people who don't have GGI installed? I think a GGI back-end would be useful. I wouldn't mind also having other back-ends even if SDL supports them (e.g. there's an Xlib patch for qemu, it is very little code compared to vnc.c which you could say duplicates code already present in libraries). The situation is the same with audio backends: there's oss, alsa and SDL which can do both oss and alsa but works poorly. Unrelated to this discussion on slow links VNC is much more usable with the Xlib patch and Xvnc than through the built-in VNC (I think it makes a better decision on what format to use based on the connection speed). It's probably just the lack of a compressed encoding. Regards, Anthony Liguori Regards, Andrew
Re: [Qemu-devel] U-Boot patch for qemu -M mips
Thiemo Seufer wrote:
Vlad Lungu wrote:
[snip]
+long int initdram(int board_type)
+{
+ /* Sdram is setup by assembler code */
+ /* If memory could be changed, we should return the true value
here */
+ return MEM_SIZE*1024*1024;
Qemu gets the amount of RAM passed via a command line switch, the
qemu-mips emulation sets up a Linux kernel like "command line" in
memory where u-boot could parse it from.
Does it, or just when you pass -kernel to it? I'll check.
Hm, you are right, it does that only for -kernel. Would it make sense
to change that in Qemu?
IDK. Maybe I can probe the RAM size in U-Boot , or if this does not
work, put some info somewhere (RAM, register,
emulated DIP-dwitch), like RAM size, endianness of the CPU.
Since the mips_r4k machine doesn't correspond to any real hardware we
have a bit of leeway with the "hardware" design.
+}
+
+
+int checkboard (void)
+{
+ u32 proc_id;
+
+ proc_id = read_32bit_cp0_register(CP0_PRID);
+
+ switch (proc_id >> 24) {
+ default:
+ printf ("Unsupported cpu %d, proc_id=0x%x\n", proc_id >>
24, proc_id);
+ }
+
+ return 0;
+}
Huh? What is this code good for?
Checking for the type of board, I suppose :-) I think all BSPs have it and
it's called early in the boot process. I could either do only a return 0 or
actually decode CP0_PRID and print something meaningful, if Qemu sets it to
something sensible. Or just print a nice banner.
As it is, this code prints a nice "Unsupported CPU" banner no matter what
(and proceeds anyway instead of bailing out).
True, because it does not care much about this at the moment. Nor do I.
But that can change.
Latest CVS Qemu supports a number of different CPUs (see the -cpu switch),
the default for 32 bit is a 24Kf, and for 64 bit a R4000.
I'll look into this and see what use can we make of CP0_PRID.
Vlad
Re: [Qemu-devel] U-Boot patch for qemu -M mips
Vlad Lungu wrote:
[snip]
>>> +long int initdram(int board_type)
>>> +{
>>> + /* Sdram is setup by assembler code */
>>> + /* If memory could be changed, we should return the true value
>>> here */
>>> + return MEM_SIZE*1024*1024;
>>>
>>
>> Qemu gets the amount of RAM passed via a command line switch, the
>> qemu-mips emulation sets up a Linux kernel like "command line" in
>> memory where u-boot could parse it from.
>>
>>
> Does it, or just when you pass -kernel to it? I'll check.
Hm, you are right, it does that only for -kernel. Would it make sense
to change that in Qemu?
Since the mips_r4k machine doesn't correspond to any real hardware we
have a bit of leeway with the "hardware" design.
>>> +}
>>> +
>>> +
>>> +int checkboard (void)
>>> +{
>>> + u32 proc_id;
>>> +
>>> + proc_id = read_32bit_cp0_register(CP0_PRID);
>>> +
>>> + switch (proc_id >> 24) {
>>> + default:
>>> + printf ("Unsupported cpu %d, proc_id=0x%x\n", proc_id >>
>>> 24, proc_id);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>>
>>
>> Huh? What is this code good for?
>>
>>
> Checking for the type of board, I suppose :-) I think all BSPs have it and
> it's called early in the boot process. I could either do only a return 0 or
> actually decode CP0_PRID and print something meaningful, if Qemu sets it to
> something sensible. Or just print a nice banner.
As it is, this code prints a nice "Unsupported CPU" banner no matter what
(and proceeds anyway instead of bailing out).
Latest CVS Qemu supports a number of different CPUs (see the -cpu switch),
the default for 32 bit is a 24Kf, and for 64 bit a R4000.
Thiemo
[Qemu-devel] Re: using pthread in qemu
On Wednesday 03 October 2007 13:04:33 you wrote: > hi! > i know... i have been told not to use them, but i just HAVE TO for the > moment :-( > > i need to run a second thread inside my hardware module which is not a > problem as long as i don't use the qcow2 image format. when i switch to > qcow2, qemu's main thread hangs because the second thread is waiting for a > semaphore... > > does anyone know how to tell the second pthread not to block the primary > thread?? > > as always --- any help is greatly appreciated!! > Clemens ok... i solved my problem using the qemu_timers works just fine ;-)
Re: merge GGI support? [was: Re: [Qemu-devel] [RFC] CRIS target port]
Hi, On 02/10/2007, Anthony Liguori <[EMAIL PROTECTED]> wrote: > Bernhard Fischer wrote: > > On Tue, Oct 02, 2007 at 03:09:41PM -0500, Anthony Liguori wrote: > > > >> Bernhard Fischer wrote: > >> > >>> On Tue, Oct 02, 2007 at 01:45:39PM -0500, Anthony Liguori wrote: > >>> > >>> > What does one gain with GGI support? I've never seen a good answer to > this. > > > >>> GGI supports a number of display-targets: > >>> http://www.ggi-project.org/targets.html > >>> umong them X11, quartz, directx, fbdev, vgl, vnc, wsfb, libaa, > >>> terminfo, cocoa, etc. > >>> > >>> > >> SDL has a GGI backend. So you can already use GGI with QEMU. > >> > >> So, what does it buy to have QEMU use GGI directly? > >> > > > > Well, I don't have SDL. What did it buy to add VNC support and cocoa > > support when there was already GGI support and GGI has backends for VNC > > and cocoa? ;) > > > > I can't comment about cocoa but the GGI support for VNC isn't very > good. Plus, I wanted to add new VNC extensions for virtualization. I think it's the same way with other back-ends - you can do more things if you talk to them directly instead of through SDL. > > If the only argument for adding GGI is so that you don't have to install > libsdl, then does that mean that we should have an X11, fbdev, etc. > backend for people who don't have GGI installed? I think a GGI back-end would be useful. I wouldn't mind also having other back-ends even if SDL supports them (e.g. there's an Xlib patch for qemu, it is very little code compared to vnc.c which you could say duplicates code already present in libraries). The situation is the same with audio backends: there's oss, alsa and SDL which can do both oss and alsa but works poorly. Unrelated to this discussion on slow links VNC is much more usable with the Xlib patch and Xvnc than through the built-in VNC (I think it makes a better decision on what format to use based on the connection speed). Regards, Andrew
Re: [Qemu-devel] using pthread in qemu
Hi, On 03/10/2007, Clemens Kolbitsch <[EMAIL PROTECTED]> wrote: > hi! > i know... i have been told not to use them, but i just HAVE TO for the > moment :-( > > i need to run a second thread inside my hardware module which is not a problem > as long as i don't use the qcow2 image format. when i switch to qcow2, qemu's > main thread hangs because the second thread is waiting for a semaphore... > > does anyone know how to tell the second pthread not to block the primary > thread?? Maybe this thread can be helpful: http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00090.html Regards, Andrew
Re: [Qemu-devel] Build failure on OS X
Am 30.09.2007 um 17:54 schrieb Andreas Färber: Am 30.09.2007 um 17:05 schrieb Andreas Färber: Am 30.09.2007 um 16:37 schrieb J. Mayer: If someone has a speedup idea for the __APPLE__ case, that could still be applied separately. I guess there are some already defined macros in the Apple build environmnet that should be used instead. But I don't know too much about this environment... The slowdown is really not an issue in that particular case. Actually, I am now seeing that in math.h Apple itself uses __attribute__ ((always_inline)) for __MATH_H_ALWAYS_INLINE__ if __GNUC__ is defined ... so I now believe the issue is rather the "recursive" definition of always_inline: QEMU defines always_inline and it subsequently tries to replace always_inline inside the __attribute__(()) in math.h! Could this be it? Puzzling, the attached patch works. It appears to be the trailing inline that it doesn't like for some reason. Just scratch it... On second tests it doesn't work at all, I could've sworn I did make distclean before building...
[Qemu-devel] using pthread in qemu
hi! i know... i have been told not to use them, but i just HAVE TO for the moment :-( i need to run a second thread inside my hardware module which is not a problem as long as i don't use the qcow2 image format. when i switch to qcow2, qemu's main thread hangs because the second thread is waiting for a semaphore... does anyone know how to tell the second pthread not to block the primary thread?? as always --- any help is greatly appreciated!! Clemens
[Qemu-devel] sh4: system emulator - interrupt controller
Hi everyone, Attached is a patch that implements a table driver interrupt controller for the sh architecture. The tables that describes the registers and interrupt sources are very similar to the linux kernel code that I rewrote recently. Included are tables for sh775x but it should be fairly easy to add tables for other cpu models in the future if needed. Only registers are hooked up to the cpu for now. No interrupts are delivered to the processor yet, but the association between register bit fields and interrupt sources works well. People that want to play with this can uncomment DEBUG_INTC in sh_intc.c to get printouts when the kernel enables various interrupt sources during boot. I'm going to continue working on this to hook up the processor, timers and serial ports as well. This is at least a good first step to share with the community. Please apply. / magnus qemu-cvs-20071003-sh-intc.patch Description: Binary data
Re: [Qemu-devel] U-Boot patch for qemu -M mips
Thiemo Seufer wrote:
Vlad Lungu wrote:
Fix for mips GOT relocation bug, NE2000 bugs, add support for qemu -M mips
target.
[snip]
diff --git a/board/qemu-mips/config.mk b/board/qemu-mips/config.mk
[snip]
+#
+# AMD development board AMD Alchemy DbAu1x00, MIPS32 core
Incorrect comment.
didn't spot that
+#
+
+# ROM version
+TEXT_BASE = 0xbfc0
+
+# RAM version
+#TEXT_BASE = 0x8010
This could be as low as 0x80001000 (assuming the space for exception
handlers isn't reserved by other means).
I think I saw that difference in Linux 2.6 too. I suppose you're right.
[snip]
diff --git a/board/qemu-mips/lowlevel_init.S b/board/qemu-mips/lowlevel_init.S
new file mode 100644
index 000..855e8ab
--- /dev/null
+++ b/board/qemu-mips/lowlevel_init.S
@@ -0,0 +1,47 @@
+/* Memory sub-system initialization code */
+
+#include
+#include
+#include
+#include
+
+ .text
+ .set noreorder
+ .set mips32
+
+ .globl lowlevel_init
+lowlevel_init:
+
+ /*
+* Step 2) Establish Status Register
+* (set BEV, clear ERL, clear EXL, clear IE)
+*/
+ li t1, 0x0040
+ mtc0t1, CP0_STATUS
+
+ /*
+* Step 3) Establish CP0 Config0
+* (set OD, set K0=3)
+*/
+ li t1, 0x00080003
+ mtc0t1, CP0_CONFIG
OD is a processor-specific flag, it does nothing on Qemu.
+ /*
+* Step 5) Disable the performance counters
+*/
+ mtc0zero, CP0_PERFORMANCE
+ nop
This field isn't required to exist (as per architecture spec), which
means you can get an exception when writing it. Since perfctr
interrupts are guaranteed to be disabled, the best option is not to
touch the register in early startup code.
(If you want to use performance counters, first check via the config
registers if they are implemented. You won't have much luck on Qemu:
The registers are implemented, but they don't do anything useful.)
Well, I didn't get any exception . And nobody complained about OD
either. The stuff that barfed on me, I deleted right away.
I'll delete this too, no problem.
+ /*
+* Step 7) Establish Cause
+* (set IV bit)
+*/
+ li t1, 0x0080
+ mtc0t1, CP0_CAUSE
+
+ /* Establish Wired (and Random) */
+ mtc0zero, CP0_WIRED
+ nop
+
+ j ra
+ nop
diff --git a/board/qemu-mips/qemu-mips.c b/board/qemu-mips/qemu-mips.c
new file mode 100644
index 000..76c093c
--- /dev/null
+++ b/board/qemu-mips/qemu-mips.c
@@ -0,0 +1,48 @@
+/*
+ * (C) Copyright 2007
+ * [EMAIL PROTECTED]
A name in addition would look nicer. :-)
Names are so passe :-)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+long int initdram(int board_type)
+{
+ /* Sdram is setup by assembler code */
+ /* If memory could be changed, we should return the true value here */
+ return MEM_SIZE*1024*1024;
Qemu gets the amount of RAM passed via a command line switch, the
qemu-mips emulation sets up a Linux kernel like "command line" in
memory where u-boot could parse it from.
Does it, or just when you pass -kernel to it? I'll check.
+}
+
+
+int checkboard (void)
+{
+ u32 proc_id;
+
+ proc_id = read_32bit_cp0_register(CP0_PRID);
+
+ switch (proc_id >> 24) {
+ default:
+ printf ("Unsupported cpu %d, proc_id=0x%x\n", proc_id >> 24,
proc_id);
+ }
+
+ return 0;
+}
Huh? What is this code good for?
Checking for the type of board, I suppose :-) I think all BSPs have it
and it's called early in the boot process. I could either do only a
return 0 or actually decode CP0_PRID and print something meaningful, if
Qemu sets it to something sensible. Or just print a nice banner.
Thanks for the input. This is a first version and it does what it's
supposed to do, it booted in qemu HEAD on linux-x86 and in stock 0.90
for Windows and loaded a linux kernel via dhcp/tftp, nfs, ext2 and fat
partitions on IDE.
Re: [Qemu-devel] Hard disk support is broken in Windows 98SE guest
Hello, >>> On 10/2/2007 at 7:43 PM, in message <[EMAIL PROTECTED]>, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > I don't have such a system for tests. Can you narrow down which CVS > commit broke it? hw/ide.c 1.64 works, version 1.65 doesn't. Only BIOS operations seems to be affected, so it may be BIOS fault after all. You can use FreeDOS for testing, it doesn't install too. Victor Shkamerda -- --- -- LIMITARE DE OBLIGATIUNI: Mesajele expediate din cadrul Bancii Nationale a Moldovei sunt transmise cu buna intentie si nu trebuie considerate drept obligatorii in activitatea acestei organizatii. Informatia transmisa este destinata doar pentru adresat si poate contine date confidentiale si / sau privilegiate. In caz ca primiti mesajul dat din greseala, va rugam sa contactati expeditorul si sa stergeti informatia in cauza din computerul Dvs. DISCLAIMER: Any e-mail messages from the National Bank of Moldova are sent in good faith, but shall not be binding nor construed as constituting any obligation on the part of the Bank. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
