Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[François Revol]

On 23/07/2013 14:19, Paolo Bonzini wrote:
 Il 22/07/2013 20:21, Peter Maydell ha scritto:
   Platforms without ISA and/or PCI have had a seriously hard time in 
   the dynamic
   device creation world of QEMU. Devices on these were modeled as 
   SysBus devices
   which can only be instantiated in machine files, not through -device.
  
   Why is that so?
  Because you can't as a user of this sort of hardware
  plug in an extra serial port to a SoC, because there's just nowhere
  to plug it in. So why should it be possible to plug an extra
  serial port into the QEMU model of the SoC?
 And why exactly should QEMU be limited to modeling an existing SoC?
 
 Perhaps the user is not working with an existing SoC.  They are working
 with with IP building blocks that they can combine the way they prefer,
 and they haven't yet made up their mind on the exact set of devices
 they'll have.  (because not all the world is a PC, but then not all the
 non-PC world is ARM either).
 
 Perhaps the user is working on kernel support for device tree / ACPI,
 wants to test many device combinations, and does not want to touch C
 code in order to do that.

For what it's worth, ont sure it matters here, but the Sam460ex (PPC)
(I've been writing code to support it recently) has an FDT, and a PCI
controller...
And there is a firmware setting to switch between the 2nd SATA port and
the PCI-e slot as they are mutually exclusive...

François.

Re: [Qemu-devel] Using TRIM to shrink qcow2 images

[François Revol]

On 08/08/2013 12:34, Ralf Ramsauer wrote:
 Hi,
 
 QCOW2 uses a similar idea like file holes (sparse files) on filesystems [1].
 RAW Images also may use file holes.
 
 If qemu would support TRIM, then the guest could easily discard and zero
 all unused blocks.
 The host system could detect all unused blocks in a (e.g.) qcow2 image
 and shrink it down to its minimum size.
 
 Did anyone already think about that?
 

Yes but no time to implement.


I believe VirtualBox has some support for TRIM already btw.

François.

[Qemu-devel] [PATCH] HDA: Honor WAKEEN bits when deciding to raise an interrupt on codec status

[François Revol]

From 2e6c61248c76d3f0c511658b9f34660d034703a4 Mon Sep 17 00:00:00 2001

HDA: Honor WAKEEN bits when deciding to raise an interrupt on codec status 
change.
This prevents an interrupt storm with the Haiku HDA driver which does not 
handle codec status changes in the irq handler.


Signed-off-by: François Revol re...@free.fr
---
 hw/intel-hda.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/intel-hda.c b/hw/intel-hda.c
index ccb059d..f1bd203 100644
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -235,7 +235,7 @@ static void intel_hda_update_int_sts(IntelHDAState *d)
 if (d-rirb_sts  ICH6_RBSTS_OVERRUN) {
 sts |= (1  30);
 }
-if (d-state_sts) {
+if (d-state_sts  d-wake_en) {
 sts |= (1  30);
 }
 
@@ -617,6 +617,7 @@ static const struct IntelHDAReg regtab[] = {
 [ ICH6_REG_WAKEEN ] = {
 .name = WAKEEN,
 .size = 2,
+.wmask= 0x3fff,
 .offset   = offsetof(IntelHDAState, wake_en),
 },
 [ ICH6_REG_STATESTS ] = {
-- 
1.7.2.2

[Qemu-devel] [PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Initial implementation of a mpeg1 layer2 streaming audio driver.
It is based on the twolame library http://www.twolame.org/.
It allows one to listen to the audio produced by a VM from an mp3 http 
streaming client.
I just noticed esdaudio.c which I used as template on was under BSD licence, 
which is fine by me for this one as well.
For now it almost works with a Haiku guest (with HDA at 22050Hz and the WAKEEN 
patch I just sent), except with a 1min delay and missing frames, so it's 
possible buffers get queued up somewhere.


From 759ce26b14b7c9c5a24fba43b01cfb5d335086be Mon Sep 17 00:00:00 2001

Initial implementation of a mpeg1 layer2 streaming audio driver.
It is based on the twolame library http://www.twolame.org/.
Added a check for libtwolame to configure.


Signed-off-by: François Revol re...@free.fr
---
 Makefile.objs|1 +
 audio/audio.c|3 +
 audio/audio_int.h|1 +
 audio/twolameaudio.c |  393 ++
 configure|   20 +++
 5 files changed, 418 insertions(+), 0 deletions(-)
 create mode 100644 audio/twolameaudio.c

diff --git a/Makefile.objs b/Makefile.objs
index faf485e..370d59a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -109,6 +109,7 @@ audio-obj-$(CONFIG_FMOD) += fmodaudio.o
 audio-obj-$(CONFIG_ESD) += esdaudio.o
 audio-obj-$(CONFIG_PA) += paaudio.o
 audio-obj-$(CONFIG_WINWAVE) += winwaveaudio.o
+audio-obj-$(CONFIG_TWOLAME) += twolameaudio.o
 audio-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o
 audio-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o
 audio-obj-y += wavcapture.o
diff --git a/audio/audio.c b/audio/audio.c
index ad51077..0c2c304 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -46,6 +46,9 @@
 static struct audio_driver *drvtab[] = {
 CONFIG_AUDIO_DRIVERS
 no_audio_driver,
+#ifdef CONFIG_TWOLAME
+twolame_audio_driver,
+#endif
 wav_audio_driver
 };
 
diff --git a/audio/audio_int.h b/audio/audio_int.h
index d8560b6..337188b 100644
--- a/audio/audio_int.h
+++ b/audio/audio_int.h
@@ -210,6 +210,7 @@ extern struct audio_driver dsound_audio_driver;
 extern struct audio_driver esd_audio_driver;
 extern struct audio_driver pa_audio_driver;
 extern struct audio_driver winwave_audio_driver;
+extern struct audio_driver twolame_audio_driver;
 extern struct mixeng_volume nominal_volume;
 
 void audio_pcm_init_info (struct audio_pcm_info *info, struct audsettings *as);
diff --git a/audio/twolameaudio.c b/audio/twolameaudio.c
new file mode 100644
index 000..e121a91
--- /dev/null
+++ b/audio/twolameaudio.c
@@ -0,0 +1,393 @@
+/*
+ * QEMU twolame streaming audio driver
+ *
+ * Copyright (c) 2010 François Revol re...@free.fr
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include config-host.h
+#include qemu-common.h
+#include qemu-char.h
+#include qemu_socket.h
+#include audio.h
+
+#define AUDIO_CAP twolame
+#include audio_int.h
+#include audio_pt_int.h
+
+#include twolame.h
+
+typedef struct {
+HWVoiceOut hw;
+int done;
+int live;
+int decr;
+int rpos;
+void *pcm_buf;
+void *mpg_buf;
+int lsock;
+int fd;
+struct audio_pt pt;
+twolame_options *options;
+} LAMEVoiceOut;
+
+static struct {
+int samples;
+int divisor;
+int port;
+int rate;
+} conf = {
+.samples = 1024,
+.divisor = 2,
+.port = 8080,
+.rate = 160
+};
+
+static const char http_header[] = HTTP/1.1 200 OK\r\nServer: 
QEMU\r\nContent-Type: audio/mpeg\r\n\r\n;
+
+static void GCC_FMT_ATTR (2, 3) qtwolame_logerr (int err, const char *fmt, ...)
+{
+va_list ap;
+
+va_start (ap, fmt);
+AUD_vlog (AUDIO_CAP, fmt, ap);
+va_end (ap);
+
+AUD_log (AUDIO_CAP, Reason: %s\n, strerror (err));
+}
+
+static void qtwolame_listen_read(void *opaque)
+{
+LAMEVoiceOut *twolame = opaque;
+struct sockaddr_in addr;
+socklen_t addrlen = sizeof(addr);
+
+if (twolame-fd  -1)
+return;
+
+int csock = qemu_accept

Re: [Qemu-devel] [PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Le 7 nov. 2010 à 19:09, malc a écrit :

 On Sun, 7 Nov 2010, Fran?ois Revol wrote:
 
 Please CC audio related stuff to audio maintainer.

And that'd be you according to MAINTAINERS ?

 +static const char http_header[] = HTTP/1.1 200 OK\r\nServer: 
 QEMU\r\nContent-Type: audio/mpeg\r\n\r\n;
 
 Line is too long.

Ok I'll break at 80col.

 +if (twolame-fd  -1)
 +return;
 
 Style.

That is ?

 +
 +int csock = qemu_accept(twolame-lsock, (struct sockaddr *)addr, 
 addrlen);
 
 C99 intermixed declartion and initialization is not allowed.

This line I copied form ui/vnc.c which does violate C89 too btw...

 +
 +again:
 +if (twolame-fd  -1) {
 +written = write (twolame-fd, twolame-mpg_buf, converted);
 +if (written == -1) {
 +if (errno == EPIPE) {
 +dolog (Lost peer\n);
 +close (twolame-fd);
 +twolame-fd = -1;
 +goto again;
 
 This goto is obfuscated.

Not much more than in esdaudio.c



 +}
 +obt_as.endianness = AUDIO_HOST_ENDIANNESS;
 +
 +audio_pcm_init_info (hw-info, obt_as);
 +
 +twolame_set_mode(twolame-options, (as-nchannels == 2) ? 
 TWOLAME_STEREO : TWOLAME_MONO);
 +twolame_set_num_channels(twolame-options, as-nchannels);
 +twolame_set_in_samplerate(twolame-options, as-freq);
 +twolame_set_out_samplerate(twolame-options, as-freq);
 +twolame_set_bitrate(twolame-options, 160); //XXX:conf.
 +
 +if (twolame_init_params(twolame-options)) {
 +dolog (Could not set twolame options\n);
 +return -1;
 +}
 
 Inconsistent space before opening paren.

Sorry, used to the Haiku style without space before but it seemed to be 
different around.


 +twolame-mpg_buf = audio_calloc (AUDIO_FUNC, hw-samples, 1  
 hw-info.shift);
 +if (!twolame-mpg_buf) {
 
 pcm_buf is not freed.
 
 +
 +// fail1:
 
 Do not use C99 style comments.

Oh that's leftover from copied error handling, which isn't correct anyway.

François.

[Qemu-devel] [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Initial implementation of a mpeg1 layer2 streaming audio driver.
2nd try: Style  other fixes from malc's comments.
It is based on the twolame library http://www.twolame.org/.
Since twolame is very similar to lame (on purpose), one might easily create a 
lame version from it for better quality.
It allows one to listen to the audio produced by a VM from an mp3 http 
streaming client (layer2 is compatible).
I noticed esdaudio.c which I used as template on was under BSD licence, which 
is fine by me for this one as well.
For now it almost works with a Haiku guest (with HDA at 22050Hz and the WAKEEN 
patch I just sent), except with a 20s delay and missing frames, so it's 
possible buffers get queued up somewhere.

From ee55900f8ceb86a96878a60086e8a4da19c645a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= re...@free.fr
Date: Mon, 8 Nov 2010 00:01:43 +0100
Subject: [PATCH] Initial implementation of a mpeg1 layer2 streaming audio 
driver.
 It is based on the twolame library http://www.twolame.org/.
 - added a check for libtwolame to configure.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


Signed-off-by: François Revol re...@free.fr
---
 Makefile.objs|1 +
 audio/audio.c|3 +
 audio/audio_int.h|1 +
 audio/twolameaudio.c |  417 ++
 configure|   20 +++
 5 files changed, 442 insertions(+), 0 deletions(-)
 create mode 100644 audio/twolameaudio.c

diff --git a/Makefile.objs b/Makefile.objs
index faf485e..370d59a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -109,6 +109,7 @@ audio-obj-$(CONFIG_FMOD) += fmodaudio.o
 audio-obj-$(CONFIG_ESD) += esdaudio.o
 audio-obj-$(CONFIG_PA) += paaudio.o
 audio-obj-$(CONFIG_WINWAVE) += winwaveaudio.o
+audio-obj-$(CONFIG_TWOLAME) += twolameaudio.o
 audio-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o
 audio-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o
 audio-obj-y += wavcapture.o
diff --git a/audio/audio.c b/audio/audio.c
index ad51077..0c2c304 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -46,6 +46,9 @@
 static struct audio_driver *drvtab[] = {
 CONFIG_AUDIO_DRIVERS
 no_audio_driver,
+#ifdef CONFIG_TWOLAME
+twolame_audio_driver,
+#endif
 wav_audio_driver
 };
 
diff --git a/audio/audio_int.h b/audio/audio_int.h
index d8560b6..337188b 100644
--- a/audio/audio_int.h
+++ b/audio/audio_int.h
@@ -210,6 +210,7 @@ extern struct audio_driver dsound_audio_driver;
 extern struct audio_driver esd_audio_driver;
 extern struct audio_driver pa_audio_driver;
 extern struct audio_driver winwave_audio_driver;
+extern struct audio_driver twolame_audio_driver;
 extern struct mixeng_volume nominal_volume;
 
 void audio_pcm_init_info (struct audio_pcm_info *info, struct audsettings *as);
diff --git a/audio/twolameaudio.c b/audio/twolameaudio.c
new file mode 100644
index 000..4372fc4
--- /dev/null
+++ b/audio/twolameaudio.c
@@ -0,0 +1,417 @@
+/*
+ * QEMU twolame streaming audio driver
+ *
+ * Copyright (c) 2010 François Revol re...@free.fr
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include config-host.h
+#include qemu-common.h
+#include qemu-char.h
+#include qemu_socket.h
+#include audio.h
+
+#define AUDIO_CAP twolame
+#include audio_int.h
+#include audio_pt_int.h
+
+#include twolame.h
+
+typedef struct {
+HWVoiceOut hw;
+int done;
+int live;
+int decr;
+int rpos;
+void *pcm_buf;
+void *mpg_buf;
+int lsock;
+int sock;
+struct audio_pt pt;
+twolame_options *options;
+} LAMEVoiceOut;
+
+static struct {
+int samples;
+int divisor;
+int port;
+int rate;
+} conf = {
+.samples = 1024,
+.divisor = 2,
+.port = 8080,
+.rate = 160
+};
+
+static const char http_header[] = HTTP/1.1 200 OK\r\nServer: QEMU\r\n
+   Content-Type: audio/mpeg\r\n\r\n;
+
+static void GCC_FMT_ATTR (2, 3) qtwolame_logerr (int err, const char *fmt

[Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Le 8 nov. 2010 à 01:02, malc a écrit :

 +
 +static void qtwolame_listen_read(void *opaque)
 
 No space here.

?

 +if (csock != -1) {
 +twolame-sock = csock;
 +dolog (Accepted peer\n);
 +if (write (twolame-sock, http_header, sizeof(http_header) - 1)  
 sizeof(http_header) - 1) {
 
 Line is too long.

Dang, wrote it after the 80col pass.

 
 +qtwolame_logerr (errno, write failed for http headers\n);
 +/* sending headers failed, just close the connection */
 +closesocket (twolame-sock);
 +twolame-sock = -1;
 +}
 +}
 
 twolame-csock is not set to -1 (the condition which is checked for 
 everywhere)

There is no twolame-csock, just twolame-lsock (the listen socket), and 
twolame-sock (=csock temporary var) which is the accepted socket.

 +again:
 +if (twolame-sock  -1) {
 +written = write (twolame-sock, twolame-mpg_buf, 
 converted);
 +if (written == -1) {
 +if (errno == EPIPE) {
 +dolog (Lost peer\n);
 +closesocket (twolame-sock);
 
 This is actually no better than jumping before, reading this code requires
 more analysis than needed, and no i'm not saying it's not correct just hard
 to read.

I'll have to sleep on this then.

 +twolame_set_mode(twolame-options,
 +(as-nchannels == 2) ? TWOLAME_STEREO : TWOLAME_MONO);
 +twolame_set_num_channels(twolame-options, as-nchannels);
 +twolame_set_in_samplerate(twolame-options, as-freq);
 +twolame_set_out_samplerate(twolame-options, as-freq);
 +twolame_set_bitrate(twolame-options, conf.rate);
 +
 +if (twolame_init_params(twolame-options)) {
 +dolog (Could not set twolame options\n);
 +goto fail1;
 +}
 
 Once again, if you don't like the space before paren by all means do not use
 it, but either way do things consistently.

Ah, forgot this one.

 +qemu_set_fd_handler2(twolame-lsock, NULL, NULL, NULL, NULL);
 +if (closesocket (twolame-lsock)) {
 
 Here we go again, closesocket is cheked here but not elsewhere.

Because elsewhere it's done in an error path and it'd won't do much better, but 
oh well.


 And can you, please, elaborate some more on usage scenarios of this thing?


cf.
http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/onlinedemo/haiku.php

and possibly http://oszoo.org/wiki/index.php/Main_Page some day...

The idea is to use it along with the -vnc option and the VNC applet to present 
a VM on the web.

François.

[Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Le 8 nov. 2010 à 04:57, malc a écrit :

 And can you, please, elaborate some more on usage scenarios of this thing?
 
 cf.
 http://dev.haiku-os.org/browser/haiku/trunk/3rdparty/mmu_man/onlinedemo/haiku.php
 
 Sorry my PHP skills have lapsed aeons ago.

Sorry I don't have it installed on a publically accessible machine atm.

 
 and possibly http://oszoo.org/wiki/index.php/Main_Page some day...
 
 The idea is to use it along with the -vnc option and the VNC applet
 to present a VM on the web.
 
 While not very sexy, but can't you just use wav output to a fifo and
 compress it via separate process.

I did try years ago, but at least the current wav driver really didn't like 
fifos back then. I recall trying for hours to get it pipe to ffmpeg or others 
without much luck.

Also, this poses several problems about the control of the external process 
(respawn on listener disconnection, close on exit...).

François.

Re: [Qemu-devel] Access to specific isa card with Qemu???

[François Revol]

Hi,

 We have a software that runs on MS-DOS and must communicate with a specific 
 card installed on port isa.
 We  want to use this software in Qemu with a machine that runs XP.
 Is it possible to access to the ISA port with Qemu in this case?
 
 Do we have to do a specific development?
 Can you help us in this development, how much would it cost?

I believe some people already implemented PCI pass-through, or ported it from 
other emulators (Bochs had one IIRC), you'd have to check the mailing list :
http://search.gmane.org/?query=pci+pass+throughgroup=gmane.comp.emulators.qemu

Essentially you'd have to write the same kind of thing but for ISA, except 
you'll have to specify the resources manually since the card isn't published as 
a specific entity on ISA busses (PnP ones excepted).

Passing through I/O ports should be easy, but IRQ forwarding or even DMA if you 
need it might require some more work.

François.

Re: [Qemu-devel] Re: [PATCH] spice: add audio

[François Revol]

 
 Add support for the spice audio interface.  With this patch applied
 audio can be forwarded over the network from/to the spice client.  Both
 recording and playback is supported.
 
 The driver is first in the driver list, but the can_be_default flag is
 set only in case spice is active.  So if you have the spice protocol
 enabled the spice audio driver is the default one, otherwise whatever
 comes first after spice in the list.  Overriding the default using
 QEMU_AUDIO_DRV works in any case.
 
 
 Applied.

Seems there is more interest than twolame :^)

Now, if only VNC had standardized audio passthrough yet...
I guess I'd have to propose...

François.

Re: [Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Le 12 nov. 2010 à 15:32, Anthony Liguori a écrit :

 I did try years ago, but at least the current wav driver really didn't like 
 fifos back then. I recall trying for hours to get it pipe to ffmpeg or 
 others without much luck.
 
 Also, this poses several problems about the control of the external process 
 (respawn on listener disconnection, close on exit...).
 
 Doing encoding in QEMU is going to starve the guest pretty bad.  For an x86 
 guest, that's going to result in issues with time drift, etc.
 
 Making reencoding with an external process work a bit more nicely also has 
 the advantage of making this work with other formats like Ogg which are a bit 
 more Open Source friendly.

The current patch uses a separate thread, but since I clone this part from the 
esdaudio code I didn't check what it was doing. It seems it's not really 
queueing anything though except the single mix buffer, which kind of defeats 
the purpose of having a separate thread. This might explain why it lags so much 
here... I tried increasing the buffer size and lowering the threshold but it 
doesn't seem to help.

I agree it'd be better to use external programs when possible but as I said 
it's a bit harder to handle the errors and such, and I wanted to have something 
working.
Also, it requires more work to set it up for users, they must install the 
externals, figure out the command line options...
Possibly we can provide default templates for known programs, either text files 
with % escaping for args, or just a shell script passing env vars maybe...

Besides, external or not, IIRC a pipe is by default 4kB max, which isn't much 
better for decoupling the processing on its own, if the encoder is too slow it 
will still starve the audio thread, and the rest. Also it all requires more 
context switching and IPC, which increase the total processing time.

So I think it might be interesting to have both.

I'll see if I can buffer a bit more in the twolame code and if it helps, then 
I'll try to merge with the failed attempts I have around at using external 
progs.

François.

[Qemu-devel] Issue with block/vmdk

[François Revol]

I tried to boot the vmdk generated by the Haiku build system here but it 
aborted.
It seems the header has the capacity field set to 0, to mean that there is no 
embedded grain directory if I understand the vbox sources...
At least the same image boots perfectly in VBox.

If anyone wants to test :
http://haiku-files.org/vmware/
any image should do.
They are generated by:
http://dev.haiku-os.org/browser/haiku/trunk/src/tools/vmdkimage/vmdkimage.cpp#L303

The mention in vbox:
http://www.virtualbox.org/browser/trunk/src/VBox/Storage/VMDK.cpp#L2796

I might have a closer look at some point but I don't know when.

François.

Re: [Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Le 15 nov. 2010 à 20:30, Anthony Liguori a écrit :

 I'll see if I can buffer a bit more in the twolame code and if it helps, 
 then I'll try to merge with the failed attempts I have around at using 
 external progs.
   
 
 Okay, but my thinking was that we'd do something like:
 
 audio_capture capture_command -opt=val -opt2=val ...
 
 Which would make it very easy to tie into lame, oggenc, etc.
 
 Having simple alias commands like mp3_capture and ogg_capture that invoke 
 common tools with reasonable options also would be a bonus.

You mean in the console ? I hardly use it (beside the idea is to not have it 
accessible to avoid the user committing snapshots as it's just for demos).

Btw, we should really convert all those audio env vars to QemuOpts someday, it 
seems like a duplicate. It should still be possible to map env vars to them for 
the time being.

Anyway I'm still having a hard time getting sound to work reliably in Haiku 
guests regardless the output or emulated card. OTH it works perfectly in 
VirtualBox with almost no cpu overhead. If anyone has a clue...
It might be related to the use of RDTSC as primary time source, still it's the 
same in vbox.
We do have some support for HPET, I should try it someday, maybe.
Maybe it has to do with vbox using VT-x and me not even building QEMU with 
kvm... (does it even work on OSX ?)

François.

Re: [Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[François Revol]

Le 16 nov. 2010 à 20:33, Anthony Liguori a écrit :

 On 11/16/2010 01:22 PM, Andreas Färber wrote:
 Am 15.11.2010 um 22:53 schrieb François Revol:
 
 I'm still having a hard time getting sound to work reliably in Haiku guests 
 regardless the output or emulated card. OTH it works perfectly in 
 VirtualBox with almost no cpu overhead. If anyone has a clue...
 It might be related to the use of RDTSC as primary time source, still it's 
 the same in vbox.
 
 Did you check the time drift command line options? Iirc Gleb needed some 
 hacks for timer-related issues on Windows.
 
 Time drift correction is only applicable to the RTC and PIT and deals with 
 catching up the periodic timers.

Except Haiku, just like BeOS 15 years ago (Linux didn't invent it) does 
tickless, so it likely has other side effects from the PIT emulation...
It should be possible to use IO-APIC for timers now, and it seems vbox has it 
enabled, but I don't remember if the code is totally working yet.

IIRC the HPET timer support also is about running timers for now, not as a 
timesource.

 The issue with the TSC as a time source is that it skips around during CPU 
 migration.  The easiest way to work around this is to simply pin your guest 
 to a single physical CPU (assuming you're using KVM).

Isn't there a POSIX API now for pinning down processes on cpus ?
Hmm seems pthread_attr_setaffinity_np is non portable...
Can't seem to find an equivalent on OSX...
Oh wait, maybe this:
http://developer.apple.com/library/mac/#releasenotes/Performance/RN-AffinityAPI/

I'll see if I can make use of this.

 (does [KVM] even work on OSX ?)
 
 No.

Won't even try to write a kext for it anyway.

François.

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

[François Revol]

 For the emulation side, things look different. I'm not aware of any 
 traction on the emulation side of Qemu. Getting people together for that 
 one is certainly lacking. I'm not sure I'm the right person to talk to 
 there. If nobody else steps up, I could barely play the role of someone who 
 knows what he's talking about, but I'm myself more of a virtualization 
 person too.
 
 What about doing some kind of QEMU-focussed meeting at FOSDEM 2011? That 
 event is much more open to actual users than some academic/commercial 
 conference with registration.
 
 That might indeed be interesting. Are the registrations open still?

Not for the devrooms proposals, no.
Last year I managed the AltOS devroom, it was really interesting. I actually 
tried to get some talks about QEMU but I never get any reply btw :^)
I'm way too busy this year to even think about it.

However the CFP from the selected devroom themselves are mostly open:
http://fosdem.org/2011/call_for_participation
It might be possible to sneak in the embedded devroom for example, or the 
virtualization one which seems to be quite on topic. They cite OSZOO topic, I 
might try a talk about haiku.php I suppose.

François.

Re: [Qemu-devel] CFP: 1st International QEMU Users Forum

[François Revol]

 the people we are addressing and we would like to bring together is from the 
 QEMU emulation community.
 We are interested in running different ISAs mainly under Linux and Windows 
 versions. There is a huge additional
 
 You're about the first person in 1/2 year that actually said you care about 
 Windows hosts. Windows support for example is currently on the verge of 
 getting deprecated, because we're lacking a maintainer.

I suppose windows users are not as much used/interested/involved into free 
software development workflows, and probably don't bother even lurking on the 
developer mailing lists. They only shout when something breaks :p

 interest from industry for this part to QEMU for embedded systems/SW 
 development. The focus we have chosen
 for the DATE conference is SystemC integration with QEMU emulation since the 
 embedded systems and SystemC
 community meets at DATE so that we expect several people from them to 
 attend. However, as already written, we
 basically failed to find any indication for contact point for the emulation 
 community. Any pointers are highly appreciated.
 
 What audience and talks do you expect to receive? I'm still trying to get a 
 full picture on what topics people would be interested in the most.

From what I understood, since it's part of a scientific event, it's mostly 
toward the CS scientific community, where conferences have quite specific rules.

 The main contact point for any qemu discussions is the qemu-devel mailing 
 list. We're a community, so these things should happen as open as possible.

The scientific community is only starting to grasp the idea of open work, 
they are more used to do things in their lab and only reveal stuff when it's 
time to publish, and often do not even talk about what doesn't concern their 
direct subject research, so often they use/contribute/write software without 
others knowing.
(it was one of the main subjects of the fOSSa conference this month btw 
http://fossa2010.inrialpes.fr/)

 It's very hard to draw a clean line. A lot of people from the KVM community 
 are active maintainers of several layers in qemu these days. For example the 
 block layer, PCI devices, PowerPC. The communities are merging. In the 
 mid-term, there shouldn't even be a qemu-kvm fork of qemu anymore. Everybody 
 who does device emulation would just work on upstream qemu, regardless of the 
 intents. The same is happening for the Xen folks too btw. They're slowly 
 moving back towards upstream qemu as well.

That's good to hear, I only found out about the beagleboard qemu fork months 
after having to stick to the verdex target while having a overo gumstix 
hardware :p

As long as patches do not take 3 years to get in like my wacom-tablet fixes ;)

 So according to my calendar, I should be free on that week. So if you're 
 eager to have a keynote/session from upstream qemu folks, I'd certainly be 
 interested in doing this. Getting people to contribute back would be so 
 awesome. I'm still getting sad to see qemu getting forked so often (android, 
 vbox, ...).
 
 If however, we find a better candidate (ideas, suggestions anyone?) to give a 
 general session, I'll gladly step back.

As I said to them, I'd be happy to talk about our usage patterns and needs with 
Haiku development, but I don't know enough of QEMU's internals to detail this.

 The one thing I am not willing to do however, is to pay a 400 € registration 
 fee to have the honor of giving a talk. That just doesn't seem right to me.

As I said, scientific conferences have a quite specific set of rules, one being 
you pay to talk :p
Usually the labs handle the expense for the attendees, because this gives them 
exposure.
It's quite different from the FOSDEM or RMLL confs with free entry and best 
effort speaker reimbursement by sponsors :D

 What about doing some kind of QEMU-focussed meeting at FOSDEM 2011? That 
 event is much more open to actual users than some academic/commercial 
 conference with registration.
 
 From the fosdem homepage:
 
  We would like to inform all interested parties that the call for devrooms is 
 running at its end.
  Coming Saturday, 16 October at 23.59 the call for devrooms closes.

Again, the virtualization devroom should give quite a lot of opportunities.

François.

[Qemu-devel] [PATCH] Add basic read, write and create support for AMD SimNow HDD images.

[François Revol]

$subj.
Someone asked about this format, wanting to try Haiku in SimNow, so I wrote 
this.
I got a report of successfully booting a converted image in SimNow.
It doesn't yet support automatically growing the file, so we just preallocate 
on create.

François.

From b0602bc2b02dcd7b15f0f9a143f850defd767509 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Revol?= re...@free.fr
Date: Sun, 28 Nov 2010 20:01:03 +0100
Subject: [PATCH] Add basic read, write and create support for AMD SimNow HDD 
images.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


Signed-off-by: François Revol re...@free.fr
---
 Makefile.objs |2 +-
 block/hdd.c   |  354 +
 2 files changed, 355 insertions(+), 1 deletions(-)
 create mode 100644 block/hdd.c

diff --git a/Makefile.objs b/Makefile.objs
index 23b17ce..20e346d 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -20,7 +20,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
 
 block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o 
vvfat.o
 block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
-block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
+block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o hdd.o
 block-nested-$(CONFIG_WIN32) += raw-win32.o
 block-nested-$(CONFIG_POSIX) += raw-posix.o
 block-nested-$(CONFIG_CURL) += curl.o
diff --git a/block/hdd.c b/block/hdd.c
new file mode 100644
index 000..aed609e
--- /dev/null
+++ b/block/hdd.c
@@ -0,0 +1,354 @@
+/*
+ * Block driver for the AMD SimNow HDD disk image
+ *
+ * Copyright (c) 2010 François Revol
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Reference:
+ * http://developer.amd.com/Assets/SimNowUsersManual4.6.2.pdf page 181
+ * 
+ * the hard-disk image file contains a 512-byte header before the raw data.
+ *  This 512-byte header is identical to the information provided by the drive
+ *  in response to the ATA command IDENTIFY. Following the 512-byte header
+ *  is the data for each sector from the device.
+ */
+
+#include qemu-common.h
+#include block_int.h
+#include module.h
+
+/* Command line option for static images. */
+#define BLOCK_OPT_STATIC static
+
+#define SECTOR_SIZE 512
+#define DATA_START 1
+#define MAX_MULT_SECTORS 1
+
+typedef struct BDRVHddState {
+uint8_t identify_data[SECTOR_SIZE];
+} BDRVHddState;
+
+
+static void padstr(char *str, const char *src, int len)
+{
+int i, v;
+for(i = 0; i  len; i++) {
+if (*src)
+v = *src++;
+else
+v = ' ';
+str[i^1] = v;
+}
+}
+
+static void put_le16(uint16_t *p, unsigned int v)
+{
+*p = cpu_to_le16(v);
+}
+
+static int isvalid_ide_chr(char c)
+{
+/* XXX: other chars also maybe? */
+return (isalnum(c) || c == ' ' || c == '.');
+}
+
+static int hdd_probe(const uint8_t *buf, int buf_size, const char *filename)
+{
+int name_len;
+uint16_t *p = (uint16_t *)buf;
+int64_t nb_sectors;
+uint32_t nb_sectors_clipped;
+int result = 0;
+int i;
+
+if (buf_size  SECTOR_SIZE) {
+/* Header too small, no VDI. */
+return 0;
+}
+
+/* best effort sanity check */
+/* TODO: check more (CHS size...) */
+
+/* serial number */
+for (i = 10 * 2; i  10 * 2 + 20; i++) {
+if (!isvalid_ide_chr(buf[i])) {
+return 0;
+}
+}
+result += 20;
+
+/* firmware version */
+for (i = 23 * 2; i  23 * 2 + 8; i++) {
+if (!isvalid_ide_chr(buf[i])) {
+return 0;
+}
+}
+result += 8;
+
+/* model */
+for (i = 27 * 2; i  27 * 2 + 40; i++) {
+if (!isvalid_ide_chr(buf[i])) {
+return 0;
+}
+}
+result += 40;
+
+nb_sectors = le16_to_cpu(p[100]);
+nb_sectors |= (uint64_t)le16_to_cpu(p[101])  16;
+nb_sectors |= (uint64_t)le16_to_cpu(p[102])  32

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[François Revol]

 
 Hi All,
 
 Now that I have usb-1.1 passthrough  / local redirection support
 working reliably (see my patch sets for this), I'm going to start
 working on doing usb redirection support over the network.
 
 The idea here is that a usb device connected to machine a, will be
 available for use by the guest os running on host b (machine b).
 
 I'm working on this because it is something which we want / need
 for spice. I'm wondering if there is interest in this outside
 of spice ?

Not me at the moment, but unless you tunnel it inside another protocol, you'd 
really want to look at the existing USB-over-IP protocols instead of 
reinventing the wheel:
http://usbip.sourceforge.net/ (some support in Linux already IIRC)
(and there are others which I don't recall)

 I'm asking because at this moment in time the redirection support
 can probably be written in a way which abstracts the transport channel
 quite easily, allowing use outside of spice.

Yeah it'd be nice to avoid code duplication.

Does RDP have such feature ?
I'd think it should be possible to add this to VNC somehow, since it has 
provisions for extensions.

François.

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[François Revol]

 The idea here is that a usb device connected to machine a, will be
 available for use by the guest os running on host b (machine b).
 
 I'm working on this because it is something which we want / need
 for spice. I'm wondering if there is interest in this outside
 of spice ?
 I'm asking because at this moment in time the redirection support
 can probably be written in a way which abstracts the transport channel
 quite easily, allowing use outside of spice.
[...]
 Not me at the moment, but unless you tunnel it inside another
 protocol, you'd really want to look at the existing USB-over-IP
 protocols instead of reinventing the wheel:
 http://usbip.sourceforge.net/ (some support in Linux already IIRC)
 (and there are others which I don't recall)
 
 Doesn't look very useful on a quick glance.
 
 First: Yes, we wanna embed this into other protocol(s).
 
 Second, seems usbip is implemented using special drivers in kernel space for 
 both sides.  We will not need special drivers on the qemu side (we just hook 
 up the devices to the emulated hci).  On the client side using libusb looks 
 alot more sensible than requiring kernel modules.

I recall seeing discussions about it on the libusb-devel list (CCing).

http://search.gmane.org/?query=usbipgroup=gmane.comp.lib.libusb.devel.general

It's just one implementation of it, it should be possible to implement a subset 
of the features at least with libusb which should be enough for most devices 
(scanners/printers/mass storage). 

And it's better to use the same protocol anyway when possible.
This way the untunnelled version could be used from QEMU or a host using a stub 
driver connecting to a server using either the kernel driver or the libusb 
version regardless.

François.

[Qemu-devel] Re: IRC channel movement - FreeNode to OFTC

[François Revol]

Hi,

 I'd like to move IRC channels from FreeNode to OFTC, so please join #qemu on 
 OFTC starting now.

- what's wrong with freenode ? everyone is there.
- #define OFTC ?

François.

[Qemu-devel] Re: Re: [PATCH 0/4] ppc: Fix PReP emulation

[François Revol]

 So we certainly do need some open source firmware solution for prep to at 
 least have Linux running. For other guests, I don't see a reason why users 
 shouldn't try to fetch a real firmware blob separately :).
 
 We're not shipping any firmware for ppcemb either, so that argument seems 
 moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to 
 supply additional blobs for U-Boot etc.
 
 IIUC you don't need u-boot for the embedded targets. You just pass in a 
 kernel and the rest is magic.

This holds only for Linux which imposes its own startup API to bootloaders and 
go with kernel drivers directly.

Other OS like Haiku use a 2nd stage bootloader which assumes a working callable 
BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own.

 Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want 
 to run using open source firmware?
 I certainly do not intend to write firmware for the upcoming 40p machine. If 
 Linux runs on real 40p hardware then it should run with real firmware under 
 emulation, too. QEMU is an emulation project, not a Linux testing framework.
 
 I completely agree. Linux is usually easy because it's fully open source and 
 supports a lot of targets. If you feel like running NetBSD or Haiku instead, 
 feel free to do so.

Thanks for thinking about Haiku ;)

Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses 
a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope 
bootloader a list of BIOS-like callbacks into U-Boot, cf. :
http://www.acube-systems.biz/index.php?page=hardwarepid=2
http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz

Though they probably won't run on PReP, and PReP support in Haiku might come 
only for the sake of supporting the BeBox, which had its own dumb firmware 
(MAME seems to have some emulation support for BeBox).

OTOH, I've been thinking about adding a Sam440 target, but it'd still require 
the custom U-Boot to start AmigaOS for example.

François.

[Qemu-devel] Re: Re: Z80 emulation updated again!

[François Revol]

 Here's an update of the Z80 system emulator, which currently emulates
 the ZX Spectrum only. [...]
 
 [...] do you think it's a valuable target to have in upstream qemu?
 
 The z80 was also used in the more modern TI-83 Plus programmable calculator 
 [1], for instance (chosen for school use in Baden-Württemberg in the early 
 2000s). There was 

Yes, all Ti8x models except 89 (and 92 which are 68000 based) are z80 based.
There are already several emulators to compare to.

 an assembler toolchain integrated with Zilog Studio on Windows iirc.
 Apparently there's also an open source C compiler toolchain at [2] for these 
 and other targets.
 No Linux that I'm aware of. ;)

http://sdcc.sourceforge.net/ ?

I'm not sure if we ever had a ti-specific z80 compiler like tigcc was for 
68k-based models, maybe check on http://www.ticalc.org/

François.

Re: [Qemu-devel] Re: Re: Z80 emulation updated again!

[François Revol]

Le 21 déc. 2010 à 10:41, Stefan Hajnoczi a écrit :
 
 Yes, all Ti8x models except 89 (and 92 which are 68000 based) are z80 based.
 There are already several emulators to compare to.
 
 The TI-83 was a great calculator.  At one point there was a community
 and quite a few games for it :).
 
 The issue with emulating it is that you need a proprietary ROM that
 can't be redistributed.  I think the same goes for the other TI graphing
 calculators.

Yes, though Ti never caused trouble with this on emulators AFAIK.
OTH they did send a DMCA letter to those who breached their signing process to 
make their own flash app.

François.

Re: [Qemu-devel] QEMU forks survey

[François Revol]

Le 21 déc. 2010 à 19:28, Andreas Färber a écrit :

 Since Christmas and the New Year with its good intensions are approaching, 
 apart from z80 there's some more feature forks around:

There is also a 68k trunk around IIRC:
http://gitorious.org/qemu-m68k/qemu-m68k

 * I heard from François that one of the downstreams has added support for the 
 arm Beagle board? Maemo?

Yes it seemed to start booting Haiku's loader built for overo btw (also an OMAP 
IIRC).

François.

Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White

[François Revol]

 I can only get the display on BeOS/x86 Personal Edition 5 to be in black
 and white.  I've tried all the -vga options.
 
 wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz
 mkdir foo
 cd foo
 tar zxvf ../BeOS4Linux.tar.gz
 qemu -cdrom image.be -fda floppy.img -boot a -vga std
 
 ** Affects: qemu
 Importance: Undecided
 Status: New
 

This is because it doesn't have any driver that supports the emulated hardware, 
so it just switches to 16 color VGA and draws from an 8bit framebuffer to the 
VGA bank with a grey palette.

I thought the Cirrus card could be supported but it probably doesn't emulate a 
matching chip.

It might be possible to try extra drivers from http://bebits.com/browse/23
though it'd be better to have a working setup from the official image.

Later versions and Haiku use VESA though, so are unaffected and should work 
with -vga std.

François.

Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White

[François Revol]

Le 2 janv. 2011 à 23:28, Andreas Färber a écrit :

 Am 02.01.2011 um 19:27 schrieb François Revol:
 
 I can only get the display on BeOS/x86 Personal Edition 5 to be in black
 and white.  I've tried all the -vga options.
 
 wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz
 mkdir foo
 cd foo
 tar zxvf ../BeOS4Linux.tar.gz
 qemu -cdrom image.be -fda floppy.img -boot a -vga std
 
 This is because it doesn't have any driver that supports the emulated 
 hardware, so it just switches to 16 color VGA and draws from an 8bit 
 framebuffer to the VGA bank with a grey palette.
 
 I thought the Cirrus card could be supported but it probably doesn't emulate 
 a matching chip.
 
 It might be possible to try extra drivers from http://bebits.com/browse/23
 though it'd be better to have a working setup from the official image.
 
 Later versions and Haiku use VESA though, so are unaffected and should work 
 with -vga std.
 
 Hmm, I have BeOS 5 PE working with qemu -hda ... (i.e., default VGA options).
 And I'm pretty sure I didn't install special drivers.
 
 /boot/home/config/settings/kernel/drivers/vesa has:
 
 mode 800 600 16

Oh, then you just have to force it.

Indeed, the VESA driver is there, but you must force it by adding the config 
file.
And it doesn't support mode changes.

François.

Re: [Qemu-devel] Re: IRC channel movement - FreeNode to OFTC

[François Revol]

Le 24 janv. 2011 à 20:13, Mike Frysinger a écrit :

 On Thu, Dec 9, 2010 at 17:44, Brian Jackson wrote:
 A. Must be registered to talk in a channel
 
 i'm fairly certain that is a per-channel setting

Indeed, only on #qemu do I have to identify to talk, other channels don't 
require it.

 D. Their non-profit status in the US was terminated for failure to file
 paperwork properly
 
 not terribly relevant if the network continues to function ... just
 dont give them money

+1

François.

Re: [Qemu-devel] Re: IRC channel movement - FreeNode to OFTC

[François Revol]

(btw, Brian Jackson i...@theiggy.com seems to be rejected by my smtp here:
Recipient address rejected: Domain not found)

Le 25 janv. 2011 à 23:40, Brian Jackson a écrit :
 
 D. Their non-profit status in the US was terminated for failure to file
 paperwork properly
 not terribly relevant if the network continues to function ... just
 dont give them money
 If nobody gives them money how are they going to continue operating?
 considering they have volunteer servers from organizations that get
 money for other reasons already, i dont think they're going to
 implode.  or if they do, you then have an argument that no one can
 defend -- let's move to OFTC because freenode no longer exists.
 -mike
 
 
 Really it's a moot point. The channel already moved. I don't think moving 
 back buys us anything at this point.

Except people who don't go there by laziness because all their other channels 
are on freenode.
Raise your hands ! \o_

François.

Re: [Qemu-devel] Re: IRC channel movement - FreeNode to OFTC

[François Revol]

Le 25 janv. 2011 à 23:24, Mike Frysinger a écrit :

 On Tue, Jan 25, 2011 at 15:05, Brian Jackson wrote:
 On 1/24/2011 1:13 PM, Mike Frysinger wrote:
 On Thu, Dec 9, 2010 at 17:44, Brian Jackson wrote:
 C. They have strange rules about groups and channel ownership
 
 ive never had a problem
 
 Yeah, this was a bit vague. I think the biggest issue is that nobody that's
 actually involved in qemu currently has any ability to do anything with the
 #qemu@freenode. So it's either make a #therealqemu@freenode, try to convince
 freenode that the current developers should have access, or move to a
 network that is friendlier to it's users. Guess which one is easiest?
 
 so from your point, it's more a matter of freenode sucks because
 we've lost control of the official qemu channel and OFTC works
 because we currently have active developers who control the official
 qemu channel.  so when control is lost on OFTC, where to next ?  i
 vote for EFnet.

No but it should be possible to ask the freenode team to drop the current 
owners, they shall see if it's not been worked on for a while.

François.

[Qemu-devel] Re: [PATCH] vdi: Fix image opening and creation for odd disk sizes

[François Revol]

Le Fri, 07 May 2010 09:55:23 +0200, Kevin Wolf a écrit :
 Am 06.05.2010 20:29, schrieb Stefan Weil:
  This patch fixes a regression introduced by commit
  95a2f9bc588c3f83375d87b0a9394f89a1bcfada.
 
  The fix is based on a patch from Kevin Wolf. Here his comment:
 
  The number of blocks needs to be rounded up to cover all of the
  virtual hard
  disk. Without this fix, we can't even open our own images if their
  size is not
  a multiple of the block size.
 
  While Kevin's patch addressed vdi_create, my modification also
  fixes
  vdi_open which now accepts any image which is large enough to hold
  the blocks.

 Shouldn't it be the other way round? That is, an image which has some
 unused blocks at its end makes sense, whereas an image with a virtual
 disk size that can't be represented with the number of blocks
 doesn't?

Exactly, else you don't create what you are asked for.

  I also decided to keep the original code in vdi_create which rounds
  down.
  Rounding works in both directions, and there are good arguments for
  both,
  so I just left the original simple code.
 
  It is very important to use the rounded value for the new disk
  size, too -
  otherwise VirtualBox cannot open our disk image.

 So you're saying that in VDI you can't represent disks with an odd
 size?
 The one thing common across image formats seems to be that they are
 broken...

VB works quite well with my converted laptop image which indeed doesn't
end on block boundary.

Was it because you were just setting size larger than the covered by
the blocks ?

François.

[Qemu-devel] Re: [PATCH] vdi: Fix image opening and creation for odd disk sizes

[François Revol]

Le Mon, 10 May 2010 22:12:33 +0200, Stefan Weil a écrit :
 The fix is based on a patch from Kevin Wolf. Here his comment:

 The number of blocks needs to be rounded up to cover all of the
 virtual hard
 disk. Without this fix, we can't even open our own images if their
 size is not
 a multiple of the block size.

 While Kevin's patch addressed vdi_create, my modification also fixes
 vdi_open which now accepts images with odd disk sizes as well as
 images created with old versions of qemu-img.

 Cc: Kevin Wolf kw...@redhat.com
 Cc: François Revol re...@free.fr

Looks good to me on first read.

François.

[Qemu-devel] Call for participation to the Alt-OS devroom at FOSDEM

[François Revol]

Hi,
I'm sending this call here too, I think it'd be interesting to see a
talk about how QEMU is used in various FOSS OS projets for testing,
debugging...
At least in Haiku many developers use it in such ways.
Also, it's interesting to hear about porting efforts of QEMU itself to
unusual OSes. Other subject could be the difficulties of supporting
weird OSes without compromising emulation speed.

François.
-

During the previous edition of the Free and Open Source Software
Developer's European Meeting (FOSDEM) http://fosdem.org/, several
alternative FOSS Operating System projects
(Haiku http://haiku-os.org/, ReactOS http://www.reactos.org/)
shared booths, but there were discussions about going beyond presenting
each projects on its own, and instead seek cooperation. Recently, at
the Google Summer of Code mentor summit, other OS projects gathered and
formed the Rosetta OS group http://code.google.com/p/rosetta-os/ to
work on driver sharing.

This year, the FOSDEM (in Brussels, 6-7th February 2010) will host the
Alt-OS devroom on sunday from 9:00 to 17:00, organized by members of
the Rosetta OS project.

This devroom is meant as a place for Free and OpenSource Alternative
Operating System projects to share ideas and work on topics like:
 * distinguishing design and features,
 * device drivers and how to share them,
 * sharing code for internal components,
 * internal usage of other FOSS projects to build upon,
 * application portability,
 * interoperability,
  * file formats,
  * extended attributes...

We are interested to hear about your OS projects, how they are
designed, and what they could eventually share for other projects'
benefit.
In addition to all FOSS OS projects, any application project that is
seeking new target platforms is invited. Featured projects will include
participants from the Rosetta OS project which charter 
http://code.google.com/p/rosetta-os/wiki/RosettaOSCharter
matches our devroom goal.

As time allows, we are also interested in transversal subjects in
cooperation with other devrooms. As an example, possible topics could
include:
 * unusual package management with the Crossdistro room,
 * standardization of GUI elements and behavior with the Crossdesktop
devroom,
 * scalability with the Embedded devroom,
 * ways in which BSD drivers were reused in your project,
 * concerns about porting Java,
 * Gallium3D port progress reports...

The format of the talks can vary, from 45min large speech to 15 min
general project presentation, or hand-on hacking session.

= Proposals =

Proposals should be sent to François Revol by mail: re...@free.fr

Your proposal should include:
 * duration (in 15 minute blocks -- please stick with that granularity,
as it will make the schedule somewhat easier to follow for visitors),
 * activity title (please try to be descriptive, there are ~250 talks
at FOSDEM during the week-end ;)),
 * a short abstract (1-2 paragraphs),
 * a longer description if appropriate,
 * optionally a list of links to the project website or similar
 * for each speaker:
  * the speaker's real name,
  * a short overview of her bio in a couple of lines,
  * optionally also a longer bio,
  * optionally a picture (please send it to us as 128x128 PNG),
  * optionally links to her website, blog, ...

Plain-text format is preferred by the FOSDEM team, it makes their life
easier, something like:

--
John Doe
john@example.org

John is currently working as a freelancer and spends most of his free
time contributing to various opensource projects, most prominently on
libjohndoe.

John currently lives in England with his wife, 2 kids and a bunch of
kitten. He loves spending his time walking around in the woods, and
of course kitten. He has a masters degree in kitten science, which
helps him a lot with coding.

blog: http://johndoe.example.org/blog/
attached: john_doe.png
--

= Deadline =

The deadline for submissions is 2009-12-25, please try to stick to it.
Acceptance notification on 2009-12-31.

= Organization =

The room provided by the FOSDEM team has:
 * room number AW1.105 with 48 seats,
 * a video projector with VGA cable,
 * wireless internet.
We will try to provide a wifi router with ethernet ports for
demonstrations since we know many projects do not have functional wifi
drivers yet.
We will also try to provide a laptop to load your slides on if you
can't use your own machine.

It is advised to see with your project supporting associations for
possible reimbursement of travel and hosting cost, since the FOSDEM
team cannot help there. Attendance is free however.
Also remember to check other devroom calls as well as the call for
lightning talks http://fosdem.org/2010/call_for_lightningtalks, for
subjects that might not fit our topics of interest.

= Projected schedule =


 9:00   Welcome (15min)
 9:15   Rosetta OS project
morning project presentations, design...
afternoon   more projects, workshops...
16:45   Closing (15min)

[Qemu-devel] [PATCH][RESEND] block/vdi: allow disk sizes not multiple of block size (fwd)

[François Revol]

Anyone just tried it yet ?

François.

-- Forwarded Message: --
To: qemu-devel@nongnu.org
From: François Revol re...@free.fr
Subject: [PATCH] block/vdi: allow disk sizes not multiple of block size
Date: Tue, 08 Dec 2009 15:34:18 +0100 CET

The disk image I created from my old laptop disk with VBoxManage
internalcommand converthd obviously was not a multiple of 1MB as when
created from scratch. This fixes QEMU refusing it. We still require the
size to be a multiple of sector size though.
It then boots correctly.




Allow opening VDI images with size not multiple of 1MB (as when converted from a raw disk).

Signed-off-by: François Revol re...@free.fr

diff --git a/block/vdi.c b/block/vdi.c
index 45aa81c..c91961a 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -411,14 +411,17 @@ static int vdi_open(BlockDriverState *bs, const char *filename, int flags)
 /* We only support data blocks which start on a sector boundary. */
 logout(unsupported data offset 0x%x B\n, header.offset_data);
 goto fail;
+} else if (header.disk_size % SECTOR_SIZE != 0) {
+logout(unsupported disk size % PRIu64  B\n, header.disk_size);
+goto fail;
 } else if (header.sector_size != SECTOR_SIZE) {
 logout(unsupported sector size %u B\n, header.sector_size);
 goto fail;
 } else if (header.block_size != 1 * MiB) {
 logout(unsupported block size %u B\n, header.block_size);
 goto fail;
-} else if (header.disk_size !=
-   (uint64_t)header.blocks_in_image * header.block_size) {
+} else if ((header.disk_size + header.block_size - 1) / header.block_size !=
+   (uint64_t)header.blocks_in_image) {
 logout(unexpected block number %u B\n, header.blocks_in_image);
 goto fail;
 } else if (!uuid_is_null(header.uuid_link)) {

[Qemu-devel] Extended deadline for proposals for the Alt-OS devroom at FOSDEM

[François Revol]

Hello,
I have been unavailable for a week, and it seems a lot of people were
cut off the Net last month busy with family...

The deadline for the propositions for the Alt-OS devroom at FOSDEM has
been extended to 2010-01-05, to allow at least one talk per project.
The shedule must be sent rapidly to the FOSDEM team so we can't stretch
it much more.

I'd really like to have a talk about some alternative OS project using
QEMU for their development. I might talk about my own usage for Haiku
but I'll be quite busy, so it'd be nice to hear someone else. Things
like USB stack debugging with the USB passthrough for ex. would be
topics of interest.
I't also be nice to have a summary of QEMU support of guest and host
OSes. Anyone wants to talk about the darwin-user target ? (is it still
maintained ? :p)

For the record, the original call for contributions with all the
details:
http://groups.google.com/group/rosetta-os/browse_thread/thread/16964e21bef27116

François.

Re: [Qemu-devel] [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)

[François Revol]

 Makes sense.  Either way, it works with my patch looking something
 like:

   -chardev stdio,id=seabios \
   -device isa-debugcon,iobase=0x402,chardev=seabios

 ... should do the job.

Btw,
I once added another method of debug output to ZETA, that was using the
low-level protocol used by laplink (nibble mode). I needed this for a
laptop that didn't have a serial port but still had a // one. This
allowed bidirectionnal debugging (including sending kernel debugger
commands) with a null-printer cable.
I also wrote code to support it in Haiku, though I'm not sure I've
added the receiving driver yet.
See:
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/debugger/laplinkll

I don't know if the parallel port emulation in QEMU supports dumping
bytes at nibble mode yet, it might be interesting to add this anyway.
Though it should also be possible to just use 8bit mode and dump data
straight to it as with the 0x402 port.

François.

[Qemu-devel] [PATCH] block/vdi: allow disk sizes not multiple of block size

[François Revol]

The disk image I created from my old laptop disk with VBoxManage 
internalcommand converthd obviously was not a multiple of 1MB as when 
created from scratch. This fixes QEMU refusing it. We still require the 
size to be a multiple of sector size though.
It then boots correctly.

Signed-off-by: 
Allow opening VDI images with size not multiple of 1MB (as when converted from a raw disk).

Signed-off-by: François Revol re...@free.fr

diff --git a/block/vdi.c b/block/vdi.c
index 45aa81c..c91961a 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -411,14 +411,17 @@ static int vdi_open(BlockDriverState *bs, const char *filename, int flags)
 /* We only support data blocks which start on a sector boundary. */
 logout(unsupported data offset 0x%x B\n, header.offset_data);
 goto fail;
+} else if (header.disk_size % SECTOR_SIZE != 0) {
+logout(unsupported disk size % PRIu64  B\n, header.disk_size);
+goto fail;
 } else if (header.sector_size != SECTOR_SIZE) {
 logout(unsupported sector size %u B\n, header.sector_size);
 goto fail;
 } else if (header.block_size != 1 * MiB) {
 logout(unsupported block size %u B\n, header.block_size);
 goto fail;
-} else if (header.disk_size !=
-   (uint64_t)header.blocks_in_image * header.block_size) {
+} else if ((header.disk_size + header.block_size - 1) / header.block_size !=
+   (uint64_t)header.blocks_in_image) {
 logout(unexpected block number %u B\n, header.blocks_in_image);
 goto fail;
 } else if (!uuid_is_null(header.uuid_link)) {

[Qemu-devel] wake-on-lan IPMI implementation; real power-off and -no-shutdown

[François Revol]

Hello,
while working on a demonstrator for a green-IT project, to show
scheduled machine shutdown and powering depending on various
conditions, I wondered if I could use QEMU with wake-on-lan
transparently, but it seems it's not implemented at all.

I though I could try to add support for it, and with -S it theorically
should be doable at least for the first boot, but the network packets
do not go much further until the NIC is actually initialized, as most
network layers use qemu_can_send_packet() which returns 0 if the
machine is stopped.
Hacking this function to return 1 seems to push the packet upward, but
I couldn't find a single point where I could check for WOL packets,
different -net subsystems using different code paths.

Also, it seems -no-shutdown doesn't actually stop the emulation as
said in the manual, it actually keeps the vm running (and using cpu),
despite the OS trying to shutdown via ACPI. At least I tested so with
Haiku (and acpi=true in kernel config), which properly exits QEMU
without -no-shutdown.

Ideally this would evolve into supporting IPMI, which would allow
managing VMs exactly like physical servers without concern, appart
launching the actual process first.
cf.
http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
http://openipmi.sourceforge.net/

Anyone interested in this ?
Anyone tried already ?

François.

Re: [Qemu-devel] wake-on-lan IPMI implementation; real power-off and -no-shutdown

[François Revol]

Le Mon, 15 Mar 2010 15:26:24 +, Paul Brook a écrit :
  Ideally this would evolve into supporting IPMI, which would allow
  managing VMs exactly like physical servers without concern, appart
  launching the actual process first.
  cf.
  http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
http://openipmi.sourceforge.net/
 
  Anyone interested in this ?
  Anyone tried already ?

 TBH I don't really see the point.

 This definitely seems like something that should be handled by your
 your
 mangement app (via libvirt, or whatever). i.e. have that implement
 whatever
 remote protocol you want, and just talk to qemu over the normal
 monitor
 interface.

Hmm for IPMI that might probably indeed be a better way, moreover since
they use a parallel subnet on the primary ethernet card...
Though it would require the implementation to listen to the same
virtual card, which are mapped differently to the host depending on the
VM (-net user, ...).

As for WOL, it would still be handy to have I think... btw, do we
support suspending the emulation via ACPI ? VirtualBox has something
called Pause mode, which I'm not sure actually if it's reflected to
ACPI, which allows to avoid wasting cpu when not usign the guest,
though it requires support from the Guest Additions to avoid clock
drifts.

François.

Re: [Qemu-devel] wake-on-lan IPMI implementation; real power-off and -no-shutdown

[François Revol]

  As for WOL, it would still be handy to have I think... btw, do we
  support suspending the emulation via ACPI ? VirtualBox has
  something
  called Pause mode, which I'm not sure actually if it's reflected
  to
  ACPI, which allows to avoid wasting cpu when not usign the guest,
  though it requires support from the Guest Additions to avoid clock
  drifts.
 

 It's just stop.

 It won't cause time drift in qemu when using pvclock but you will get
 soft lockups in Linux.  I presume you get that with Virtual Box too.

Hmm yeah I didn't try playing with the various clock options, since
Haiku doesn't support them anyway, only TSC, and HPET but it's in
progress.

François.

Re: [Qemu-devel] wake-on-lan IPMI implementation; real power-off and -no-shutdown

[François Revol]

  Also, it seems -no-shutdown doesn't actually stop the emulation
   as
  said in the manual, it actually keeps the vm running (and using
   cpu),
  despite the OS trying to shutdown via ACPI. At least I tested so
   with
  Haiku (and acpi=true in kernel config), which properly exits QEMU
  without -no-shutdown.
 
  Hmm, I think -no-shutdown should at least stop the CPUs executing.
  It is
  not really useful on its own though. The app managing QEMU would
  want to
  use the new JSON based monitor to listen for the SHUTDOWN event to
  be
  emitted, so it can detect the shutdown completing  then take
  action it
  wants either reset the guest, or kill QEMU, etc
 

 The semantics of -no-shutdown are awful.

 I'd personally prefer to see the option deprecated and a new set of
 options introduced with clearer semantics.

 Currently, -no-shutdown does too many things.  It affects reboot
 behaviour, shutdown behaviour, the behavior of the SDL close button.
 Each of these things should be individual tunables.

Indeed, it both means do not allow user to close the vm and do not
allow the guest to stop (or reboot ?) it seems...

François.

Re: [Qemu-devel] wake-on-lan IPMI implementation; real power-off and -no-shutdown

[François Revol]

   Also, it seems -no-shutdown doesn't actually stop the emulation
   as
   said in the manual, it actually keeps the vm running (and using
   cpu),
   despite the OS trying to shutdown via ACPI. At least I tested so
   with
   Haiku (and acpi=true in kernel config), which properly exits QEMU
   without -no-shutdown.
 
  Hmm, I think -no-shutdown should at least stop the CPUs executing.
  It is
  not really useful on its own though. The app managing QEMU would
  want to
  use the new JSON based monitor to listen for the SHUTDOWN event to
  be
  emitted, so it can detect the shutdown completing  then take
  action it
  wants either reset the guest, or kill QEMU, etc

  If I'm not missing something, -no-shutdown calls vm_stop(), which
 calls
 pause_all_vcpus().

Oh indeed, info status shows the VM as paused.
I was misled because the GUI window was still open...

François.

Re: [Qemu-devel] wake-on-lan IPMI implementation; real power-off and -no-shutdown

[François Revol]

 I use -no-reboot so that when the guest does a reboot during
 installation, as they invariably do one or more times, QEMU exits, my
 scripts does things eject the CD/floppy, or change it for the next in
 sequence, and modify the guest's installed files to add virtio
 drivers, install extra fiels, edit boot scripts and whatever else is
 useful, and then restart QEMU.

 The guest thinks it's just rebooted, but it has the virtualisation
 goodies in place to run better.

 Unfortunately with an MS-DOS 5.00 guest, -no-reboot does not
 work.  It fails to exit QEMU; instead it just reboots.  I guess that
 means a QJSON event would not be sent either.

I suppose it uses a weird way to reboot, there are many (PS/2
controller, calling the BIOS entry point...).

François.

Re: [Qemu-devel] BeOS R5 boot failure

[François Revol]

 It's a known bug but nobody knows or has time to apply a solution.

 Bochs had the same bug and corrected it about November 2009, maybe
 checking their commit will make light to correct QEMU.

Ok, I might have a look at it, thanks.

  It seems VirtualBox has the same issue. Older versions (ZETA) seem
  to
  work fine, but they have a totally different IDE subsystem.

 VirtualPC had the same fail also.
 Zeta however is not an older version but a newer one.

Yes I messed up, I meant newer of course.

 Considering Zeta is a non-authorized hack, who knows what have they
 changed.

I do, I worked at yellowTAB for a while. :p

ZETA switched to a customized version of the IDE Replacement stack
from Thomas Kurschel at some point:
http://bebits.com/app/2625


This whole FUD about ZETA not being legal has nothing to do in here.
Besides, if PalmSource/Palm/ACCESS loose documents in their cupboards
it's not my fault.


François.

Re: [Qemu-devel] BeOS R5 boot failure

[François Revol]

 http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markupcontent-type=text/vnd.viewcvs-markuprevision=REL_2_4_2_FINAL
 
 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code

 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD


I had a look at it, but it seems it's only about DMA... and the code in
hw/ide/ seems to already or the status reg with BM_STATUS_INT (4) in
many places...

Seems to be something else maybe.

François.

Re: [Qemu-devel] BeOS R5 boot failure

[François Revol]

 http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markupcontent-type=text/vnd.viewcvs-markuprevision=REL_2_4_2_FINAL
 
 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code

 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD

Hmm actually, I begin to think it just doesn't like booting from a
partition image directly. The fact the bootloader lists the volume
misleads into thinking it can boot...
Using the image as cdrom with a floppy image works fine.
Also, the log says ...ata/0/master/0/0_0 and 0_0 is supposed to be the
first partition, which of course doesn't exist (and thus has a size of
0...), the whole block device should have been .../raw instead. I
suppose I've been way too used to Haiku being able to boot this way.

Those images were meant to be used in a FAT or ext2 partition, not
straight away as disk images, unlike in Haiku.

I suppose it was just too obvious :^)

François.

[Qemu-devel] Re: SymbianOS, MeeGO, WebOS and QEMU

[François Revol]

Le 28 févr. 2011 à 20:54, qemu-devel-requ...@nongnu.org a écrit :

 I proposed on GSoC 2010 to cleanup and finish the WIP that was done on 0.9.0 
 for emulation Acorn Archimedes platform.
 It was going to be mentored by Paul Brook but no one took the project, so the 
 proposal is still up.
 I cannot mentor it as I know nothing about ARM.
 
 Check on  
 http://wiki.qemu.org/Google_Summer_of_Code_2011#Enhance.2C_update_and_integrate_Acorn_Archimedes_system_emulation

Oh, interesting list there...

I see someone wants BeBox support.
I already started on this but it doesn't do much yet.

There are also several other 68k machines that could be fun to support once the 
m68k branch is in shape in addition to NeXT, like Atari ST/Falcon and Amiga, 
and there are existing emulators for those to look at.

And I need 68k emulators to finish my Haiku port :-)

François.

Re: [Qemu-devel] Re: SymbianOS, MeeGO, WebOS and QEMU

[François Revol]

Le 1 mars 2011 à 00:19, Natalia Portillo a écrit :

 I see someone wants BeBox support.
 I already started on this but it doesn't do much yet.
 Loading Be's firmware or with a custom one?

I wrote a loader for their boot nub.
It currently starts by probing the PCI bridge and that's about it.

The boot nub can be extracted from the floppy images from there:
http://www.bebox.nu/tech.php?s=tech/bootROM/download
with this script:
http://revolf.free.fr/beos/extract_bebox_images.sh

I shall post a patch someday.

 There are also several other 68k machines that could be fun to support once 
 the m68k branch is in shape in addition to NeXT, like Atari ST/Falcon and 
 Amiga, and there are existing emulators for those to look at.
 Well, there are thousands of 68k machines, however the ones nobody emulates 
 are of more interest.

Indeed, and I'd love to get Haiku to boot on a NeXT :-)

 (Unless your Atari ST and Amiga emulation pretends to support things no other 
 does, like Amiga UNIX, Apple UNIX)

Well, most of those emulators do not support the required mmu, except ARAnyM 
(and their mmu patch was backported to UAE I think).

A/UX would be fun to run :-)
There used to be UNIX for Atari TT also IIRC, though not sure it was ever 
published.

 And I need 68k emulators to finish my Haiku port :-)
 Interesting

http://www.haiku-os.org/blog/mmu_man/2008-08-03/helping_on_m68k

Some recent stuff:
http://revolf.free.fr/beos/shots/shot_haiku_loader_m68k_amiga_vs_atari.png
http://revolf.free.fr/beos/shots/shot_haiku_loader_atari_m68k_splash_001.png

François.

[Qemu-devel] [RFC][PATCH] Preliminary BeBox support

[François Revol]

Since Natalia raised the subject I though I'd post my current patch for the 
BeBox support.
I think the loader stuff can probably be committed already with some cleanup.
The rest is mostly a copy of the prep file with tweaks and needs more work.
The boot nub images can be extracted with this script:
http://revolf.free.fr/beos/extract_bebox_images.sh
Running -M bebox -bios bootnub.image makes it try to probe the PCI bridge for 
now.
Comments ?

François.

diff --git a/Makefile.target b/Makefile.target
index 220589e..a41f792 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -227,6 +227,7 @@ obj-ppc-y += vga.o
 # PREP target
 obj-ppc-y += i8259.o mc146818rtc.o
 obj-ppc-y += ppc_prep.o
+obj-ppc-y += ppc_bebox.o
 # OldWorld PowerMac
 obj-ppc-y += ppc_oldworld.o
 # NewWorld PowerMac
diff --git a/hw/loader.c b/hw/loader.c
index 35d792e..7dc759a 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -515,6 +515,142 @@ out:
 return ret;
 }
 
+/* BeBox ROM image loader */
+
+struct bebox_image_header {
+   uint32_t entry;
+   uint32_t TOC;
+   uint32_t serial_num[2];
+   uint32_t checksum;
+   uint32_t addr;
+   uint32_t size;
+   uint32_t segtable;
+   char date[32];
+};
+
+struct bebox_image_section {
+   uint32_t size;
+   uint32_t offset;
+   uint32_t addr;
+   uint32_t zsize;
+};
+
+static void bswap_bebox_header(struct bebox_image_header *hdr)
+{
+#ifndef HOST_WORDS_BIGENDIAN
+bswap32s(hdr-entry);
+bswap32s(hdr-TOC);
+bswap32s(hdr-serial_num[0]);
+bswap32s(hdr-serial_num[1]);
+bswap32s(hdr-checksum);
+bswap32s(hdr-addr);
+bswap32s(hdr-size);
+bswap32s(hdr-segtable);
+#endif
+}
+
+static void bswap_bebox_section(struct bebox_image_section *sec)
+{
+#ifndef HOST_WORDS_BIGENDIAN
+bswap32s(sec-size);
+bswap32s(sec-addr);
+bswap32s(sec-offset);
+bswap32s(sec-zsize);
+#endif
+}
+
+/* Load a BeBox nub image. */
+int load_bebox(const char *filename, target_phys_addr_t *ep,
+   target_phys_addr_t *ds, target_phys_addr_t *loadaddr)
+{
+int fd;
+int size;
+   int i;
+struct bebox_image_header h;
+struct bebox_image_header *hdr = h;
+struct bebox_image_section s;
+struct bebox_image_section *sec = s;
+uint8_t *data = NULL;
+int ret = -1;
+fprintf(stderr, %s(%s)\n, __FUNCTION__, filename);
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd  0)
+return -1;
+
+size = read(fd, hdr, sizeof(uboot_image_header_t));
+if (size  sizeof(uboot_image_header_t))
+goto out;
+
+fprintf(stderr, %s: %d read\n, __FUNCTION__, size);
+bswap_bebox_header(hdr);
+
+fprintf(stderr, %s: entry %08x addr %08x\n, __FUNCTION__, hdr-entry, 
hdr-addr);
+   /* XXX: all known images load there, but... */
+if (hdr-entry != 0xfff00100)
+goto out;
+if (hdr-addr != 0xfff0)
+goto out;
+   /* date field seems be ASCII, ends with \n and \0 padded */
+   for (i = 0; i  32; i++) {
+   if (!qemu_isprint(hdr-date[i]))
+   break;
+   }
+   if (i = 32 || hdr-date[i] != '\n')
+   goto out;
+   i++;
+   for (; i  32; i++) {
+   if (hdr-date[i] != '\0')
+   goto out;
+   }
+
+   /* TODO: check sum */
+
+fprintf(stderr, %s: hdr ok\n, __FUNCTION__);
+/* it seems the image is supposed to be loaded at hdr-addr,
+* then the primary boot nub relocates the sections itself, copying 
some in RAM.
+ * But we don't have the image for the primary boot nub, so we do it on 
our own. */
+
+*ep = hdr-entry;
+*ds = hdr-TOC;
+data = qemu_malloc(hdr-size);
+
+   /* we also include the header when flashing */
+   lseek(fd, 0, SEEK_SET);
+
+if (read(fd, data, hdr-size) != hdr-size) {
+fprintf(stderr, Error reading file\n);
+goto out;
+}
+
+rom_add_blob_fixed(filename, data, hdr-size, hdr-addr);
+
+if (loadaddr)
+*loadaddr = hdr-addr;
+
+fprintf(stderr, %s: loaded @ %08x\n, __FUNCTION__, *loadaddr);
+
+   /* relocate sections */
+   for (i = 0; ; i++) {
+   memcpy(sec, data + hdr-segtable + i * sizeof(*sec), 
sizeof(*sec));
+   bswap_bebox_section(sec);
+fprintf(stderr, %s: section: offset %08x addr %08x size %d zsize %d \n, 
__FUNCTION__, sec-offset, sec-addr, sec-size, sec-zsize);
+   if (sec-size == 0  sec-zsize == 0)
+   break;
+   /* already there */
+   if (sec-addr == -1 || sec-addr == (hdr-addr + sec-offset))
+   continue;
+   rom_add_blob_z(filename, data + sec-offset, sec-size, 
sec-addr, sec-zsize);
+   }
+
+ret = hdr-size;
+
+out:
+if (data)
+qemu_free(data);
+close(fd);
+return ret;
+}
+
 /*
  * Functions for reboot-persistent memory regions.
  *  - used for vga bios and option roms.
@@ -640,6 +776,21 @@ int rom_add_blob(const char *name, const 

Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)

[François Revol]

Le 1 mars 2011 à 01:18, Natalia Portillo a écrit :

 Well, most of those emulators do not support the required mmu, except ARAnyM 
 (and their mmu patch was backported to UAE I think).
 That's the main problem, but first of all in QEMU there is the need for 
 complete pre-Coldfire 68ks, as well as the modular support for FPUs and MMU 
 (Sun and Apple's Lisa)

Yeah old Sun stuff used their own mmu due to missing support in pre-020 for 
some insn restart.

 Currently the fastest ones would be BeBox, Mac68k and NeXT machines, because 
 almost all devices are already emulated, but the assembly itself, firmware 
 and CPU/FPU/MMU in case of 68k.

IIRC the Mac68k hardware is quite obscure and model-dependant... but EMILE and 
BasiliskII should say enough.

Just posted my BeBox patch btw.

 A/UX would be fun to run :-)
 There used to be UNIX for Atari TT also IIRC, though not sure it was ever 
 published.
 There is a binary dump somewhere, I may have it.

So should I, just can't recall where I left it.

François.

Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)

[François Revol]

Le 1 mars 2011 à 13:02, Laurent Vivier a écrit :
 Currently the fastest ones would be BeBox, Mac68k and NeXT machines, 
 because almost all devices are already emulated, but the assembly itself, 
 firmware and CPU/FPU/MMU in case of 68k.
 
 IIRC the Mac68k hardware is quite obscure and model-dependant... 
 but EMILE and BasiliskII should say enough.
 
 They will not help you:
 - EMILE uses Mac ROM to access hardware
 - BasiliskII patches the ROM to call its internal drivers instead of
 accessing hardware.

Oh right, I was sure there was a trick somewhere :)

 The best source for hardware definition is linux...

Or NetBSD, if you don't have enough aspirin for Linux.
http://www.netbsd.org/ports/mac68k/

And I have an LCIII around for testing.

As well for the BeBox:
http://www.netbsd.org/ports/bebox/hardware.html

 If it can help I think I have all hardware reference manuals for m68k
 macintosh.

Actually I think they used to be online until recently, but Apple revamped 
their archived not too long ago IIRC.

François.

Re: [Qemu-devel] [RFC][PATCH] Preliminary BeBox support

[François Revol]

Le 2 mars 2011 à 22:59, Andreas Färber a écrit :

 Hello François,
 
 Am 01.03.2011 um 01:15 schrieb François Revol:
 
 Since Natalia raised the subject I though I'd post my current patch for the 
 BeBox support.
 I think the loader stuff can probably be committed already with some cleanup.
 The rest is mostly a copy of the prep file with tweaks and needs more work.
 The boot nub images can be extracted with this script:
 http://revolf.free.fr/beos/extract_bebox_images.sh
 Running -M bebox -bios bootnub.image makes it try to probe the PCI bridge 
 for now.
 Comments ?
 
 How does this relate to the BeBox emulation I started? I assume not at all?
 I tried to do the PEF parsing and nub extraction inside QEMU.
 http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/bebox

Eh, not at all, I didn't notice this one.
Hopefully I won't be dupping work anymore :p

 I'd prefer the BeBox machine to go into ppc_prep.c and to benefit from the 
 PReP cleanup that I started.

Yeah it needs some.

 I'll have a closer look the weekend, please cc me on future patches.

Ok.

François.

[Qemu-devel] OSX build issues

[François Revol]

The OSX build has been broken for some time now...

* qemu-thread-posix.c:
both qemu_mutex_timedlock and qemu_cond_timedwait make use of clock_gettime() 
and CLOCK_REALTIME, which OSX doesn't have.
It seems like both functions are nowhere found. Can they be removed then ?

* cpus.c:
qemu_kvm_eat_signals refers to sigbus_reraise which is defined conditionally on 
CONFIG_LINUX...
And OSX doesn't have sigtimedwait...
Any maintainer around who can fix it ?


François.

[Qemu-devel] Re: Re: [PATCH] Autodetect clock_gettime

[François Revol]

Le 15 mars 2011 à 14:58, Paolo Bonzini pbonz...@redhat.com a écrit :

 Some POSIX OSes (such as Darwin) doesn't have clock_gettime.  This patch
 falls back on gettimeofday if clock_gettime is not available.

Some code I've seen use #ifdef CLOCK_REALTIME but this doesn't seem right
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

 
 This may be okay as a stopgap measure, but any sane porting target for QEMU 
 should have a monotonic clock.  In fact, Darwin has it.
 
 Yes mach primitives could be used.  But why isn't a monotonic clock used on 
 Linux ?  


cf. 
http://www.virtualbox.org/browser/trunk/src/VBox/Runtime/r3/darwin/time-darwin.cpp

You might want to check this as well :
http://www.wand.net.nz/~smr26/wordpress/2009/01/19/monotonic-time-in-mac-os-x/

 According to man, CLOCK_MONOTONIC is monotonic
 while CLOCK_REALTIME isn't.

Yes that's the reason both exist actually...

 Unfortunately, pthread timed wait/lock functions are documented to use the 
 realtime clock by default.  Using pthread_condattr_setclock is probably not 
 portable enough, and anyway there is no such function for mutexes so we're 
 stuck with CLOCK_REALTIME.  What you're patching is fine, but those functions 
 might actually go away soon as they're not supported on Win32.

If you're talking about qemu_mutex_timedlock and qemu_cond_timedwait, I failed 
to grep them anywhere else than at their own definition.

 So, in addition to what you've done, you should probably use those Mach 
 primitives in qemu-timer.h.

Likely.
(though I'd like to get QEMU to just work again here first as I need it running 
for friday...)

François.

Re: [Qemu-devel] OSX build issues

[François Revol]

Le 15 mars 2011 à 22:03, Blue Swirl a écrit :

 On Mon, Mar 14, 2011 at 11:21 PM, François Revol re...@free.fr wrote:
 The OSX build has been broken for some time now...
 
 * qemu-thread-posix.c:
 both qemu_mutex_timedlock and qemu_cond_timedwait make use of 
 clock_gettime() and CLOCK_REALTIME, which OSX doesn't have.
 It seems like both functions are nowhere found. Can they be removed then ?
 
 This patch should fix the problem.
 0001-qemu-thread-delete-unused-functions.patch

It should fix the build issue.
But QEMU is unreliable on OSX even when it gets built.
I tried to bisect but lost some time trying to find a revision that actually 
builds. I thought I updated more this month...

55f8d6ac3e03d2859393c281737f60c65dfc9ab3 definitely works ok.
Then there are some thread-related changes which I suspect have side effects.
The guest starts but stales for a while several times, at least with Haiku.
And the screen (SDL, couldn't try with vnc since the OSX client violates the 
RFB specs and QEMU doesn't like it) stays white for some time, then is only 
updated a few times.
Then the IDE driver fails to get DMA working, disables the DMA and eventually 
goes a bit further.

François.

Re: [Qemu-devel] OSX build issues

[François Revol]

Hi,

Le 16 mars 2011 à 08:57, Tristan Gingold a écrit :

 It should fix the build issue.
 But QEMU is unreliable on OSX even when it gets built.
 I tried to bisect but lost some time trying to find a revision that actually 
 builds. I thought I updated more this month...
 
 55f8d6ac3e03d2859393c281737f60c65dfc9ab3 definitely works ok.
 
 J'utilise ce hack pour eviter ce probleme.

Indeed this hack works (quite a hack for someone working on ada :p)...

 diff --git a/cpus.c b/cpus.c
 index 5d14468..e976452 100644
 --- a/cpus.c
 +++ b/cpus.c
 @@ -548,6 +548,7 @@ static void qemu_tcg_init_cpu_signals(void)
 #ifndef CONFIG_IOTHREAD
 int qemu_init_main_loop(void)
 {
 +#if 0
 int ret;
 
 ret = qemu_signal_init();
 @@ -558,6 +559,7 @@ int qemu_init_main_loop(void)
 qemu_init_sigbus();
 
 return qemu_event_init();
 +#endif
 }
 
 void qemu_main_loop_start(void)

(Added a return 0 for the sake of it).

From the content of the functions called it's either one of the added fds which 
cause problem on select() (but why ?), or likely some signal masks which 
interfere with some internal thread in the process.

I sampled the process and took some screenshots without and with the #if 0 hack:
http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if0.png
Things work but oddly what is supposed to be an internal dispatcher thread ends 
up executing qemu code. The main thread includes lots of calls from arbitrary 
addresses indicating it receives some signals.

http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if1.png
Things stale, and there are 2 more threads that wait, and the main thread seems 
quite stuck in select().

François.

[Qemu-devel] qemu.org unreachable ?

[François Revol]

At least from france, confirmed by several people.

François.

traceroute to qemu.org (64.62.173.86), 64 hops max, 52 byte packets
 1  172.28.0.1 (172.28.0.1)  1.145 ms  0.960 ms  0.859 ms
 2  172.30.1.1 (172.30.1.1)  0.702 ms  0.786 ms  0.631 ms
 3  routeur-iut.iut-valence.fr (193.51.172.1)  1.207 ms  0.894 ms  0.878 ms
 4  r-val1.grenet.fr (194.214.50.1)  0.920 ms  0.996 ms  0.904 ms
 5  193.54.135.13 (193.54.135.13)  1.572 ms  3.565 ms  1.670 ms
 6  grenoble-valence.amplivia.fr (193.54.133.141)  6.838 ms  3.696 ms  3.771 ms
 7  * * *
 8  te1-3-lyon2-rtr-021.noc.renater.fr (193.51.189.110)  12.558 ms  12.544 ms  
14.353 ms
 9  te0-0-0-1-paris2-rtr-001.noc.renater.fr (193.51.189.2)  13.107 ms  13.642 
ms  12.555 ms
10  hurricane-electric.franceix.net (193.105.232.10)  18.148 ms  13.341 ms  
20.290 ms
11  10gigabitethernet1-3.core1.lon1.he.net (72.52.92.33)  21.393 ms  28.434 ms  
25.895 ms
12  10gigabitethernet7-4.core1.nyc4.he.net (72.52.92.77)  89.660 ms  89.808 ms  
90.473 ms
13  10gigabitethernet2-3.core1.ash1.he.net (72.52.92.86)  104.163 ms  95.601 ms 
 102.327 ms
14  10gigabitethernet1-4.core1.pao1.he.net (72.52.92.29)  164.219 ms  164.891 ms
10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109)  176.086 ms
15  lafrance-internet-services.gigabitethernet3-15.core1.fmt1.he.net 
(66.220.10.126)  173.076 ms  172.690 ms  172.628 ms
16  lafrance-internet-services.gigabitethernet3-15.core1.fmt1.he.net 
(66.220.10.126)  1625.419 ms !H *  1419.260 ms !H


PING qemu.org (64.62.173.86): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
92 bytes from lafrance-internet-services.gigabitethernet3-15.core1.fmt1.he.net 
(66.220.10.126): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 d1d7   0   31  01 1c40 172.28.1.225  64.62.173.86 

Re: [Qemu-devel] [PATCH 03/30] ppc: remove ppc440 bamboo board support

[François Revol]

Le -10/01/-28163 20:59, Anthony Liguori a écrit :
 This board never worked with TCG.  It hasn't been updated since 0.13.0.  I'm
 fairly sure hardware doesn't exist anymore that you can run the KVM support
 with.
 
 So let's remove it.  It can always be restored later if there is interest 
 again.


I'd like to have a ppc440 board around still...
I once pondered adding the sam440, but don't have the time.

Anyone looking into it ?

It'd be quite wow to have the latest Amiga X-1000 too but it has a very
custom chipset.

François.

Re: [Qemu-devel] [PATCH] Add basic read, write and create support for AMD SimNow HDD images.

[François Revol]

Hi,

Le 01/12/2010 11:38, Stefan Hajnoczi a écrit :
 This block driver does not implement the asynchronous APIs
 (bdrv_aio_writev, bdrv_aio_readv, bdrv_aio_flush) which are necessary
 for running a VM properly.  Some block drivers are currently written
 without async support and that limits them to being used as qemu-img
 formats.  It's a bad idea to run a VM with these block drivers because
 I/O will block the VM from making progress (it is synchronous).

I'm digging old stuff at the moment...
It seems to be the coroutine calls recently introduced makes aio
optional, does it ?

I added co versions of the calls in the code and it seems to work.
It passes the qemu-iotests:
Not run: 006 007 013 014 015 016 017 018 019 020 022 023 024 025 026 027 028
Passed all 11 tests

But before I submit the patch again I'll rather have it written correctly.

 +typedef struct BDRVHddState {
 +uint8_t identify_data[SECTOR_SIZE];
 
 Perhaps identify_data[] should be uint16_t since it gets casted on every use.

I tried doing so but you end up adding many other casts everywhere
and another #define to ...SIZE/sizeof(uint16_t) which doesn't look
better though.

 +static void padstr(char *str, const char *src, int len)
 +{
 +int i, v;
 +for(i = 0; i  len; i++) {
 +if (*src)
 +v = *src++;
 +else
 +v = ' ';
 +str[i^1] = v;
 +}
 +}
 
 This function is confusing, it uses int v instead of char.  The name
 padstr() doesn't hint that it also byteswaps the string.

Well it was copied verbatim from another file.
I now added a comment mentioning it.

 QEMU coding style uses {} even for one-line if statement bodies
 (Section 4 in the CODING_STYLE file).

Well it was copied verbatim from another file. :P

 +static int hdd_probe(const uint8_t *buf, int buf_size, const char *filename)
 
 HDD has no magic by which to identify valid files.  We need to avoid
 false positives because existing image files could be corrupted or VMs
 at least made unbootable.  Although using filename extensions to test
 for formats is lame, in this case I don't think we have another
 choice.

I suppose so, I didn't look any further but apart from checking the
geometry validity at several places in the header there is not much to
check for.

 +if (bdrv_read(bs-file, 0, s-identify_data, 1)  0) {
 +goto fail;
 +}
 
 We're assuming that BDRV_SECTOR_SIZE == SECTOR_SIZE == 512 throughout
 the code.  It would be safer to explicitly calculate against
 BDRV_SECTOR_SIZE.  It would be clearer to rename SECTOR_SIZE to
 ATA_IDENTIFY_SIZE.

Right, though the code would not work for SECTOR_SIZE != 512 since it's
the size of the header, so having it defined to something else would
make blocks unaligned anyway.
I'll use other defines but also an #error if SECTOR_SIZE doesn't fit to
make sure people don't try things without noticing.

 +/* TODO: specs says it can grow, so no need to always do this */
 +if (static_image) {
 +if (ftruncate(fd, sizeof(header) + blocks * SECTOR_SIZE)) {
 +result = -errno;
 +}
 +}
 
 Is there an issue with leaving ftruncate() out?  I don't see a reason
 to truncate.  If we want to preallocate then ftruncate() isn't
 appropriate anyway.

Right, it doesn't write zeroes on ext2 anyway.
I'd have to test without it first.

François.

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[François Revol]

Le -10/01/-28163 20:59, Laurent Vivier a écrit :

Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit :

On 08/17/2011 03:46 PM, Bryce Lanham wrote:

These patches greatly expand Motorola 68k emulation within qemu, and are what I 
used as a basis for my
Google Summer of Code project to add NeXT hardware support to QEMU.


Please don't crap flood the list with a series of 100 patches.

Split things into logical chunks such that a series can be reasonably
reviewed and applied.


And I'm not sure this series of patches is ready for inclusion in qemu
mainline as it should break existing m68k emulation...

Bryce, you should only post your patches, refering to the repository on
which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git ,
master branch.



Btw, are you planning on merging it back someday?

François.

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions

[François Revol]

Le 19/08/2011 04:14, Natalia Portillo a écrit :

Hi,



[...]
(no need to quote the full thread!)



He worked on emulating an abandoned, strange, difficult to get, and 
undocumented hardware, using your 111 patches, and finished it before the wholy 
more experienced MESS team.


The next-cube emulation is really working ?


Yes, it is, absolutely.


Cool I need to add this target to my Haiku port... where are the docs 
for the boot process ?




Why are you planning to port a hack instead of making a full machine
emulation?


Because I'm lazy and dumb: the work is already done, I like cut'n'paste.


Yeah, you said it!
The work is already done, we have all the hardware emulation that Basilisk 
substitutes for hacks.


I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no
video card, no SWIM, no SCSI, ... useless with a patched ROM.


Macs do not have videocards :p, only the Mac II and we're not forced to emulate 
that one.
SWIM is a piece of cake that can be even implemented without ICs, just some 
logical arrays.
NuBus is not required for almost anything, only the video card uses it, and 
it's present only on the Mac II, a stub will suffice to make Toolbox be happy.
Most m68k didn't include a network card, third party ones are stock chips 
(probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are 
also stock, easy to do :p


NIC isn't really necessary at first, those things don't netboot anyway, 
do they ?



The MMU is your part I won't discuss on it.


There is 040 mmu support in ARAnyM (Atari Running on Any Machine), 
enough to run Linux, that has been backported to UAE (ARAnyM is based on 
the UAE core), that should give some hints:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201442
http://www.amigaemulator.org/patches
http://www.amigaemulator.org/bin/patches/mmu/uae-0.8.20.2-mmu.diff.gz
(though I fixed a bug in handling TTR1 in ARAnyM)

It's why I chose to go Falcon first and use ARAnyM for the 68k Haiku port.

The 030 or 68551 ones are much more complex though (the 040 one has a 
fixed table layout, others have fully configurable table size for all 
the 4 levels). The 060 one is just the 040 with some cache restrictions.



I know it's not perfect, but right now, it's better than nothing.
There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a 
lot on that when he was working on LisaEm.
However emulators are live, Aranym, UAE, LisaEm, BasiliskII.

qemu-m68k is quite complete to go live (when it does not break mcoldfire) right 
now.
Bugs are easy to be corrected by more people when they are in main than in a 
developer's own clone.

Leave your little kid go wild, it's old and big enough :p


Release early, release often :p

François.

Re: [Qemu-devel] When will the Q35 chipset be merged into Qemu mainstream

[François Revol]

Le -10/01/-28163 20:59, Adnan Khaleel a écrit :

PCI express support has been made available for quite sometime now with patches 
from Isaku Yamahata for the Q35 chipset for Qemu 0.12 and then for Qemu 0.14. 
However, Qemu 0.15 has been released but support for the Q35 chipset is still 
not officially included.

At what point will Qemu merge the Q35 chipset code for PCIexpress?


I'm afraid you're chasing the wrong rabbit here if you send patches 
against releases.

Development happens on the git tree, so patches should be against HEAD.
Sending patches against (old by definition) releases implies someone 
must do the merge since usually many things have diverged since then.

Specially with the recent move to Glib and other qdevice or whatever API.

So you'll maximize luck by sending patches against HEAD as it removes 
most merging trouble.


Another way is to fork the git tree, apply your current patch, handle 
the merge yourself and send pull request instead of the patch.


Still, I recall having to wait 3 year for my wacom tablet fix (which was 
just a fix) to be applied, so be patient :P


François.

Re: [Qemu-devel] QEMU was not selected for Google Summer of Code this year

[François Revol]

On -10/01/-28163 20:59, Stefan Hajnoczi wrote:
 Sad news - QEMU was not accepted for Google Summer of Code 2012.
 

Shame, there is so much to do.

 Students can consider other organizations in the accepted
 organizations list here:
 
 http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012
 
 The list is currently not complete but should be finalized over the
 next few days as organizations complete their profiles.

I just heard Haiku is on the accepted list.

Last year a student worked on finishing the VirtualBox guest additions I
started writing:
https://www.haiku-os.org/blog/scgtrp/2011-09-05_vbox_guest_additions_slightly_late_final_progress_report

It should be possible to come up with a project involving QEMU on Haiku
if anyone is interested.
While there is an existing QEMU port, I'm not sure in what state it
currently is.

QEMU proved useful to Haiku developers up to now, cf.
http://revolf.free.fr/beos/quf-haiku-qemu-abstract.pdf

 
 Students and mentors who wanted to participate with QEMU will be
 disappointed.  I am too but there are many factors that organizations
 are considered against, we have not received information why QEMU was
 rejected this year.

Well, ReactOS tried and failed several times to be accepted without
being given any reason, if that is of any comfort.

François.

Re: [Qemu-devel] QEMU was not selected for Google Summer of Code this year

[François Revol]

On 19/03/2012 18:28, Andreas Färber wrote:
 Am 16.03.2012 23:11, schrieb François Revol:
 It should be possible to come up with a project involving QEMU on Haiku
 if anyone is interested.
 While there is an existing QEMU port, I'm not sure in what state it
 currently is.
 
 Haiku is missing a GLib OptionalPackage, and I have so far not finished
 collecting all the prerequisites to build it from git - to ./autogen.sh
 glib you needs gtk-doc, gtk-doc needs gnome-common or what-not. Also
 HaikuPorts, like many of the ports systems, is collecting recipes to
 build stable versions and stopping there rather than focussing on fixing
 issues upstream, so that the porting doesn't need to be done all over
 again... GLib still doesn't seem to have Haiku support after three+ years.

Welcome to dependency hell.
I'm not guilty for GLib, I usually send things upstream.

François.

Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)

[François Revol]

On -10/01/-28163 20:59, Stefan Weil wrote:
 Am 27.02.2012 00:46, schrieb Anthony Liguori:
 I realize UIs are the third rail of QEMU development, but over the
 years I've
 gotten a lot of feedback from users about our UI. I think everyone
 struggles
 with the SDL interface and its lack of discoverability but it's worse
 than I
 think most people realize for users that rely on accessibility tools.
[...]

While I do think accessibility is important...

 These are solved problems though and while we could reinvent all of this
 ourselves with SDL, we would be crazy if we did. Modern toolkits, like
 GTK,
 solve these problems.

GTK itself causes problems, because, it's not ported, thus not
available, to all platforms QEMU can run on.

It's certainly not available on Haiku at least.

Of course, SDL itself is not really a good candidate to add a11y
features, due to its framebuffer-based design...


 By using GTK, we can leverage VteTerminal for screen reader
 integration and font
 configuration. We can also use GTK's accelerator support to make
 accelerators
 configurable (Gnome provides a global accelerator configuration
 interface).

Hmm the thing using libvte that uses /tmp to insecurely store terminal
backlogs ? ;-)

[snip]

 As soon as the GTK UI is considered stable and usable, the default
 could be changed from SDL to GTK.

Due to GTK not being as universally available as SDL, I'd really like
not to.

François.

Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)

[François Revol]

On 12/03/2012 03:31, Anthony Liguori wrote:
 On 03/11/2012 01:24 PM, François Revol wrote:
 GTK itself causes problems, because, it's not ported, thus not
 available, to all platforms QEMU can run on.

 It's certainly not available on Haiku at least.
 
 There is no perfect solution here.  I think GTK is the best that's out
 there.

Well as long as it's not mandatory...

 By using GTK, we can leverage VteTerminal for screen reader
 integration and font
 configuration. We can also use GTK's accelerator support to make
 accelerators
 configurable (Gnome provides a global accelerator configuration
 interface).

 Hmm the thing using libvte that uses /tmp to insecurely store terminal
 backlogs ? ;-)
 
 Yeah, I saw it on a blog, it must be true!

Well it is true, just fill up your /tmp and see the backlog stop working
in gnome-terminal. I did it unintentionally the other day... :P

François.

[Qemu-devel] [PATCH] Add mmubooke_dump_mmu

[François Revol]

The following patch adds some support for dumping the TLBs of type
TLB_EMB, at least enough to see the mappings.
I wasn't sure how to deal with the flags anyway, it seems to me the
struct lacks some stuff needed for system emulation, so it will probably
need some revamping for the new target I'm adding.

François.

Signed-off-by: François Revol re...@free.fr

diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index c610ce3..c998efc 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1466,6 +1466,52 @@ static const char *book3e_tsize_to_str[32] = {
 1T, 2T
 };

+static void mmubooke_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
+ CPUPPCState *env)
+{
+ppcemb_tlb_t *entry;
+int i;
+
+if (kvm_enabled()  !env-kvm_sw_tlb) {
+cpu_fprintf(f, Cannot access KVM TLB\n);
+return;
+}
+
+cpu_fprintf(f, \nTLB:\n);
+cpu_fprintf(f, Effective  Physical   Size PID
Prot Attr\n);
+
+entry = env-tlb.tlbe[0];
+for (i = 0; i  env-nb_tlb; i++, entry++) {
+target_phys_addr_t ea, pa;
+target_ulong mask;
+uint64_t size = (uint64_t)entry-size;
+char size_buff[20];
+
+/* Check valid flag */
+if (!(entry-prot  PAGE_VALID)) {
+continue;
+}
+
+mask = ~(entry-size - 1);
+ea = entry-EPN  mask;
+pa = entry-RPN  mask;
+#if (TARGET_PHYS_ADDR_BITS = 36)
+/* Extend the physical address to 36 bits */
+pa |= (target_phys_addr_t)(entry-RPN  0xF)  32;
+#endif
+size /= 1024;
+if (size = 1024)
+snprintf(size_buff, sizeof(size_buff), %3 PRId64 M,
size / 1024);
+else
+snprintf(size_buff, sizeof(size_buff), %3 PRId64 k, size);
+cpu_fprintf(f, 0x%016 PRIx64  0x%016 PRIx64  %s %-5u %08x
%08x\n,
+(uint64_t)ea, (uint64_t)pa,
+size_buff, (uint32_t)entry-PID,
+entry-prot, entry-attr);
+}
+
+}
+
 static void mmubooke206_dump_one_tlb(FILE *f, fprintf_function cpu_fprintf,
  CPUPPCState *env, int tlbn, int
offset,
  int tlbsize)
@@ -1561,6 +1607,9 @@ static void mmubooks_dump_mmu(FILE *f,
fprintf_function cpu_fprintf,
 void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUPPCState *env)
 {
 switch (env-mmu_model) {
+case POWERPC_MMU_BOOKE:
+mmubooke_dump_mmu(f, cpu_fprintf, env);
+break;
 case POWERPC_MMU_BOOKE206:
 mmubooke206_dump_mmu(f, cpu_fprintf, env);
 break;

Re: [Qemu-devel] [PATCH] Add mmubooke_dump_mmu

[François Revol]

On 24/04/2012 18:22, François Revol wrote:
 The following patch adds some support for dumping the TLBs of type
 TLB_EMB, at least enough to see the mappings.
 I wasn't sure how to deal with the flags anyway, it seems to me the
 struct lacks some stuff needed for system emulation, so it will probably
 need some revamping for the new target I'm adding.
 
 François.
 

Ditch that, I'll use git to send it, icedove finally discovered how to
line-wrap at the worst moment.

François.

[Qemu-devel] [PATCH] target-ppc: Some support for dumping TLB_EMB TLBs

[François Revol]

Add mmubooke_dump_mmu().

TODO: Add printing of individual flags.

Signed-off-by: François Revol re...@free.fr
---
 target-ppc/helper.c |   49 +
 1 file changed, 49 insertions(+)

diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index c610ce3..c998efc 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1466,6 +1466,52 @@ static const char *book3e_tsize_to_str[32] = {
 1T, 2T
 };
 
+static void mmubooke_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
+ CPUPPCState *env)
+{
+ppcemb_tlb_t *entry;
+int i;
+
+if (kvm_enabled()  !env-kvm_sw_tlb) {
+cpu_fprintf(f, Cannot access KVM TLB\n);
+return;
+}
+
+cpu_fprintf(f, \nTLB:\n);
+cpu_fprintf(f, Effective  Physical   Size PID   Prot 
Attr\n);
+
+entry = env-tlb.tlbe[0];
+for (i = 0; i  env-nb_tlb; i++, entry++) {
+target_phys_addr_t ea, pa;
+target_ulong mask;
+uint64_t size = (uint64_t)entry-size;
+char size_buff[20];
+
+/* Check valid flag */
+if (!(entry-prot  PAGE_VALID)) {
+continue;
+}
+
+mask = ~(entry-size - 1);
+ea = entry-EPN  mask;
+pa = entry-RPN  mask;
+#if (TARGET_PHYS_ADDR_BITS = 36)
+/* Extend the physical address to 36 bits */
+pa |= (target_phys_addr_t)(entry-RPN  0xF)  32;
+#endif
+size /= 1024;
+if (size = 1024)
+snprintf(size_buff, sizeof(size_buff), %3 PRId64 M, size / 
1024);
+else
+snprintf(size_buff, sizeof(size_buff), %3 PRId64 k, size);
+cpu_fprintf(f, 0x%016 PRIx64  0x%016 PRIx64  %s %-5u %08x %08x\n,
+(uint64_t)ea, (uint64_t)pa,
+size_buff, (uint32_t)entry-PID,
+entry-prot, entry-attr);
+}
+
+}
+
 static void mmubooke206_dump_one_tlb(FILE *f, fprintf_function cpu_fprintf,
  CPUPPCState *env, int tlbn, int offset,
  int tlbsize)
@@ -1561,6 +1607,9 @@ static void mmubooks_dump_mmu(FILE *f, fprintf_function 
cpu_fprintf,
 void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUPPCState *env)
 {
 switch (env-mmu_model) {
+case POWERPC_MMU_BOOKE:
+mmubooke_dump_mmu(f, cpu_fprintf, env);
+break;
 case POWERPC_MMU_BOOKE206:
 mmubooke206_dump_mmu(f, cpu_fprintf, env);
 break;
-- 
1.7.10

[Qemu-devel] [PATCH] [RFC] PPC: dump DCRs from monitor

[François Revol]

Hi,
I noticed the DCRs weren't shown with the registers or another command,
and tried to add one to dump them to help debugging my sam460ex target.
This first version doesn't list the names since they aren't registered
as such.
I tried adding a name arg to ppc_dcr_register, and a #define to get it
from the index, but it seems some code uses a loop to register them, so
it gives a dump like:
DCR[SDRAM0_CFGDATA 11]  
DCR[dcr_base + i c0]
DCR[dcr_base + i c1]
Any suggestion?
BTW, they aren't saved in state dumps, are they?

François.

diff --git a/cpu-all.h b/cpu-all.h
index 5e07d28..a34ae25 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -372,6 +372,8 @@ void cpu_dump_state(CPUArchState *env, FILE *f,
fprintf_function cpu_fprintf,
 int flags);
 void cpu_dump_statistics(CPUArchState *env, FILE *f, fprintf_function
cpu_fprintf,
  int flags);
+void ppc_dump_dcr(CPUArchState *env, FILE *f, fprintf_function cpu_fprintf,
+  int flags);

 void QEMU_NORETURN cpu_abort(CPUArchState *env, const char *fmt, ...)
 GCC_FMT_ATTR(2, 3);
diff --git a/hw/ppc.c b/hw/ppc.c
index 98546de..74b82b7 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -1120,6 +1120,27 @@ int ppc_dcr_init (CPUPPCState *env, int
(*read_error)(int dcrn),
 return 0;
 }

+void ppc_dump_dcr (CPUPPCState *env, FILE*f, fprintf_function cpu_fprintf,
+   int flags)
+{
+ppc_dcr_t *dcr_env;
+ppc_dcrn_t *dcr;
+int dcrn;
+
+dcr_env = env-dcr_env;
+if (dcr_env == NULL)
+return;
+
+for (dcrn = 0; dcrn  DCRN_NB; dcrn++) {
+dcr = dcr_env-dcrn[dcrn];
+if (dcr-dcr_read == NULL)
+continue;
+
+cpu_fprintf(f, DCR[%02x] %08x\n, dcrn,
+dcr-dcr_read(dcr-opaque, dcrn));
+}
+}
+
 /*/
 /* Debug port */
 void PPC_debug_write (void *opaque, uint32_t addr, uint32_t val)
diff --git a/monitor.c b/monitor.c
index b17b1bb..b7a2a4b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -936,6 +936,14 @@ static void do_info_cpu_stats(Monitor *mon)
 env = mon_get_cpu();
 cpu_dump_statistics(env, (FILE *)mon, monitor_fprintf, 0);
 }
+
+static void do_info_dcr(Monitor *mon)
+{
+CPUArchState *env;
+
+env = mon_get_cpu();
+ppc_dump_dcr(env, (FILE*)mon, (fprintf_function)monitor_printf, 0);
+}
 #endif

 static void do_trace_print_events(Monitor *mon)
@@ -2768,6 +2776,15 @@ static mon_cmd_t info_cmds[] = {
 .mhandler.info = tlb_info,
 },
 #endif
+#if defined(TARGET_PPC)
+{
+.name   = dcr,
+.args_type  = ,
+.params = ,
+.help   = show device control registers,
+.mhandler.info = do_info_dcr,
+},
+#endif
 #if defined(TARGET_I386)
 {
 .name   = mem,

Re: [Qemu-devel] [PATCH] [RFC] PPC: dump DCRs from monitor

[François Revol]

On 29/08/2012 16:53, Alexander Graf wrote:
 
 
 On 29.08.2012, at 04:03, François Revol re...@free.fr wrote:
 
 Hi,
 I noticed the DCRs weren't shown with the registers or another command,
 and tried to add one to dump them to help debugging my sam460ex target.
 This first version doesn't list the names since they aren't registered
 as such.
 I tried adding a name arg to ppc_dcr_register, and a #define to get it
 from the index, but it seems some code uses a loop to register them, so
 it gives a dump like:
 DCR[SDRAM0_CFGDATA 11]
 DCR[dcr_base + i c0]
 DCR[dcr_base + i c1]
 Any suggestion?
 BTW, they aren't saved in state dumps, are they?
 
 Are they accessible through the monitor's p command? Would be good to 
 implement there too if not.

I don't think so, which syntax would you use anyway? $dcr[n] ?


François.

Re: [Qemu-devel] [PATCH] [RFC] PPC: dump DCRs from monitor

[François Revol]

On 29/08/2012 19:55, Alexander Graf wrote:
 Are they accessible through the monitor's p command? Would be good to 
 implement there too if not.

 I don't think so, which syntax would you use anyway? $dcr[n] ?
 
 Sure, why not? Is that possible with the register parsing code? I don't know 
 that one too well,
 but it's probably the best fit for you, right?

Except I don't know the parsing code well enough to not waste time
digging it...
For now the full dump is enough to me, I suppose if someone wants more
he can also send a patch ;-)

We could also add logging to the read/write calls to see the ordering.
For now I just added some printf in my code just like in ppc405*.

François.

Re: [Qemu-devel] Compiling qemu to emulate AMCC's PPC440GX eval board

[François Revol]

On 03/11/2012 09:03, Peter Teoh wrote:
 Can I know if it is possible to run software which were running on AMCC
 PPC440GX eval board (eg, LynxOS) on qemu emulator?   I can see a lot of
 440GX symbols inside QEMU source code, but no where can I find someone who
 has done it successfully.   Even qemu-system-ppc -cpu ? does not return
 440GX as one of the supported CPU.   Neither does qemu-system-ppc -M ?
 return the board that support 440GX (for example Taishan or Ocotea board).

AFAIK most embedded board definitions only have enough support to boot
Linux, but not their own firmware or other OSes. Many onchip devices
required to use the firmware are missing, and the only direct kernel
loading mechanism available is the Linux one.

For my Haiku Sam460ex port I started writing a sam460ex target but it's
not published yet nor finished.
It can start our own bootloader faking a Linux kernel, and has enough
faked onchip devices to start the U-Boot image but doesn't get far yet
inside it.


François.

Re: [Qemu-devel] AmigaOS 4.x on QEMU

[François Revol]

On 25/01/2014 01:20, BALATON Zoltan wrote:
 On Sun, 12 Jan 2014, Alpha Mule wrote:
 Hi. AmigaOS 4.x runs natively on some niche PowerPC boards. I was
 wondering about the viability of running AmigaOS 4.x on QEMU.

 Specifically, I was wondering if there has been any development on
 that and/or what needs to be done to get it fully working.

 Any information would be appreciated. Thanks.
 
 Looks like not much info is available on this... I think that the first
 difficulty is that AmigaOS 4.x is not freely available (AFAIK) so it's
 hard to do any testing with it.
 
 I've found that a demo version of MorphOS (which is not the same but
 runs on similar hardware) is available and runs on some Mac hardware
 that may be closer to what qemu already has support for so it may be an
 easier target to test.

Unlike MorphOS which supports some PPC Mac machines, AmigaOS 4.x only
supports some specific hardwares, AFAIK, like the X-1000 from A-EON, and
the Sam440 and Sam460ex boards from ACube.

I'm currently porting Haiku to the Sam460ex board, so I started adding
support for it to QEMU locally, including enough to get the custom
U-Boot to start, but it's far from finished, U-Boot still fails before
POST (something to do with enumerating RAM).

As for AmigaOS4, it uses a custom stage2 bootloader which requires some
exported functions from the specific U-Boot (why they didn't use and
extend the official U-Boot calls I don't know), so you won't be able to
boot it with -kernel anyway, unlike Haiku which stage2 loader currently
fakes a Linux kernel for non-x86 archs.

I don't know when I'll have time to clean that up and put it online yet.

François.

Re: [Qemu-devel] Raspbian in QEMU

[François Revol]

On 20/03/2014 13:36, Paolo Bonzini wrote:
 Il 12/03/2014 21:01, Peter Maydell ha scritto:
 On 12 March 2014 19:41, Richard Henderson r...@twiddle.net wrote:
 Ew.  No.  It would be easier to just implement setend, even if badly.

 Agreed.

 For my part, the endian-aware load/store opcodes I alluded to last
 August are now in.

 Yes, it would be fairly straightforward to implement setend now.
 I haven't actually looked at it, though, because the only thing that
 uses it is this raspi memcmp code, and there's a workaround
 for that. So other things have been higher priority.
 
 I looked at that yesterday and it took me exactly one hour... I'll
 submit it for 2.1 since I'm interested (for non-work reasons) in
 Raspberry Pi emulation.

Just so you don't start rewriting the wheel:

https://github.com/Torlus/qemu/tree/rpi

I'm not sure how far he went yet though.

François.

Re: [Qemu-devel] Announcing QEMU Advent Calendar 2014

[François Revol]

On 24/11/2014 17:15, Stefan Hajnoczi wrote:
 The QEMU Advent Calendar is launching on December 1st 2014:
 
 http://www.qemu-advent-calendar.org/
 
 Each day until Christmas (or until we run out) a new QEMU disk image
 will be posted for you to enjoy.
 
 The disk images showcase interesting guest operating systems, demos,
 and software that runs under QEMU.
 
 Want to contribute a disk image?  Send a description, QEMU
 command-line, and the disk image (or download link) to
 stefa...@gmail.com.  Disk images must be freely redistributable.

I can probably propose a Haiku nightly :)


Btw, that would be a good opportunity to relaunch the Free Live OS Zoo:
http://floz.sourceforge.net/

François.

Re: [Qemu-devel] [PATCH] Makefile.target: set icon for binary file on Mac OS X

[François Revol]

On 20/02/2015 13:36, Paolo Bonzini wrote:
 
 
 On 20/02/2015 13:18, Peter Maydell wrote:
 Why not just use the sips --out option to specify a different
 output file? That way we automatically put the current icon
 into the executable, and don't have to update a hand-created
 qemu.rsrc file in git if we change the icon in future (and I
 bet if we don't have the rules for doing this in the makefile
 then nobody will remember how to do it).
 
 I suspect the Windows icon is not a great match for Mac OS X which likes
 to have big sizes (48x48 or 128x128).  If you want to generate the .rsrc
 file automatically, the right source probably would be the .svg file,
 and doing the conversion in the Makefile probably isn't entirely
 feasible.  It would need extra build dependency and rounding errors
 would make it harder to achieve reproducible builds.

And depending on the complexity of the SVG not all methods produce the
same result. Although it was years ago I recall having a hard time
getting gradients to render correctly with ImageMagick. You'll want to
compare the ImageMagick/GraphicsMagick and rsvg (apt:librsvg2-bin on
Debian) outputs.
Although the current ImageMagick seems to work fine on the logo here.
But you'll have to find how to properly specify the size of the SVG (and
not use -scale since it'll resize the bitmap, and make it 128x127).

OTOH:

rsvg-convert -w 128 -h 128 ./pc-bios/qemu_logo_no_text.svg  qemu-r.png

seems to generate a proper png with transparency.

It seems inkscape can do it as well, but it's probably a larger dependency:

http://stackoverflow.com/questions/9853325/how-to-convert-a-svg-to-a-png-with-image-magick


François.

Re: [Qemu-devel] [PATCH] Haiku: Platform build fixes

[François Revol]

On 24/03/2015 23:56, Max Filippov wrote:
 On Wed, Mar 25, 2015 at 1:26 AM, Andreas Färber afaer...@suse.de wrote:
 Am 24.03.2015 um 00:36 schrieb Alexander von Gluck IV:


 Why convert from array to switch statement? It looks like a very
 invasive change for no obvious reason.
 
 I'd be interested to know the reason too, but I'm OK with either way.

Maybe because negative array indices are usually a bad idea in C?
Are the host errno codes used there actually?

François.

Re: [Qemu-devel] [PATCH] Haiku: Platform build fixes

[François Revol]

On 25/03/2015 00:40, Andreas Färber wrote:
 Am 25.03.2015 um 00:11 schrieb Max Filippov:
 On Wed, Mar 25, 2015 at 2:03 AM, François Revol re...@free.fr wrote:
 On 24/03/2015 23:56, Max Filippov wrote:
 On Wed, Mar 25, 2015 at 1:26 AM, Andreas Färber afaer...@suse.de wrote:
 Am 24.03.2015 um 00:36 schrieb Alexander von Gluck IV:


 Why convert from array to switch statement? It looks like a very
 invasive change for no obvious reason.

 I'd be interested to know the reason too, but I'm OK with either way.

 Maybe because negative array indices are usually a bad idea in C?

 Sounds like a good reason (:
 
 True, but assumes that error codes are indeed negative.
 
 AFAIU linking with -lposix_error_helper or so (- configure/Makefile*)
 may be an alternative, keeping errors POSIX-compliant in our code. I
 don't recall the implementation details though...

Indeed, although it doesn't solve everything (some things like nginx
want to use deprecated things like sys_errlist[] (although they dropped
this) or assume the codes are all  some very low positive value), and I
suspect it could have strange side effects on code used as a library by
other things.

As for myself, I consider POSIX to be boggus (they even changed their
mind in some places) and error prone on this (I've ported enough foreign
code to assert this) :p

François.

Re: [Qemu-devel] GSoC 2015 (Mac OS 9 support) report, week 8

[François Revol]

On 24/06/2015 02:35, Alexander Graf wrote:
 [Done]
   - Fix ppc: mem_claim() and mmu_claim()
 - Initial patch has been sent to the OpenBIOS mailing list.
 - Newest version submitted and waiting to be pushed to trunk.


Cool, maybe someday Haiku will boot on ppc there!

François.

Re: [Qemu-devel] [PATCH 00/12] Audio backend cleanup

[François Revol]

On 02/06/2015 13:40, Michael Tokarev wrote:
 Yes, that's true.  As long as the native version actually works.
 As I said before, initially it didn't, and sdl was the only
 driver that worked.  Maybe in 0.12, maybe even before, I don't
 remember anymore, but the fact remains, in our testing only
 sdl was more or less adequate, maybe due to pure luck or
 phase of moon. Later native drivers started working, so we
 started using native driver which is default to the OS, which
 is pulseaudio (installed on all desktop environments) or,
 failing that, alsa (native to linux).


Btw, please consider that ports to new host platforms really benefit
from SDL for those things. For example we've been using SDL for the
Haiku port until last year:

http://bb.haikuports.org/haikuports/commits/df441da15a7c4a5583f6460de2ca1d570d0caee1

All other backends are either *nix only like OSS (Haiku has an OSS port
but only uses its drivers, the API is not made public), or even
Linux-only like PA or ALSA. There are more OSes out there than just
GNU/Linux :p

It's already hard enough to get stuff upstream into QEMU, having to
write native audio and graphics backends before things get usable won't
help at all.


François.

Re: [Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

[François Revol]

On 17/11/2015 23:14, Rob Herring wrote:
> On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini  wrote:
>>
>>
>> On 15/11/2015 03:07, Rob Herring wrote:
>>> We generally don't want DT docs to depend on other kernel documentation.
>>
>> DT docs do not contain a copy of the data sheets, either.  There is no
>> reason to say how to use the device (and even then, only doing so
>> partially) in the DT docs.
> 
> The difference is datasheets apply to all OS's, kernel documentation
> does not. In theory at least this could be used for other OS's, right?

Would be nice indeed, as it's part of their intended purpose.

For now we have to shoehorn things into linux-only stuff (like initrd)
because well, nobody cares enough about NetBSD to compile U-Boot with
its internal API, so let alone adding custom Haiku code.

And of course, for things linux doesn't care about (like framebuffer
description) then we're stuck trying to guess where it's at and writing
drivers for our bootloader.

So if at least people were considering they aren't the only users of
this, that'd make life better for everyone.

> Perhaps QEMU is the right place to thoroughly describe this and DT and
> sysfs docs can refer to it.

The brilliant idea of FDT was that we could have a canonical source and
blob for it where people could send patches, but of course Linux and BSD
freaks disagreed, so you now find Linux-flavoured DTs for rPi and other
things, as well as BSD versions.

Please, at least get the binding documentation for this unique and
usable for everyone!

François.

Re: [Qemu-devel] [Bug 925405] Re: VNC server does not work with Mac Screen Sharing

[François Revol]

On 01/01/2017 17:55, Rui Carmo wrote:

Hey there. Will git tip from September do? At that time I built QEMU on
Ubuntu 16.04.1, pointed my Mac (10.10) at it again and had the same
experience (had to use a third-party client)

Considering I opened this four years ago, I'm kind of surprised it's
still a talking topic. Was kind of expecting more people to report it,
but then again Launchpad is a bit off the beaten path these days and
most people just sigh and fetch a third party client.

It's just that it seems like a trivial thing to fix overall, so I
thought it worthwhile to chime in - Happy New Year!




For what it's worth, it's a bug in Apple's client which despite them 
claiming to "use the industry standard VNC" (whatever that means) 
clearly violates the VNC specs by replying with a boggus protocol 
version number.


I told them 5 years ago but it's not like they care about respecting 
standards...


François.

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH 09/12] ppc440: Add emulation of plb-pcix controller found in some 440 SoCs

[François Revol]

Le 18/08/2017 à 21:43, luigi burdo a écrit :
> can i ask you something ? why you dont try to integrate in qemu the
> pegasos 2 or the efika machine. i have the feeling that probably it
> can be more simple because more old machine and components.
> 

Except they are antique, and the Pegasos at least has an horribly buggy
OpenFirmware implementation.

I'd rather work on BeBox support ;-)

François.

Re: [Qemu-devel] [PATCH 15/15] ppc: Add aCube Sam460ex board

[François Revol]

Le 23/08/2017 à 13:12, BALATON Zoltan a écrit :
>> What's the connection with mips_malta?
> 
> The board's firmware wants to see SPD EEPROMs of the connected memory
> while initialising the memory controller. This is why we need to
> implement SDRAM controller, I2C and SPD EEPROMs. MIPS malta board had
> already SPD EEPROM implementation so this is based on that. The comment
> just indicates where this code comes from.

Indeed, and I copy-pasted from elsewhere for this.

>>> +fprintf(stderr, "qemu: Error registering flash memory.\n");
>>
>> Use error_report() instead, please.

I guess this didn't exist back when I started writing it...

>>> +/* Create reset TLB entries for BookE, mapping only the flash
>>> memory.  */
>>> +static void mmubooke_create_initial_mapping_uboot(CPUPPCState *env)
>>> +{
>>> +ppcemb_tlb_t *tlb = >tlb.tlbe[0];
>>> +
>>> +/* on reset the flash is mapped by a shadow TLB,
>>> + * but since we don't implement them we need to use
>>> + * the same values U-Boot will use to avoid a fault.
>>> + */
>>
>> Usually the reset state of the MMU is handled in the cpu code rather
>> than the board code.  Is there a specific reason you need it in the
>> board code here?
> 
> I'm not sure, probably lack of a better place. The ppc440_bamboo board
> this is based on has it the same way in the board code. Maybe this could
> be cleaned up when someone wants to QOMify the SoC models sometimes.

Thing is, the code allows both booting with U-Boot and with a kernel
directly, and the MMU mapping differ in those cases.

Maybe the CPU reset should use the U-Boot setup and the kernel boot
would just overwrite it?

>>> +env->nip = bi->entry;
>>> +
>>> +/* Create a mapping for the kernel.  */
>>> +mmubooke_create_initial_mapping(env, 0, 0);
>>> +env->gpr[6] = tswap32(EPAPR_MAGIC);
>>
>> I'm pretty sure the tswap can't be right here.  env->gpr is in host
>> native order and I'd expect the constant to be as well.
> 
> I know nothing about this, maybe Francois remembers why it's there. But
> booting linux with -kernel works so it's probably either correct or does
> not matter.

Absolutely no idea. It seems to be there from the first commit in my own
history here.

I don't recall testing booting linux at all though.
Linux does check the magic, so it'd be weird if it booted:

https://github.com/torvalds/linux/blob/master/arch/powerpc/boot/epapr.c

But maybe it got added later than the version you tested?

At least my current Haiku port ignores the magic for now.

>>> +env->gpr[7] = (16 << 20) - 8; /*bi->ima_size;*/
>>
>> So, entering the kernel directly can be useful, particularly during
>> early development.  However, having both firmware and non-firmware
>> entry paths can lead to confusing bugs if there's a subtle difference
>> between the initial (to the kernel) states between the two paths.  For
>> that reason, the usual preferred way to implement -kernel is to still
>> run the usual firmware, but use some way of telling it to boot
>> immediately into the supplied kernel.
>>
>> I won't object to merging it this way - just a wanrning that this may
>> bite you in the future if you're not careful.
> 
> Warning taken, at this point until firmware cannot reliably boot things
> having another way to test is useful to have. In the future when booting
> via firmware works well we can figure out what to do with this.

Possibly we could dig the U-Boot environment...

>>> +memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(),
>>> + 0, 0x1);
>>> +memory_region_add_subregion(get_system_memory(), 0xc0800, isa);
>>
>> Does it really make sense to just embed the ISA IO space here, rather
>> than actually instanting a PCI<->ISA bridge?
> 
> I'm not sure if this is correct but I don't know how it's handled on
> real hardware. The board does not have ISA and I don't think it has a
> bridge but the IO space appears at this location according to the
> datasheet (In System Memory Address Map it's listed as PCI I/O
> 0xc0800-0xc0800) and clients expect PCI card's io registers to
> be accessible here. If anyone knows how it's done on real hardware and
> if there's a better way to model this please let me know.

Indeed it's the PCI I/O space, maybe it's just copy-paste error.

As for how to declare it, keep in mind this code is years old and I
fixed it several times when compilation broke, without really reading
the documentation (actually, do we have proper documentation for the
internal API?), and it kept changing over the years.

> 
>>> +/* PCI devices */
>>> +pci_create_simple(pci_bus, PCI_DEVFN(6, 0), "sm501");
>>> +/* SoC has a single SATA port but we don't emulate that yet
>>> + * However, firmware and usual clients have driver for SiI311x
>>> + * so add one for convenience by default */
>>> +pci_create_simple(pci_bus, -1, "sii3112");
>>
>> You should probably not create this 

Re: [Qemu-devel] [RFC PATCH 12/12] ppc: Add aCube Sam460ex board

[François Revol]

Le 18/08/2017 à 08:10, David Gibson a écrit :
> On Sun, Aug 13, 2017 at 07:04:38PM +0200, BALATON Zoltan wrote:
>> Add emulation of aCube Sam460ex board based on AMCC 460EX embedded SoC.
>> This is not a full implementation yet with a lot of components still
>> missing but enough to start a Linux kernel and the U-Boot firmware.
>>
>> Signed-off-by: François Revol <re...@free.fr>
>> Signed-off-by: BALATON Zoltan <bala...@eik.bme.hu>
> 
> There are a *lot* of devices defined here.  Most of them look like
> they belong to the SoC, not the board (since they use DCRs), so it
> doesn't really make sense to define them in a board file.  It would
> also make it easier to review if they were split up into separate
> patches.
> 


Indeed, I never thought it would need that many devices to run, and I
intended to move that out but never did.

While it'd make it easier to review, I also recall waiting 3 years to
get a simple patch in just because someone wanted the code to first be
refactored (hint: wacom) :p

François.



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC PATCH 09/12] ppc440: Add emulation of plb-pcix controller found in some 440 SoCs

[François Revol]

Hi,

Le 18/08/2017 à 03:53, David Gibson a écrit :
> On Sun, Aug 13, 2017 at 07:04:38PM +0200, BALATON Zoltan wrote:
> 
> You know I'm going to say it, right: needs a commit message.
> 
> What's a "plb-pcix", and what's an example of a 440 SoCs which has it.

IIRC that's the PCI(express) controller, which is not memory-mapped but
inside the DCR address space, so accessed from the PLB.

See:

http://www.embeddeddeveloper.com/assets/processors/amcc/datasheets/PP460EX_DS2063.pdf

page 9, 13.



François.



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH 09/12] ppc440: Add emulation of plb-pcix controller found in some 440 SoCs

[François Revol]

Hi,

Le 18/08/2017 à 11:30, luigi burdo a écrit :
> hi Balaton, i can help with amigaos4 for sam . i can test it on P5040
> book3e and on G5 quad book3s machine. note sam for boot amigaos need
> a special modified version of uboot that is available on acube
> website it is a firmware update. without modified uboot will be not
> posdible auto boot amigaos. idont know if is possible use standard
> uboot incuded in qemu for boot amigaos from uboot command line. i can
> ask help to Enrico Vidale as my FB friend but i dont know if he will
> be available for this kind of helping.
> 

Yes they use their own custom U-Boot, with a lot of changes and code
duplication, and added x86 emulation to run a VGA BIOS, and never
upstreamed the changes... much like any other vendor, sadly.

I once managed to build a binary from their published source code with
an old compiler, although it's not exactly the same of the binary used,
which I think is actually run with the on-chip RAM or something weird alike.

François.

[Qemu-devel] Retrocomputing devroom at FOSDEM 2018

[François Revol]

Hi,
I just found out someone managed to get a retrocomputing devroom
accepted at FOSDEM:

https://lists.fosdem.org/pipermail/retrocomputing-devroom/2017-October/00.html

https://www.elpauer.org/2017/10/retrocomputing-devroom-call-for-participation/comment-page-1/

Surely there are a lot of subjects in QEMU to talk about in such a
devroom ;-)

François.

[Qemu-devel] Fwd: [retrocomputing devroom] FOSDEM 2019 - Retrocomputing DevRoom CfP

[François Revol]

Hi,

anyone wants to talk about emulating oldies with QEMU?


François.

 Message transféré 
Sujet : [retrocomputing devroom] FOSDEM 2019 - Retrocomputing DevRoom CfP
Date : Sun, 28 Oct 2018 23:12:58 +0100
De : Pau Garcia Quiles 
Pour : FOSDEM visitors 
Copie à : retrocomputing-devr...@lists.fosdem.org

Hello,

FOSDEM 2019 - Retrocomputing DevRoom Call for Participation

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renown for being
highly developer-oriented and brings together 8000+ participants from
all over the world. It is held in the city of Brussels (Belgium).

FOSDEM 2019 will take place during the weekend of February 2nd-3rd
2019. More details about the event can be found at
http://www.fosdem.org.


CALL FOR PARTICIPATION

After last year's success, the Retrocomputing DevRoom will be back in
2019, with talks about use of older computing hardware and software in
modern times.

Presentation topics could include but are not limited to:
   - Emulation of old systems to run videogames, legacy software, etc
   - New software, hardware or related to be used with classic systems
   - Open source software emulation/simulation
   - Open hardware
   - Operating systems/executives for retrocomputers/retrosystems
   - Uses of retrocomputing today
   - Other retrosystems topics
   - Opportunities in retrocomputing

You are not limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We are not afraid of technical
stuff: devrooms are a place for development teams to meet, discuss,
hack and publicly present their project’s latest improvements and
future directions.

If you will have special needs for your talk (e. g. because you will
need to plug some sort of a system), please note that clearly in your
proposal so that we can provide it.

You can use the Wikipedia definition of retrocomputing as a reference
definition to see if you talk qualifies, although it is not exclusive:
https://en.wikipedia.org/wiki/Retrocomputing


IMPORTANT DATES
   -  30 November 2018: submission deadline for talk proposals
   -  16 December 2018: announcement of the final schedule
   -  2 February 2019: Retrocomputing DevRoom


USEFUL INFORMATION

Use the FOSDEM Pentabarf tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM19

- If necessary, create a Pentabarf account and activate it. Please
reuse your account from previous years if you have already created it.
- In the "Person" section, provide First name, Last name (in the
"General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Retrocomputing DevRoom" track (on the
"General" tab). If you do not select a track, then nobody, from any
track, will look at your submission!
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the intended
audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
- Provide an expected length of your talk in the "Duration" field,
including discussion. The default duration is 30 minutes.

Please note neither FOSDEM nor the Retrocomputing DevRoom will
reimburse any expenses you incur


RECORDING OF TALKS


The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people
can watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed.

If you plan to be a speaker, please understand that by doing so you
implicitly give consent for your talk to be recorded and streamed. The
recordings will be published under the same license as all FOSDEM
content (CC-BY).

Hope to hear from you soon! And please forward this announcement.



CONTACT

The Retrocomputing DevRoom is managed by Pau Garcia Quiles
(retrocomputing-devroom-manager at fosdem.org).

A mailing list of speakers, audience and the curious is available,
please subscribe at:
https://lists.fosdem.org/listinfo/retrocomputing-devroom

-- 
Pau Garcia Quiles
http://www.elpauer.org
___
retrocomputing-devroom mailing list
retrocomputing-devr...@lists.fosdem.org
https://lists.fosdem.org/listinfo/retrocomputing-devroom

Fwd: [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom Call for Participation

[François Revol]

Hi,

anyone wants to talk about using QEMU for old platform emulation? (like,
m68k or older…)


François.


 Message transféré 
Sujet : [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom
Call for Participation
Date : Sun, 27 Oct 2019 23:48:33 +0100
De : Pau Garcia Quiles 
Pour : retrocomputing-devr...@lists.fosdem.org

Hello,

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 8000+ participants from
all over the world. It is held in the city of Brussels (Belgium).

FOSDEM 2020 will take place during the weekend of February 1st-2nd
2020. More details about the event can be found at
http://www.fosdem.org.


CALL FOR PARTICIPATION

After success in the past two years, the Retrocomputing DevRoom will
be back in 2020, with talks about usage of older computing hardware
and software in modern times.

Presentation topics could include but are not limited to:
   - Emulation of old systems to run videogames, legacy software, etc
   - New software, hardware or related to be used with classic systems
   - Open source software emulation/simulation
   - Open hardware
   - Operating systems/executives for retrocomputers/retrosystems
   - Uses of retrocomputing today
   - Other retrosystems topics
   - Opportunities in retrocomputing

You are not limited to slide presentations, of course. Be creative.

However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We are not afraid of technical
stuff: devrooms are a place for development teams to meet, discuss,
hack and publicly present their project’s latest  improvements and
future directions.

If you will have special needs for your talk (e. g. because you will
need to plug some sort of a system, you need sound, etc), please note
that clearly in your proposal so that we can provide it.

You can use the Wikipedia definition of retrocomputing as a reference
definition to see if you talk qualifies, although it is not exclusive:
https://en.wikipedia.org/wiki/Retrocomputing


IMPORTANT DATES
   -  30 November 2019: submission deadline for talk proposals
   -  14 December 2019: announcement of the final schedule
   -  1 February 2020: Retrocomputing DevRoom


USEFUL INFORMATION

Use the FOSDEM Pentabarf tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20

- If necessary, create a Pentabarf account and activate it. Please
reuse your account from previous years if you have already created it.
- In the "Person" section, provide First name, Last name (in the
"General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Retrocomputing DevRoom" track (on the
"General" tab). If you do not select a track, then nobody, from any
track, will look at your submission!
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the intended
audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
- Provide an expected length of your talk in the "Duration" field,
including discussion. The default duration is 30 minutes.
- Slides are NOT required at the moment of submission

Please note neither FOSDEM nor the Retrocomputing DevRoom will
reimburse any expenses you incur.


RECORDING OF TALKS

The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people
can watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed.

If you plan to be a speaker, please understand that by doing so you
implicitly give consent for your talk to be recorded and streamed. The
recordings will be published under the same license as all FOSDEM
content (CC-BY).

Hope to hear from you soon! And please forward this announcement.


CONTACT

The Retrocomputing DevRoom is managed by Pau Garcia Quiles and
François Revol (retro-devroom-mana...@fosdem.org).

A mailing list of speakers, audience and the curious is available,
please subscribe at:
https://lists.fosdem.org/listinfo/retrocomputing-devroom


-- 
Pau Garcia Quiles
http://www.elpauer.org
___
retrocomputing-devroom mailing list
retrocomputing-devr...@lists.fosdem.org
https://lists.fosdem.org/listinfo/retrocomputing-devroom