Re: [Qemu-devel] Block driver and constant sector size

[Jonathan Phenix]

Paul Brook wrote:

On Saturday 12 May 2007, Jonathan Phenix wrote:
  

Hi,

currently the block driver in qemu only handles blocks (or sectors)
which are 512 bytes long, 
...

Then, each probe functions should be modified to reject sector size
which is not 512 bytes, except for the raw block driver, which will be
modified to accept any block sizes. This change would probably solve the
whole problem without having a negative impact on the rest of the code.

Is it the right way to solve the problem? If this solution is accepted,
I will code it and submit a patch.



Seems like it might just be simpler to have the qemu block ABI use bytes 
rather than blocks. Maybe with some common helper functions for doing R/M/W 
on hard sectored devices.


By adding variable sized sectors you're just shifting complexity from the 
block backends to the device emulation.
  
No, it will not add complexity at all to the device emulation code, 
perhaps I was not clear enough on what I was trying to describe. 
Basically, the only change that would be needed to existing users of the 
block driver is to change bdrv_new(...) to bdrv_new(..., 512) (it 
could be also done with bdrv_open instead) and that's it. The only 
other difference that the user code will see is that the buffer required 
by bdrv_read, bdrv_write and friends must now be a multiple of the size 
requested before, but that's to be expected. The block driver will 
continue to deal with sectors as a base unit.


As for internal changes in the block driver, a new variable, let's call 
it requested_sector_size will be added to the probe function of each 
driver as well as the BlockDriver structure. We can simply do if 
(requested_sector_size != 512) return 0; for all existing drivers for 
now in their probe functions and implement it in the future if required. 
I will add support for a sector_size that is different than 512 in the 
raw driver, the image file produced by cdrdao is in raw format. Other 
popular CD ripping tools for Windows also creates raw images, with very 
slight variations, as far as I know.


Sounds good?

Regards,

Jonathan Phénix

Paul
  

Re: [Qemu-devel] [PATCH] Joystick API

[Jonathan Phenix]

Jonathan Phenix wrote:

Hi,

this is an attempt to add a simple joystick API to qemu. This API will 
be required for my upcoming Playstation emulator. It includes a null 
driver, I have a Linux and SDL driver as well, I will send them when 
this patch will be merged. Constructive comments are welcome.
No comment were posted about the patch and it was not committed in CVS, 
is it going to be done or some modifications are required? I can produce 
a patch that will include both the new subsystem as well as the 2 real 
drivers if needed.


Regards,

Jonathan Phénix

[Qemu-devel] Block driver and constant sector size

[Jonathan Phenix]

Hi,

currently the block driver in qemu only handles blocks (or sectors) 
which are 512 bytes long, this is ideal if the device you are emulating 
have a block size which is a multiple of 512. Unfortunately, this is not 
always the case, for example an audio CD (CD-DA) or a CD in mode 2 have 
a sector size of 2352, which is not a multiple of 512. Typical data CD 
are encoded in mode 1 with an ISO9660 file system, and this mode uses a 
sector size of 2048, which is a multiple of 512, this is the reason why 
the problem probably didn't come up yet. You can dump about any CDs in 
mode 2 under Linux with the cdrdao read-cd --read-raw [...] command 
for example.


In order to let the block driver read these raw images, I would like to 
change:


BlockDriverState *bdrv_new(const char *device_name);

to:

BlockDriverState *bdrv_new(const char *device_name, int sector_size);

and change:

int (*bdrv_probe)(const uint8_t *buf, int buf_size, const char *filename);

of the BlockDriver structure to:

int (*bdrv_probe)(const uint8_t *buf, int buf_size, const char 
*filename, int sector_size);


Then, each probe functions should be modified to reject sector size 
which is not 512 bytes, except for the raw block driver, which will be 
modified to accept any block sizes. This change would probably solve the 
whole problem without having a negative impact on the rest of the code.


Is it the right way to solve the problem? If this solution is accepted, 
I will code it and submit a patch.


Regards,

Jonathan Phénix

[Qemu-devel] [PATCH] Joystick API

[Jonathan Phenix]

Hi,

this is an attempt to add a simple joystick API to qemu. This API will 
be required for my upcoming Playstation emulator. It includes a null 
driver, I have a Linux and SDL driver as well, I will send them when 
this patch will be merged. Constructive comments are welcome.


Regards,

Jonathan Phénix


diff -urN --exclude CVS qemu/joystick/joystick.c qemu-joystick/joystick/joystick.c
--- qemu/joystick/joystick.c	1969-12-31 19:00:00.0 -0500
+++ qemu-joystick/joystick/joystick.c	2007-05-10 19:21:07.0 -0400
@@ -0,0 +1,148 @@
+/*  QEMU joystick API
+ *
+ *  Copyright (C) 2007 Jonathan Phénix
+ *
+ *  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 joystick_int.h
+
+static const JoyDriver *joy_driver_table[] = {
+#if 0
+#ifdef CONFIG_JOY_LINUX
+joy_driver_linux,
+#endif
+#ifdef CONFIG_SDL
+joy_driver_sdl,
+#endif
+#endif
+joy_driver_null,
+NULL,
+};
+
+JoyState *qemu_joy_init(JoyButtonCB but_cb, JoyAxisCB axis_cb, void *opaque)
+{
+const JoyDriver **ptr;
+JoyState *s;
+
+#ifdef JOY_SAFE
+if (!but_cb || !axis_cb)
+return NULL;
+#endif
+
+ptr = joy_driver_table;
+
+while (*ptr) {
+if ((*ptr)-probe() == JOY_OK)
+break;
+ptr++;
+}
+
+if (!ptr) {
+/* This should never happens, the null driver should catch it but we are never too careful */
+qemu_joy_log(%s: No suitable joystick driver\n, __func__);
+qemu_free(s);
+return NULL;
+}
+
+s = qemu_mallocz(sizeof(*s) + (*ptr)-size);
+if (!s)
+return NULL;
+
+s-driver = *ptr;
+
+s-joy_but_cb = but_cb;
+s-joy_axis_cb = axis_cb;
+s-cb_opaque = opaque;
+
+s-driver-init(s);
+
+return s;
+}
+
+JoyError qemu_joy_open(JoyState *s, unsigned int devno)
+{
+#ifdef JOY_SAFE
+if (devno = JOY_MAX || !s)
+return JOY_EINVAL;
+#endif
+return s-driver-open(s, devno);
+}
+
+JoyError qemu_joy_close(JoyState *s, unsigned int devno)
+{
+#ifdef JOY_SAFE
+if (devno = JOY_MAX || !s)
+return JOY_EINVAL;
+#endif
+
+return s-driver-close(s, devno);
+}
+
+JoyError qemu_joy_get_info(JoyState *s, unsigned int devno, JoyInfo *info)
+{
+#ifdef JOY_SAFE
+if (devno = JOY_MAX || !s || !info)
+return JOY_EINVAL;
+#endif
+
+memset(info, 0, sizeof(*info));
+
+return s-driver-get_info(s, devno, info);
+}
+
+unsigned int qemu_joy_nr(JoyState *s)
+{
+#ifdef JOY_SAFE
+if (!s)
+return 0;
+#endif
+
+return s-driver-nr(s);
+}
+
+void qemu_joy_flush(JoyState *s)
+{
+#ifdef JOY_SAFE
+if (!s)
+return;
+#endif
+
+if (s-driver-flush)
+s-driver-flush(s);
+}
+
+void qemu_joy_enable(JoyState *s)
+{
+#ifdef JOY_SAFE
+if (!s)
+return;
+#endif
+
+if (s-driver-enable)
+s-driver-enable(s);
+}
+
+extern FILE *logfile;
+
+void qemu_joy_log(const char *fmt, ...)
+{
+va_list ap;
+
+va_start(ap, fmt);
+vfprintf(logfile ? logfile : stderr, fmt, ap);
+va_end(ap);
+}
+
diff -urN --exclude CVS qemu/joystick/joystick.h qemu-joystick/joystick/joystick.h
--- qemu/joystick/joystick.h	1969-12-31 19:00:00.0 -0500
+++ qemu-joystick/joystick/joystick.h	2007-05-10 19:14:08.0 -0400
@@ -0,0 +1,84 @@
+/*  QEMU joystick API
+ *
+ *  Copyright (C) 2007 Jonathan Phénix
+ *
+ *  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
+ */
+
+#ifndef __JOYSTICK_H__
+#define __JOYSTICK_H__
+
+#include vl.h
+
+typedef struct JoyState JoyState;
+
+typedef void (*JoyButtonCB)(void *opaque, unsigned int devno, uint8_t button, int down);
+typedef void (*JoyAxisCB)(void *opaque, unsigned 

Re: [Qemu-devel] [patch] factor out commonly used scancode translation table

[Jonathan Phenix]

Bernhard Fischer wrote:

Hi,

The attached patch moves the x_keycode_to_pc_keycode LUT from sdl.c into
an x_keycode.c. This struct is also used by the GGI backend (that is not
yet merged ¹).

Comments?
  
How it is done right now, each time x_keycode.c is included, you will 
end up with an extra copy in the final executable. Perhaps that simply 
keeping the LUT in sdl.c but removing the 'static' keyword from it and 
creating a sdl.h file with the statement:


extern const uint8_t *x_keycode_to_pc_keycode;

would be a better idea. Including a header file is more clean than 
including a C file as well.

Please apply.

¹)
http://members.aon.at/berny_f/qemu/qemu-HEAD.ggi-2.2.x-04c-20070104.diff
___
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] Question/problems with Qemu and 64Bit Opensuse 10.2

[Jonathan Phenix]

Werner Dittmann wrote:

Just forgot to give the info about my system:

Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also,
while compiling Qemu I got quite some warning about casting pointers to
integer of different size (64bit vs 32 bit). Is this ok?
  
I'm using Fedora Core 5 x86_64 with qemu 0.8.2 and I have noticed these 
warnings as well. However, they do not seem to be a problem, at least 
for what I'm currently doing, developing a new system on top of qemu. 
They seem to be casts from void * to int, which is OK on x86 but 
generate a warning on x86_64 since sizeof(void *) != sizeof(int) on that 
platform.


I other words, I doubt that these warnings are the source of the problem.

Regards,

Jonathan


Regards,
Werner

Werner Dittmann wrote:
  

All,

currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu.

Using a plain 0.82 didn't work out, after the Install screen Qemu goes
in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc).
I could not even stop Qemu but had to use kill -9 .
Because of some mail in the list that reported similar errors I
downloaded the latest CVS version and built it using a gcc 3.3.

That didn't solve the problem: It seems to be in a loop but I can close
the qemu window and the window also grabs the mouse cursor (that was not
the case  with the 0.8.2 version).

After loading the kernel I get the following message on the console
(only in VESA mode):


Decompressing Linux ... done.
Booting the kernel.


and at the bottom of the console screen the message (without the qutes):

kernel direct mapping tables up to 1 @ 8000-d000

I tried to switch on some -d but I don't know which one is relevant
here. I tried -d int but this produced about 90MB log data in just
some seconds.

Which info do you need to get down to the problem? What can I try to
tackle the problem?

Regards,
Werner

PS: Because I'm somewhat experienced with security software I would ask
if there is any interest to have a TPM module (Software based TPM) for
Qemu that looks like a real HW TPM according the the TPM specs? If yes I
would start to look how to do it for Qemu. There is a software based TPM
avaliable with a GPL licence. The only thing to do would be to wrap it
with the HW interface functions (it's a memory mapped interface) so that
standard drivers would see it as standard TPM module.

Werner




___
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 mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] SMP Question

[Jonathan Phenix]

maple Chou wrote:

Dear All,
 I just doing my floppy toy-os project(include little bootloader). And 
test with qemu.

The Floppy Image is here  http://file.maple.tw/mapleos/floppy.img

My problem is when I turn on the SMP option. (qemu -fda floppy.img -smp 2)
The system will hang on bootsector (i just watch qemu monitor hang on 
0x7eca)


And some problem with Grub+floppy image.
Grub+HD image boot successful, but can't capture the keyboard.

What's problem!?? i only run SMP case successful with linux kernel.
For your project, qemu should be considered a _tool_. Like all tools, 
you must know it's usefulness (it's easier to debug your OS on an 
emulator) but you must be very well aware that all emulators are 
accurate only up to a certain point of the actual system emulated. This 
is not to mention that qemu is not yet complete (latest official release 
is 0.8.2), there are known bugs and unimplemented features that could 
always be the source of the problem. Finally, even if qemu is able to 
boot many common SMP enabled OSes, it's not a guarantee that everything 
is perfect related to SMP in qemu.


If you believe that your code is correct and this is a bug in qemu, 
which is always possible, try with different PC emulators to see if 
there is a difference. The best thing to do is to actually test on a 
real SMP system, real hardware have a final say on what should work and 
what doesn't.


Finally, developing an OS is not a small task, perhaps you should focus 
on single processor systems first which are a lot easier to design and 
debug for and then focus on SMP systems later on.


Regards,

- Jonathan


Best Regards

  ~maple


___
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