[Qemu-devel] Problems with Modifying TranslationBlock

2007-09-03 Thread [EMAIL PROTECTED]
Hi, everybody,

I have encountered an odd problem. I want to mark the TranslationBlock when 
the code running on guest-os is a 'call' one or a 'ret' one. So I add some 
member variables in TranslationBlock of exec-all.h. Just like the 
following: 


typedef struct TranslationBlock {

target_ulong pc;   /* simulated PC corresponding to this block (EIP + CS 
base) */
..
struct TranslationBlock *jmp_first;
int is_call;// I add this if the translation block is a 
'call' block
int is_ret; // I add this if the translation block is a 'ret' 
block
}

Moreover, I add some codes in Translation.c to mark the current block 'call' 
or 'ret'.

Although the code I add seems work well, the result is not correct. Moreover, 
if I add the member variables before 'pc' in TranslationBlock, qemu does not 
even work. 

So can anyone help me?  Thanks a lot in advance.

Kevin






Re: [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.

2007-09-03 Thread GUERRAZ Francois
Hello,

Can you confirm to me that if I have only one periodic timer on my
motherboard I can only have one qemu-instance running using hpet?

Thanks.

François.

Le mardi 21 août 2007 à 21:40 +0200, Luca a écrit :
 On 8/21/07, Matthew Kent [EMAIL PROTECTED] wrote:
  On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote:
   plain text document attachment (clock-hpet)
   Linux operates the HPET timer in legacy replacement mode, which means that
   the periodic interrupt of the CMOS RTC is not delivered (qemu won't be 
   able
   to use /dev/rtc). Add support for HPET (/dev/hpet) as a replacement for 
   the
   RTC; the periodic interrupt is delivered via SIGIO and is handled in the
   same way as the RTC timer.
  
   Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
 
  I must be missing something silly here.. should I be able to open more
  than one instance of qemu with -clock hpet? Because upon invoking a
  second instance of qemu HPET_IE_ON fails.
 
 It depends on your hardware. Theoretically it's possible, but I've yet
 to see a motherboard with more than one periodic timer.
 
 dmesg | grep hpet should tell you something like:
 
 hpet0: 3 64-bit timers, 14318180 Hz
 
 Luca
 
 
 





Re: [Qemu-devel] Re: Réf. : Re: [kvm-devel] [ PATCH][RFC] Allowing QEMU to directly executead irectory (and storing command line options in it)

2007-09-03 Thread Laurent Vivier
Anthony Liguori wrote:
 On Fri, 2007-08-31 at 22:13 +0200, [EMAIL PROTECTED] wrote:
 Hi Anthony,

 I think passing only the directory name is better because it can be like a
 black box : the user don't have to know how it is inside. And it is much
 more simple to use qemu my_pc than qemu -c my_pc/config.
 
 You're overriding what qemu my_pc means.  qemu my_pc create a QEMU
 vm with 128m of memory and -hda my_pc with the default network card.
 
 qemu -c my_pc/config only has one meaning: read command line arguments
 from my_pc/config.
 
 Your suggested syntax may be simpler for your particular use-case, but
 it makes QEMU much more difficult to understand for every other user.

I don't totally agree with you: qemu my_pc, when my_pc is a file, as you
explain, has an implicit behavior use vm with 128 MB and hda my_pc and the
default network card, so perhaps we can have also qemu my_pc, when my_pc is a
directory, has an implicit behavior use vm as defined in my_pc/config and hd
found in this directory.

BUT, as there is a lot of debates on this, I AGREE WITH YOU: we should choose
the most simple, logic and common solution... and -c seems the good one.

Jorge made a very good work, it should be sad to not use it.

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
  Software is hard - Donald Knuth



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

2007-09-03 Thread Philip Boulain

On 1 Sep 2007, at 21:26, Jorge Lucángeli Obes wrote:

I think the problem here is that the scope of this change is not
clear. I _really_ wish to keep this simple. I _really_ wish to avoid
having giant command lines and useless shell scripts.


Surely the small shell script /is/ the simple solution, as it  
requires zero changes to QEMU itself.


What's the difference between having to hack about a plain-text, few- 
lines configuration file, and a plain-text, few-lines shell script?


LionsPhil
(Ok, the latter is needlessly Turing complete, so tools can't  
understand it, but tools are i) out of scope ii) better served by Q- 
style XML plists anyway.)






Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

2007-09-03 Thread Christian Brunschen


On 3 Sep 2007, at 11:19, Philip Boulain wrote:


On 1 Sep 2007, at 21:26, Jorge Lucángeli Obes wrote:

I think the problem here is that the scope of this change is not
clear. I _really_ wish to keep this simple. I _really_ wish to avoid
having giant command lines and useless shell scripts.


Surely the small shell script /is/ the simple solution, as it  
requires zero changes to QEMU itself.


What's the difference between having to hack about a plain-text,  
few-lines configuration file, and a plain-text, few-lines shell  
script?


The same shells are not (at least by default) available on all  
platforms.


Basically, requiring a shell script means that you have to meta- 
program around qemu itself, whereas a configuration file means you're  
writing something within the context of qemu (and thus don't have to  
venture outside qemu's domain).


In my opinion, it would be nice, from the point of view of a user, to  
have this behaviour:


The command
qemu foo
will behave as follows:
1) if 'foo' is a file:
  a) if 'foo' is a qemu configuration file (begins with a suitable,  
easily recognisable character sequence, read 'foo' as a configuration  
file; all relative path
references within 'foo' will be interpreted relative to the  
current directory
  b) otherwise, use 'foo' as a disk image, presume a simple standard  
PC configuration, and attempt to boot from 'foo' as the disk image  
for ide0/hda

2) if 'foo' is a directory:
  verify that 'foo' is in fact a vm bundle directory, i.e., that it  
contains at the very least a qemu configuration file at a canonical  
name within the directory, i.e, 'qemu.cfg'. If there is no such  
configuration file, then the directory is _not_ a valid vm bundle,  
and qemu compains and exits. If the directory is a valid vm bundle,  
open and use the file 'qemu.cfg' inside the directory. All relative  
path references within 'qemu.cfg' will be interpreted relative to the  
'foo' directory, and no references outside the 'foo' directory will  
be permitted.


The qemu command also offers explicit command line options to specify  
with, say, '-c foo' that 'foo' is a configuration file, '-hda foo'  
that foo should be used as the ide0 hard drive image, and '-vm foo'  
that voo is a virtual machine bundle directory (containing both the  
configuration and any necessary resources - disk images, BIOS images,  
etc).


This gives the *user* of qemu the maximum ease-of-use, to simply  
invoke 'qemu' with a single point of entry, whether this single point  
is a hard drive image, a configuration file or a vm bundle directory.  
It costs very little implementation. It also means that programs like  
'Q' and such, while certainly nice, are not *necessary* to give the  
user a simple initial user experience for the simple use case of  
starting qemu. And it gives us the vm bundle format as an interchange  
format for moving virtual machines between qemu installations,  
including those that use *different* wrapper programs (like 'Q' and  
similar).


Saying that 'Q already handles this' means that any other program  
that wants to offer a similar ease-of-use would have to be able to  
read and interpret Q's configuration file format. If instead there is  
a wrapper-neutral format, then each wrapper can use that. Of course,  
each wrapper may also add its own, wrapper-specific information to  
its own bespoke configuration file within the bundle, but any  
information that is for qemu's use, and that can be shared regardless  
of which wrapper or even *if* a wrapper is used, would and should be  
kept in the qemu configuration file - making it possible and easy to  
share vm bundles with other people, whether or not they have or use  
the same wrapper.



LionsPhil


Best wishes,

// Christian Brunschen





Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

2007-09-03 Thread Philip Boulain
On Mon, 2007-09-03 at 12:01 +0200, Christian Brunschen wrote:
 On 3 Sep 2007, at 11:19, Philip Boulain wrote:
  What's the difference between having to hack about a plain-text,  
  few-lines configuration file, and a plain-text, few-lines shell  
  script?
 The same shells are not (at least by default) available on all  
 platforms.

You only need sh, because all you're doing is an exec, which covers all
POSIX platforms. For Windows, use a shortcut.

 Basically, requiring a shell script means that you have to meta- 
 program around qemu itself, whereas a configuration file means you're  
 writing something within the context of qemu (and thus don't have to  
 venture outside qemu's domain).

Given that the goal is simple, I'd consider this a plus. 95% of
UNIX-like systems is glue.[1]

 2) if 'foo' is a directory:
verify that 'foo' is in fact a vm bundle directory...

If this is going to move from frontends to QEMU itself, given that the Q
devs have already created a QEMU VM bundle format, it makes sense to use
theirs. It's a sensible format, consistent at least with OS X bundle
conventions. (Not sure about GNUStep bundles, but given that their both
NeXT offspring, I doubt there's much difference.)

 Saying that 'Q already handles this' means that any other program  
 that wants to offer a similar ease-of-use would have to be able to  
 read and interpret Q's configuration file format.

I don't see a problem with this.

 If instead there is  
 a wrapper-neutral format, then each wrapper can use that.

This is what Q bundles should be absorbed as. For simple, there are
shell scripts. For complete, there are bundles, and Q's format is a
good one to absorb as the QEMU bundle format. I don't see the point in
a config format which adds nothing but complexity over a shell script.

LionsPhil

1. This figure drawn from entirely unauthoritative sources. ;)






Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

2007-09-03 Thread Andreas Färber


Am 03.09.2007 um 12:01 schrieb Christian Brunschen:

Saying that 'Q already handles this' means that any other program  
that wants to offer a similar ease-of-use would have to be able to  
read and interpret Q's configuration file format. If instead there  
is a wrapper-neutral format, then each wrapper can use that. Of  
course, each wrapper may also add its own, wrapper-specific  
information to its own bespoke configuration file within the  
bundle, but any information that is for qemu's use, and that can be  
shared regardless of which wrapper or even *if* a wrapper is used,  
would and should be kept in the qemu configuration file - making it  
possible and easy to share vm bundles with other people, whether or  
not they have or use the same wrapper.


Just to point this out, I was not saying QEMU must adopt Q's format  
because that already handles a bundle format. Maybe it would be  
feasible to have a qemu-specific command line only file. The point  
is however that such a bundle should be designed in a way that has  
extended uses such as Q's or qemu-launcher's etc. in mind.


Do all frontends actually serialize the whole command line? I noticed  
the port redirection was in both command line and special sections  
for Q but I thought some info wasn't in...


Andreas




Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)

2007-09-03 Thread Andreas Färber


Am 03.09.2007 um 13:40 schrieb Andreas Färber:

Do all frontends actually serialize the whole command line? I  
noticed the port redirection was in both command line and special  
sections for Q but I thought some info wasn't in...


Answering myself here: Obviously the architecture is not part of the  
command line arguments. It would somehow need to be stored in the  
bundle as well.


Leading to this:

1) QEMU could get a -c switch that reads in only command line  
arguments for the current QEMU executable.
It was argued that this could be handled by shell scripts on Unices  
and Windows respectively, whereas a config file would work on both.


2) For really using a bundle with QEMU for multiple architectures  
we'd need a separate script or executable anyway to read in which  
qemu executable to launch.
So this can hardly be handled by QEMU command line arguments alone  
effectively.



So, independent of any config file switches, would there be any  
interest in such a simple command line frontend? I wouldn't  
personally need it but from my view this would come close to the use  
case of the VMware Player (on Windows) - people download the image  
and configuration and just run it.


I do like the idea of specifying a standard, extensible QEMU machine  
bundle format.


A first use case for QEMU itself would be the provided test images on  
qemu.org: If provided in a bundle then instead of downloading an  
archive and either running a custom script or, worse, looking up the  
configuration details in the custom script and needing to re-enter  
them in the frontend, such a bundle could be launched with the  
recommended configuration either through e.g. qemu-run  
TestImage.qvm or by opening the bundle with an appropriate platform- 
specific frontend.


Andreas



Re: [Qemu-devel] [PATCH] Patches from PyQemu project

2007-09-03 Thread Blue Swirl
On 9/2/07, Maria Zabolotnaya [EMAIL PROTECTED] wrote:
 2-qemu-mplugin.patch
 Add -mplugin switch to allow loading of shared library and registering a
 machine declared in it.

Sorry to ruin your GSoC project, but the plugin system was discussed
last year, please see this thread:
http://thread.gmane.org/gmane.comp.emulators.qemu/14341/focus=14473

 4-qemu-no-statics.patch
 Remove static declaration from some QEMU symbols, so they were exported from 
 shared
 library.

I don't think this API is worth supporting in the future.




Re: [Qemu-devel] Nokia N770 and/or N800 emulation

2007-09-03 Thread Dirk Behme

M. Warner Losh wrote:

Is anybody working on N770 and/or N800 emulation for qemu?


Andrzej Zaborowski worked on OMAP310 for Palm Tungsten|E machine 
emulation for qemu:


http://cvs.savannah.gnu.org/viewvc/qemu/hw/?root=qemu

Please note that N770/800 has other OMAP processors than Tungsten. 
N770 has ARM9/DSP based OMAP17xx, while N800 has ARM11/DSP based 
OMAP24xx. I think qemu will never support DSP, and qemu doesn't 
support ARM11 (see qemu mail archives for details). So currently I 
think there are only chances for ARM9 side of N770.


Best regards

Dirk






Re: [Qemu-devel] Nokia N770 and/or N800 emulation

2007-09-03 Thread Paul Brook
On Sunday 02 September 2007, M. Warner Losh wrote:
 Is anybody working on N770 and/or N800 emulation for qemu?

Most of the OMAP (The main SoC used on the N770/N800) documentation is only 
available under NDA, and some components don't even have open source drivers 
(most notably the DSP and wireless chipsets).

This makes creating a useful emulator extremely hard. Don't hold your breath.

Paul




Re: [Qemu-devel] Nokia N770 and/or N800 emulation

2007-09-03 Thread Lauro Ramos Venancio
Hi Warner,

I've just started a project to implement the OMAP processor on QEMU.
This project is part of Mamona (http://dev.openbossa.org/trac/mamona)
and I'm continuing the Andrzej Zaborowski's work. I've already
implemented the OMAP 16xx interrupt handler, GPIO and other minor
things. I'm close to make the OMAP H3 Dev Board ethernet works.

I'm starting by the OMAP H3 implementation, but the main target is to
implement the N770/N800 emulation. There are some legal constraints to
implement the N800 emulation, but we will try to solve them in the
future.

You can download the code using svn co
http://dev.openbossa.org/svn/mamona/qemu-omap/trunk;.
To browse the source, go to
http://dev.openbossa.org/trac/mamona/browser/qemu-omap/trunk

Contributions are welcome.

In few days, I will make a more complete announce.


Lauro Ramos Venancio
OpenBossa Labs
Instituto Nokia de Tecnologia
Recife - Brazil



2007/9/1, M. Warner Losh [EMAIL PROTECTED]:
 Is anybody working on N770 and/or N800 emulation for qemu?

 Warner







Re: [Qemu-devel] [PATCH] Patches from PyQemu project

2007-09-03 Thread Anthony Liguori

On Mon, 2007-09-03 at 18:41 +0300, Blue Swirl wrote:
 On 9/2/07, Maria Zabolotnaya [EMAIL PROTECTED] wrote:
  2-qemu-mplugin.patch
  Add -mplugin switch to allow loading of shared library and registering a
  machine declared in it.
 
 Sorry to ruin your GSoC project, but the plugin system was discussed
 last year, please see this thread:
 http://thread.gmane.org/gmane.comp.emulators.qemu/14341/focus=14473

I've always agreed that allowing plugins was not a good idea.  However,
I had a different thought recently.

While I don't think there's much of a reason to allow plugins for QEMU,
it would be interesting to make some of QEMU's device emulation into
more a of a library that could be used by other programs.

With things like KVM making it relatively simple to do CPU emulation, if
QEMU's device emulation was available as a library (even a GPL library),
it would be pretty easy to do interesting things without forking QEMU
which is what everyone seems to be doing these days.

My initial thought is to make the libraries at the individual device
level.

Regards,

Anthony Liguori

  4-qemu-no-statics.patch
  Remove static declaration from some QEMU symbols, so they were exported 
  from shared
  library.
 
 I don't think this API is worth supporting in the future.