date:20071211


Fabrice Bellard wrote:

Hi,

At this point I am not interested in integrating it into QEMU as it is 
one more API level to maintain in addition to the command line 
monitor. However, I can change my mind if several projects insists to 
have a similar interface.




I think that many projects now want to control qemu programatically.  
The monitor is not a good interface since it is text-based, hard to 
parse, and liable to change without notice when new features are added.  
However, I agree that having many similar constructs is not a good 
thing, and that we should retain the monitor for non-programmatic control.


What do you say to implementing the qemu interface as a plugin API, and 
implementing the monitor on top of this API? e.g.:


qemu loads /usr/local/lib/qemu/libmonitor.so, which uses the API to 
export the good old qemu monitor interface.  If it finds 
/usr/local/lib/qemu/libdbus.so, it loads an additional dbus interface.  
If libvirt wants to drop a libvirtapi.so into that directory, it can 
control qemu through that.


--
error compiling committee.c: too many arguments to function

[Qemu-devel] patch: block-vvfat.c add no-mbr: option

2007-12-11 Thread Tristan Gingold


Hi,

this very simple patch allows to suppress the (virtual) mbr of block- 
vvfat.  Without an mbr, the fat filesystem

starts obviously at block 0.  Some simple OS doesn't support mbr.

Tristan.


qemu.diff
Description: Binary data

[Qemu-devel] patch: ppc_prep.c: use qemu_alloc_ram

2007-12-11 Thread Tristan Gingold


Hi,

this patch updates ppc_prep.c.  It now uses qemu_ram_alloc.
The original purpose of this patch was being able to use a bios  
bigger than 1MB.  And updating ppc_prep.c

was a better way than increasing BIOS_SIZE.

Tristan.


qemu.diff
Description: Binary data

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Avi Kivity wrote:

Fabrice Bellard wrote:

Hi,

At this point I am not interested in integrating it into QEMU as it 
is one more API level to maintain in addition to the command line 
monitor. However, I can change my mind if several projects insists to 
have a similar interface.




I think that many projects now want to control qemu programatically.  
The monitor is not a good interface since it is text-based, hard to 
parse, and liable to change without notice when new features are 
added.  However, I agree that having many similar constructs is not a 
good thing, and that we should retain the monitor for non-programmatic 
control.


What do you say to implementing the qemu interface as a plugin API, 
and implementing the monitor on top of this API? e.g.:


qemu loads /usr/local/lib/qemu/libmonitor.so, which uses the API to 
export the good old qemu monitor interface.  If it finds 
/usr/local/lib/qemu/libdbus.so, it loads an additional dbus 
interface.  If libvirt wants to drop a libvirtapi.so into that 
directory, it can control qemu through that.


Why not just improve the monitor interface?  Half the internet is based 
on human-readable text protocols.


I don't think there would be a lot of objections to adding a status 
field with each monitor command.  It could even be done in a way that 
was backwards compatible.  For instance:


(qemu) info kqemu
kqemu support is not compiled in
(qemu) verbosity status
(qemu) info kqemu
-38: kqemu support is not compiled in

The other two things to add to the monitor are support for multiple 
simultaneous connections and some sort of select command.


Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Dor Laor wrote:

Laurent Vivier wrote:

Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
  

Hi,



Hi,

  
At this point I am not interested in integrating it into QEMU as it is 
one more API level to maintain in addition to the command line monitor. 
However, I can change my mind if several projects insists to have a 
similar interface.



perhaps the DBUS interface can replace the command line monitor ?
We have just to move the command line interface to a client speaking to
qemu through the DBUS interface.

  
This is a valid option but the problem is that local user will have to 
use another tool (client) to
send commands. Another option is to have a common backend with machine 
 user interfaces.
For example, if we use dbus as the backend, monitor commands will just 
be translated into dbus.

The opposite option is also valid.

Anyway, the motivation behind a new interface is that the monitor 
interface is not good enough for automation:
There are not return status for commands, no option for async 
notifications, no option for parallel actions in case

a command takes long time to complete (like snapshot).


All of these are valid, and addressable.  Return statuses can just be 
added to the beginning of the output of each command (similar to how 
POP3 works).  Async notification can be made to work by add support to 
the monitor for a select command.  Semantically, select would block 
the monitor and then output events.   For this to work really well, you 
would have to support multiple simultaneous monitor sessions.  The 
parallel options for long running commands is already address in KVM 
with the migration command.  We just have to rework the snapshotting to 
be properly asynchronous.




So we either a new interface is added or the existing one will be 
enhanced.
Since Qemu/KVM will be used in production its highly important to have 
a reliable channel to connects with mgmt daemons.
Dbus is a common practice for communication and used in Linux, 
libvirt, etc. The question is whether to add a dbus server to Qemu or

a client is sufficient.


The main objection I have to dbus is that it's very heavy weight.  It 
implies a rather fat infrastructure and it not very suitable for 
embedding.  QEMU has very few dependencies and that is a strength ATM.  
People interested in embedding QEMU still want a good management 
interface so enhancing the monitor seems more preferable to me than 
adding a dbus dependency.


Regards,

Anthony Liguori


Regards,
Dor.

I guess Yuval will be very happy to make this work :-D

Regards,
laurent

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Mon, Dec 10, 2007 at 10:28:01AM +0200, Yuval Kashtan wrote:
 Hello All,
 Attached is a proposed patch which adds DBus support to QEMU. DBus is a
 standard message bus for linux (
 http://www.freedesktop.org/wiki/Software/dbus )
 The idea behind this is to allow for external programs such as controlling
 GUI or HyperVisors to communicate and control QEMU, in a standard manner.
 Although it is possible to connect to the monitor, an API is more standard,
 theres no need to parse texts and error messages, no internationalization
 problems and in general is a much better idea.
 
 Implementation:
 This is done by creating a DBus server from QEMU which raise signals and act
 upon methods.
 Methods mainly implement same logic as the current command line options and
 monitor does.
 
 How to use:
 To enable DBus support you'll have to add --enable-dbus when you execure
 configure script.
 Then when you execute QEMU, you'll have to add -dbus-service service_name
 where service_name follows the DBus naming convention ( xxx.xxx.xxx)
 To support QEMU configuration through DBus,  you'll also have to add
 -dbus_configuration which will cause QEMU to wait until ConfigDone is called
 through the DBus interface. this allows external programs time to call DBus
 methods starting with Config_ which changes configuration (just as the CLI
 does) thus enabling invocation of QEMU without parameters (beside the DBus
 ones).
 With that, we have implemented a nice python script that reads VM's
 configuration from INI file.

Frankly this is complete  utter overkill. QEMU needs a configuration file
for machines, but writing a configuration file in an external app and then 
sending that over DBus to QEMU is just insane, when QEMU can simply implement
a config file directly. Spawning QEMU then just becomes 'qemu -config foo.cfg'
instead of a mass of DBus calls. Having QEMU do the config file directly
is also portable to all operating systems and simpler to maintain, and easier
to deploy since it does not mandate a depedancy on a message  bus.


 Currently support was added to all important CLI configuration and some
 online monitor functions (such as connecting and disconnecting usb devices).
 
 configuration methods begins with Config_ prefix and monitor ones with
 Monitor_.
 For a complete list you can just execute qemu and connect with dbus-viewer
 to see what is supported.

The style of the DBus API does not make any sense  does not follow the common
recommended approach for dbus services. 

The idea of well-known bus names is that they are well-known. Passing in the
DBus well-known name as a --service command line arg is non-sensical because
then it ceases to be well-known since it can change at the whim of the app /
admin running QEMU. 

Simply exporting a single object having populating that with a flat set of
methods mapping 1-1 onto the monitor commands is a bad idea. THis has been
done before and is very much unliked  discouraged (eg the Skype dbus control 
API which maps DBus methods straight onto the SKype monitor). The idea with
DBus is to provide a tree of objects mapping to objects managed within the
application, and then provide contextually relevant methods. 

So for a virtual machine management application you might have a main manager
object (eg '/qemu/Manager') which provides a way to list virtual machines. Each
virtual machine might then be its own object (eg '/qemu/Machines/name'). From
a machine one might have methods to list devices, and add  remove devices. Each
device though would be an object '/qemu/Machines/name/Devices/device'. The
device objects would implement different interfaces depending on the type of
device being managed. eg, you might have a qemu.Device.Disk interface, a 
qemu.Device.USB interface, etc, etc, and each interface would have methods
relevant to that type of device.

Which dovetails into the next point - having a DBus API for a single VM is not
really much use. To be generally useful it needs to have a single DBus service
to control all virtual machines (ie QEMU instances). This implies that any DBus
service doesn't belong in the QEMU process itself.

You're now back to square one - the DBus control service needs to spawn QEMU
instances and talk to the QEMU monitor.

IMHO, the entire idea of bolting DBus into QEMU to provide a control API is
just fundamentally flawed.



Looking at what you're trying to address I see two core problems

 - Interacting with QEMU at runtime to change various configs
 - Configuring QEMU at startup

For the first, we currently have the monitor. As you noted this is hard to
interact with programatically since it involves parsing  formating strings.
The way to deal with this problem is to provide a 'libqemumonitor.so' which
exposes a formal C api for the various runtime control needs. Internally
this library would talk to the monitor. This ensures that all the string
parsing  formatting is isolated in a single source, trivially usable by any 
application.

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 01:05:38PM +0200, Avi Kivity wrote:
 Fabrice Bellard wrote:
 Hi,
 
 At this point I am not interested in integrating it into QEMU as it is 
 one more API level to maintain in addition to the command line 
 monitor. However, I can change my mind if several projects insists to 
 have a similar interface.
 
 
 I think that many projects now want to control qemu programatically.  
 The monitor is not a good interface since it is text-based, hard to 
 parse, and liable to change without notice when new features are added.  
 However, I agree that having many similar constructs is not a good 
 thing, and that we should retain the monitor for non-programmatic control.
 
 What do you say to implementing the qemu interface as a plugin API, and 
 implementing the monitor on top of this API? e.g.:
 
 qemu loads /usr/local/lib/qemu/libmonitor.so, which uses the API to 
 export the good old qemu monitor interface.  If it finds 
 /usr/local/lib/qemu/libdbus.so, it loads an additional dbus interface.  
 If libvirt wants to drop a libvirtapi.so into that directory, it can 
 control qemu through that.

To be honest this is overkill. IMHO, there should simply be a client side
'libqemumonitor.so' which provides a formal C API for applications to use.
This C api would then talk to the QEMU monitor, thus isolating all the
string parsing  formatting in one place. Behind the scenes I could imagine
dropping in an alternative QEMU monitor impl which used an XDR serialization
format for the args  reply to avoid the string parsing/formatting, but this
is a minor detail, compared to the big picture, which is that applications
would benefit from a simply C api implementing the monitor commands. I'd
be interested in using such an API in libvirt, since I could remove the 
string parsing/formatting code I currently have. Having libvirt drop a
custom .so into the QEMU process just feels horribly wrong.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
 Dor Laor wrote:
 Laurent Vivier wrote:
 Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
   
 Hi,
 
 
 Hi,
 
   
 At this point I am not interested in integrating it into QEMU as it is 
 one more API level to maintain in addition to the command line monitor. 
 However, I can change my mind if several projects insists to have a 
 similar interface.
 
 
 perhaps the DBUS interface can replace the command line monitor ?
 We have just to move the command line interface to a client speaking to
 qemu through the DBUS interface.
 
   
 This is a valid option but the problem is that local user will have to 
 use another tool (client) to
 send commands. Another option is to have a common backend with machine 
  user interfaces.
 For example, if we use dbus as the backend, monitor commands will just 
 be translated into dbus.
 The opposite option is also valid.
 
 Anyway, the motivation behind a new interface is that the monitor 
 interface is not good enough for automation:
 There are not return status for commands, no option for async 
 notifications, no option for parallel actions in case
 a command takes long time to complete (like snapshot).
 
 All of these are valid, and addressable.  Return statuses can just be 
 added to the beginning of the output of each command (similar to how 
 POP3 works).  Async notification can be made to work by add support to 
 the monitor for a select command.  Semantically, select would block 
 the monitor and then output events.   For this to work really well, you 
 would have to support multiple simultaneous monitor sessions.  The 
 parallel options for long running commands is already address in KVM 
 with the migration command.  We just have to rework the snapshotting to 
 be properly asynchronous.
 
 
 So we either a new interface is added or the existing one will be 
 enhanced.
 Since Qemu/KVM will be used in production its highly important to have 
 a reliable channel to connects with mgmt daemons.
 Dbus is a common practice for communication and used in Linux, 
 libvirt, etc. The question is whether to add a dbus server to Qemu or
 a client is sufficient.
 
 The main objection I have to dbus is that it's very heavy weight.  It 
 implies a rather fat infrastructure and it not very suitable for 
 embedding.  QEMU has very few dependencies and that is a strength ATM.  
 People interested in embedding QEMU still want a good management 
 interface so enhancing the monitor seems more preferable to me than 
 adding a dbus dependency.

It is also not so easily portable to other OS like Windows  Mac OS, who
will still be lacking a decent control API. As I mentioned in my other
thread, embedding a DBus in each individual QEMU process is not the right
way to write DBus services either. If you want DBus (which is questionable
in itself), then you want to have a single service which manages all a QEMU
VMs. This mandates that the DBus service be outside the context of the QEMU
process itself.


Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
 Dor Laor wrote:
 Laurent Vivier wrote:
 Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
   
 Hi,
 
 
 Hi,
 
   
 At this point I am not interested in integrating it into QEMU as it is 
 one more API level to maintain in addition to the command line monitor. 
 However, I can change my mind if several projects insists to have a 
 similar interface.
 
 
 perhaps the DBUS interface can replace the command line monitor ?
 We have just to move the command line interface to a client speaking to
 qemu through the DBUS interface.
 
   
 This is a valid option but the problem is that local user will have to 
 use another tool (client) to
 send commands. Another option is to have a common backend with machine 
  user interfaces.
 For example, if we use dbus as the backend, monitor commands will just 
 be translated into dbus.
 The opposite option is also valid.
 
 Anyway, the motivation behind a new interface is that the monitor 
 interface is not good enough for automation:
 There are not return status for commands, no option for async 
 notifications, no option for parallel actions in case
 a command takes long time to complete (like snapshot).
 
 All of these are valid, and addressable.  Return statuses can just be 
 added to the beginning of the output of each command (similar to how 
 POP3 works).  Async notification can be made to work by add support to 
 the monitor for a select command.  Semantically, select would block 
 the monitor and then output events.   For this to work really well, you 
 would have to support multiple simultaneous monitor sessions.  The 
 parallel options for long running commands is already address in KVM 
 with the migration command.  We just have to rework the snapshotting to 
 be properly asynchronous.

Or have 2 monitor interaction modes. One mode uses the command line style
suitable for people / scripting languages. The other umode ses a binary XDR
protocol for serializing the args  returns values for formal control
APIs to use in a easy manner. It ought to be reasonably straightforward to
add a binary serialization format for all existing commands

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Daniel P. Berrange wrote:

On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
  

Dor Laor wrote:


Laurent Vivier wrote:
  

Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
 


Hi,
   
  

Hi,

 

At this point I am not interested in integrating it into QEMU as it is 
one more API level to maintain in addition to the command line monitor. 
However, I can change my mind if several projects insists to have a 
similar interface.
   
  

perhaps the DBUS interface can replace the command line monitor ?
We have just to move the command line interface to a client speaking to
qemu through the DBUS interface.

 

This is a valid option but the problem is that local user will have to 
use another tool (client) to
send commands. Another option is to have a common backend with machine 
 user interfaces.
For example, if we use dbus as the backend, monitor commands will just 
be translated into dbus.

The opposite option is also valid.

Anyway, the motivation behind a new interface is that the monitor 
interface is not good enough for automation:
There are not return status for commands, no option for async 
notifications, no option for parallel actions in case

a command takes long time to complete (like snapshot).
  
All of these are valid, and addressable.  Return statuses can just be 
added to the beginning of the output of each command (similar to how 
POP3 works).  Async notification can be made to work by add support to 
the monitor for a select command.  Semantically, select would block 
the monitor and then output events.   For this to work really well, you 
would have to support multiple simultaneous monitor sessions.  The 
parallel options for long running commands is already address in KVM 
with the migration command.  We just have to rework the snapshotting to 
be properly asynchronous.



Or have 2 monitor interaction modes. One mode uses the command line style
suitable for people / scripting languages. The other umode ses a binary XDR
protocol for serializing the args  returns values for formal control
APIs to use in a easy manner. It ought to be reasonably straightforward to
add a binary serialization format for all existing commands
  


I don't think binary is inherently easier to parse than text provided 
that some thought is put into the format of the textual output.


I think we just want to levels of verbosity.

Regards,

Anthony Liguori


Dan.

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

2007-12-11 Thread Yuval Kashtan

As I can see,
There is HUGH interest in management API for QEMU.
seemly, DBus is NOT the right solution for direct integration into QEMU as
it is not cross platform enough, pose extra dependency and (probably) not
suitable for embedded systems.

Keeping only the old monitor interface with no formal interface will make
QEMU harder to integrate with as it requires extra work

C API is not a complete solution as it does not define well enough how will
you integrate with QEMU without changing or adding to the source..
But combined with AVI's idea of some plug-in mechanism, which will use this
C API, it sounds like a complete and valid solution.

The monitor should be kept for backward compatibility, human interface and
be implemented on top of that API as well, so there will also be a reference
implementation of how to use the API and create a plug-in.




As of Daniel remarks regarding DBus:
- I actually have a newer version where commands are divided into different
DBus interfaces. So (hopefully) that solves the methods naming problem.
- I had to pass the server name at the CLI, since I was executing multiple
instances of QEMU.. Having an external server, raises again the question of
how will that server communicate with each instance of QEMU?
- It was easier for my project to configure QEMU after it started and not
through a file, that why there is a configuration method for each option. of
course there could also be a bulk method which receive them all or even read
them from a file (and actually with some extra work, many of them could be
made dynamics)

On Dec 11, 2007 5:00 PM, Daniel P. Berrange [EMAIL PROTECTED] wrote:

 On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
  Dor Laor wrote:
  Laurent Vivier wrote:
  Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
  
  Hi,
  
  
  Hi,
  
  
  At this point I am not interested in integrating it into QEMU as it
 is
  one more API level to maintain in addition to the command line
 monitor.
  However, I can change my mind if several projects insists to have a
  similar interface.
  
  
  perhaps the DBUS interface can replace the command line monitor ?
  We have just to move the command line interface to a client speaking
 to
  qemu through the DBUS interface.
  
  
  This is a valid option but the problem is that local user will have to
  use another tool (client) to
  send commands. Another option is to have a common backend with machine
   user interfaces.
  For example, if we use dbus as the backend, monitor commands will just
  be translated into dbus.
  The opposite option is also valid.
  
  Anyway, the motivation behind a new interface is that the monitor
  interface is not good enough for automation:
  There are not return status for commands, no option for async
  notifications, no option for parallel actions in case
  a command takes long time to complete (like snapshot).
 
  All of these are valid, and addressable.  Return statuses can just be
  added to the beginning of the output of each command (similar to how
  POP3 works).  Async notification can be made to work by add support to
  the monitor for a select command.  Semantically, select would block
  the monitor and then output events.   For this to work really well, you
  would have to support multiple simultaneous monitor sessions.  The
  parallel options for long running commands is already address in KVM
  with the migration command.  We just have to rework the snapshotting to
  be properly asynchronous.
 
  
  So we either a new interface is added or the existing one will be
  enhanced.
  Since Qemu/KVM will be used in production its highly important to have
  a reliable channel to connects with mgmt daemons.
  Dbus is a common practice for communication and used in Linux,
  libvirt, etc. The question is whether to add a dbus server to Qemu or
  a client is sufficient.
 
  The main objection I have to dbus is that it's very heavy weight.  It
  implies a rather fat infrastructure and it not very suitable for
  embedding.  QEMU has very few dependencies and that is a strength ATM.
  People interested in embedding QEMU still want a good management
  interface so enhancing the monitor seems more preferable to me than
  adding a dbus dependency.

 It is also not so easily portable to other OS like Windows  Mac OS, who
 will still be lacking a decent control API. As I mentioned in my other
 thread, embedding a DBus in each individual QEMU process is not the right
 way to write DBus services either. If you want DBus (which is questionable
 in itself), then you want to have a single service which manages all a
 QEMU
 VMs. This mandates that the DBus service be outside the context of the
 QEMU
 process itself.


 Dan.
 --
 |=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496
 -=|
 |=-   Perl modules: 
 http://search.cpan.org/~danberr/http://search.cpan.org/%7Edanberr/  
-=|
 |=-   Projects:

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 04:17:51PM +0100, Jean-Christian de Rivaz wrote:
 Anthony Liguori a écrit :
   The main objection I have to dbus is that it's very heavy weight.  It
 implies a rather fat infrastructure and it not very suitable for 
 embedding.  QEMU has very few dependencies and that is a strength ATM.  
 People interested in embedding QEMU still want a good management 
 interface so enhancing the monitor seems more preferable to me than 
 adding a dbus dependency.
 
 I must object again that.
 
 I use D-Bus on a very small processor (Analog Devices Blackfin BF-537) 
 and it work very well. The library is around 200k on the target: this is 
 very supportable for embedded device, especially when you take in 
 account all the simplifications it allow in the code of each 
 applications. The D-Bus library have very few and simple dependency.
 
 D-Bus is a growing standard for the communication between applications. 
 I expect that sooner or later, QEMU will be a D-Bus service.

A DBus service for controlling QEMU, does not imply that QEMU needs to use
DBus. It is perfectly possible to write DBus services for managing QEMU
outside of the QEMU process. I've written 2 myself - the first exposed a
DBus service for managing a collection of VMs, and communicated with QEMU
via its monitor. The second, simply exposed the libvirt API over DBus
which allows managing of QEMU, Xen, KVM, etc via the same interface.

Embedding DBus within QEMU is flawed because it neccessarily restricts you
to only managing a single VM, and does not provide you any management 
capabilities when QEMU is not running.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

2007-12-11 Thread Jean-Christian de Rivaz


Anthony Liguori a écrit :
  The main objection I have to dbus is that it's very heavy weight.  It
implies a rather fat infrastructure and it not very suitable for 
embedding.  QEMU has very few dependencies and that is a strength ATM.  
People interested in embedding QEMU still want a good management 
interface so enhancing the monitor seems more preferable to me than 
adding a dbus dependency.


I must object again that.

I use D-Bus on a very small processor (Analog Devices Blackfin BF-537) 
and it work very well. The library is around 200k on the target: this is 
very supportable for embedded device, especially when you take in 
account all the simplifications it allow in the code of each 
applications. The D-Bus library have very few and simple dependency.


D-Bus is a growing standard for the communication between applications. 
I expect that sooner or later, QEMU will be a D-Bus service.


Best regards,
--
Jean-Christian de Rivaz

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 05:21:08PM +0200, Yuval Kashtan wrote:
 As I can see,
 There is HUGH interest in management API for QEMU.
 seemly, DBus is NOT the right solution for direct integration into QEMU as
 it is not cross platform enough, pose extra dependency and (probably) not
 suitable for embedded systems.
 
 Keeping only the old monitor interface with no formal interface will make
 QEMU harder to integrate with as it requires extra work

The monitor does have an initial barrier to entry, but that can be addressed
by providing a C API which sends  receives monitor commands. This does not
require any intrusive modification of QEMU, at most incremental enhancements
to make the monitor more complete.

 C API is not a complete solution as it does not define well enough how will
 you integrate with QEMU without changing or adding to the source..
 But combined with AVI's idea of some plug-in mechanism, which will use this
 C API, it sounds like a complete and valid solution.

You are now exposing the internals of QEMU as a stable ABI which has to be 
maintained indefinittely to avoid breaking these out-of-tree plugins. THis
does not sound like a winning solution since it'll dramatically restrict 
the scope of future development of QEMU code.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Yuval Kashtan wrote:

As I can see,
There is HUGH interest in management API for QEMU.
seemly, DBus is NOT the right solution for direct integration into 
QEMU as it is not cross platform enough, pose extra dependency and 
(probably) not suitable for embedded systems.


Keeping only the old monitor interface with no formal interface will 
make QEMU harder to integrate with as it requires extra work


Why can't we make the monitor interface a formal interface?

Regards,

Anthony Liguori

C API is not a complete solution as it does not define well enough how 
will you integrate with QEMU without changing or adding to the source..
But combined with AVI's idea of some plug-in mechanism, which will use 
this C API, it sounds like a complete and valid solution.


The monitor should be kept for backward compatibility, human interface 
and be implemented on top of that API as well, so there will also be a 
reference implementation of how to use the API and create a plug-in.





As of Daniel remarks regarding DBus:
- I actually have a newer version where commands are divided into 
different DBus interfaces. So (hopefully) that solves the methods 
naming problem.
- I had to pass the server name at the CLI, since I was executing 
multiple instances of QEMU.. Having an external server, raises again 
the question of how will that server communicate with each instance of 
QEMU?
- It was easier for my project to configure QEMU after it started and 
not through a file, that why there is a configuration method for each 
option. of course there could also be a bulk method which receive them 
all or even read them from a file (and actually with some extra work, 
many of them could be made dynamics)


On Dec 11, 2007 5:00 PM, Daniel P. Berrange [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
 Dor Laor wrote:
 Laurent Vivier wrote:
 Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a
écrit :
 
 Hi,
 
 
 Hi,
 
 
 At this point I am not interested in integrating it into QEMU
as it is
 one more API level to maintain in addition to the command
line monitor.
 However, I can change my mind if several projects insists to
have a
 similar interface.
 
 
 perhaps the DBUS interface can replace the command line monitor ?
 We have just to move the command line interface to a client
speaking to
 qemu through the DBUS interface.
 
 
 This is a valid option but the problem is that local user will
have to
 use another tool (client) to
 send commands. Another option is to have a common backend with
machine
  user interfaces.
 For example, if we use dbus as the backend, monitor commands
will just
 be translated into dbus.
 The opposite option is also valid.
 
 Anyway, the motivation behind a new interface is that the monitor
 interface is not good enough for automation:
 There are not return status for commands, no option for async
 notifications, no option for parallel actions in case
 a command takes long time to complete (like snapshot).

 All of these are valid, and addressable.  Return statuses can
just be
 added to the beginning of the output of each command (similar to how
 POP3 works).  Async notification can be made to work by add
support to
 the monitor for a select command.  Semantically, select would
block
 the monitor and then output events.   For this to work really
well, you
 would have to support multiple simultaneous monitor sessions.  The
 parallel options for long running commands is already address in KVM
 with the migration command.  We just have to rework the
snapshotting to
 be properly asynchronous.

 
 So we either a new interface is added or the existing one will be
 enhanced.
 Since Qemu/KVM will be used in production its highly important
to have
 a reliable channel to connects with mgmt daemons.
 Dbus is a common practice for communication and used in Linux,
 libvirt, etc. The question is whether to add a dbus server to
Qemu or
 a client is sufficient.

 The main objection I have to dbus is that it's very heavy
weight.  It
 implies a rather fat infrastructure and it not very suitable for
 embedding.  QEMU has very few dependencies and that is a
strength ATM.
 People interested in embedding QEMU still want a good management
 interface so enhancing the monitor seems more preferable to me than
 adding a dbus dependency.

It is also not so easily portable to other OS like Windows  Mac
OS, who
will still be lacking a decent control API. As I mentioned in my other
thread, embedding a DBus in each individual QEMU process is not
the right
way to write DBus services either. If you want DBus (which is
questionable

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

2007-12-11 Thread Richard W.M. Jones

Anthony Liguori wrote:

Daniel P. Berrange wrote:

Or have 2 monitor interaction modes. One mode uses the command line style
suitable for people / scripting languages. The other umode ses a
binary XDR

protocol for serializing the args returns values for formal control
APIs to use in a easy manner. It ought to be reasonably
straightforward to

add a binary serialization format for all existing commands

I don't think binary is inherently easier to parse than text provided
that some thought is put into the format of the textual output.

XDR (aka RFC 1014 RFC 4506) does let you generate complex interfaces
with relative ease. For example, here's the description of the remote
protocol used by libvirt:

http://git.et.redhat.com/?p=libvirt.git;a=blob;f=qemud/remote_protocol.x;h=d409c74387c2642651896136aba9bc1e2b62b621;hb=HEAD

Parsing is done for you by stubs that are generated from the above file.

On the downside it turns out that it's not very well supported under
Windows. For libvirt I had to basically port an XDR implementation by
hand to MinGW and add extra functions from glibc to it.

I think we just want to levels of verbosity.

This would work too.

On the point of controlling multiple qemu instances on a machine from a
single place: Easiest way to do this would be to direct all the monitor
sockets into a single known directory. Something along the lines of:

qemu -monitor unix:/var/lib/qemu-monitors/`uuidgen`,nowait

A control process can then just keep an eye on entries under that
directory, and (unlike libvirtd) it's robust against the control process
restarting.

Rich.

--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 09:16:43AM +0200, Yuval Kashtan wrote:
 - This is very useful when you want to manage and control QEMU, for instance
 developing a GUI to attach and detach usb devices or controlling more than
 one instance of QEMU from a single management point, receiving parameters
 externally and more.

This capability is already possible using the monitor API. I've implemented
it in libvirt, and in virt-manager and can easily hotplug/remove USB devices.
So DBus is not required to do this and does not really make it any easier
to use. DBus is very verbose to use from languages like C, so switching from
the monitor to DBus API would not really help simplify my existing code. On
the other hand, having a library providing a simple client side C API to 
send  receive monitor commands, would be beneficial

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

Richard W.M. Jones wrote:

Anthony Liguori wrote:

Daniel P. Berrange wrote:
Or have 2 monitor interaction modes. One mode uses the command line
style
suitable for people / scripting languages. The other umode ses a
binary XDR

protocol for serializing the args returns values for formal control
APIs to use in a easy manner. It ought to be reasonably
straightforward to

add a binary serialization format for all existing commands

I don't think binary is inherently easier to parse than text provided
that some thought is put into the format of the textual output.

XDR (aka RFC 1014 RFC 4506) does let you generate complex interfaces
with relative ease. For example, here's the description of the remote
protocol used by libvirt:

http://git.et.redhat.com/?p=libvirt.git;a=blob;f=qemud/remote_protocol.x;h=d409c74387c2642651896136aba9bc1e2b62b621;hb=HEAD

Parsing is done for you by stubs that are generated from the above
file.

On the downside it turns out that it's not very well supported under
Windows. For libvirt I had to basically port an XDR implementation by
hand to MinGW and add extra functions from glibc to it.

I think we just want to levels of verbosity.

This would work too.

On the point of controlling multiple qemu instances on a machine from
a single place: Easiest way to do this would be to direct all the
monitor sockets into a single known directory. Something along the
lines of:

qemu -monitor unix:/var/lib/qemu-monitors/`uuidgen`,nowait

A control process can then just keep an eye on entries under that
directory, and (unlike libvirtd) it's robust against the control
process restarting.

Actually, this was the original intention of the -name parameter. What
a management tool would want to do is:

1) if -name is specified by user, generate one with uuidgen
2) pass -name name and -pidfile /path/to/well/known/location/name.pid

This will ensure uniqueness of name without requiring the creation tool
to maintain any state (so no daemon is required). Right now, you would
also have to store a monitor socket in that well known path. However,
I'm working on a VNC tunnels patch right now that would allow the
monitor to be tunneled through a VNC session. The idea here is that a
management tool could just store a hint about the VNC location and then
you can get at the rest of the character devices through the VNC session.

Otherwise, you end up with a bunch of temporary sockets for things like
the monitor, serial devices, parallel devices, etc.

Regards,

Anthony Liguori

Rich.

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Daniel P. Berrange wrote:


I think that many projects now want to control qemu programatically.  
The monitor is not a good interface since it is text-based, hard to 
parse, and liable to change without notice when new features are added.  
However, I agree that having many similar constructs is not a good 
thing, and that we should retain the monitor for non-programmatic control.


What do you say to implementing the qemu interface as a plugin API, and 
implementing the monitor on top of this API? e.g.:


qemu loads /usr/local/lib/qemu/libmonitor.so, which uses the API to 
export the good old qemu monitor interface.  If it finds 
/usr/local/lib/qemu/libdbus.so, it loads an additional dbus interface.  
If libvirt wants to drop a libvirtapi.so into that directory, it can 
control qemu through that.



To be honest this is overkill. IMHO, there should simply be a client side
'libqemumonitor.so' which provides a formal C API for applications to use.
  


libqemumonitor.so is an excellent idea. perhaps the libvirt code can be 
used as a base?


We should also provide bindings to the saner languages that management 
apps are typically written in.


--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote:
 Richard W.M. Jones wrote:
 
 Actually, this was the original intention of the -name parameter.  What 
 a management tool would want to do is:
 
 1) if -name is specified by user, generate one with uuidgen
 2) pass -name name and -pidfile /path/to/well/known/location/name.pid
 
 This will ensure uniqueness of name without requiring the creation tool 
 to maintain any state (so no daemon is required).  Right now, you would 
 also have to store a monitor socket in that well known path.  However, 
 I'm working on a VNC tunnels patch right now that would allow the 
 monitor to be tunneled through a VNC session.  The idea here is that a 
 management tool could just store a hint about the VNC location and then 
 you can get at the rest of the character devices through the VNC session.
 
 Otherwise, you end up with a bunch of temporary sockets for things like 
 the monitor, serial devices, parallel devices, etc.

Tunnelling things like the serial devices / parallel devices over VNC
would be very useful, as using a pty/file isn't useful for remote
management. Tunnelling the monitor over VNC is questionable though because
it has very significant security implications - if you can connect to the
VNC server, you essentially own the entire user account that the VM is
running under since the monitor can be used to map arbitrary files into
the guest VM. Now this may be useful in some cases, but for libvirt we
really just want the monitor accessible locally via a well-known UNIX
socket. Also, VNC ports are typically auto-allocated at startup so not
neccessary a good predictable access method.

The reason libvirt use the PTY  direct PID ownership was because we stared
off with QEMU 0.8.0. We should really just mandate use of QEMU 0.9.0 with
libvirt now since its been around quite a while. Then we could just run
with  -daemonize, -pidfile and -monitor unix:/well/known/path.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

2007-12-11 Thread Dor Laor

Anthony Liguori wrote:

Richard W.M. Jones wrote:
Anthony Liguori wrote:
Daniel P. Berrange wrote:
Or have 2 monitor interaction modes. One mode uses the command line
style
suitable for people / scripting languages. The other umode ses a
binary XDR
protocol for serializing the args returns values for formal control
APIs to use in a easy manner. It ought to be reasonably
straightforward to
add a binary serialization format for all existing commands

I don't think binary is inherently easier to parse than text provided
that some thought is put into the format of the textual output.

XDR (aka RFC 1014 RFC 4506) does let you generate complex interfaces
with relative ease. For example, here's the description of the remote
protocol used by libvirt:

http://git.et.redhat.com/?p=libvirt.git;a=blob;f=qemud/remote_protocol.x;h=d409c74387c2642651896136aba9bc1e2b62b621;hb=HEAD

Parsing is done for you by stubs that are generated from the above
file.

On the downside it turns out that it's not very well supported under
Windows. For libvirt I had to basically port an XDR implementation by
hand to MinGW and add extra functions from glibc to it.

I think we just want to levels of verbosity.

This would work too.

On the point of controlling multiple qemu instances on a machine from
a single place: Easiest way to do this would be to direct all the
monitor sockets into a single known directory. Something along the
lines of:

qemu -monitor unix:/var/lib/qemu-monitors/`uuidgen`,nowait

A control process can then just keep an eye on entries under that
directory, and (unlike libvirtd) it's robust against the control
process restarting.

Actually, this was the original intention of the -name parameter. What
a management tool would want to do is:

1) if -name is specified by user, generate one with uuidgen
2) pass -name name and -pidfile /path/to/well/known/location/name.pid

While this is good for home usage, it does not match product needs because
you don't always want to allow the user of the VM to control it. For
example,
the user might hack memory values from the monitor and comprise his
permission

within the guest.

Otherwise, you end up with a bunch of temporary sockets for things like
the monitor, serial devices, parallel devices, etc.

Actually this is what we do in Qumranet to run multiple VMs.
We just need to improve/replace the monitor. Maybe enhancing the current
implementation
as you suggested might be good enough, although library interface might
be cleaner (no ugly return code

for the user).
Thanks,
Dor.

Regards,

Anthony Liguori

Rich.

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Anthony Liguori wrote:

Yuval Kashtan wrote:

As I can see,
There is HUGH interest in management API for QEMU.
seemly, DBus is NOT the right solution for direct integration into 
QEMU as it is not cross platform enough, pose extra dependency and 
(probably) not suitable for embedded systems.


Keeping only the old monitor interface with no formal interface 
will make QEMU harder to integrate with as it requires extra work


Why can't we make the monitor interface a formal interface?



Because then fixing a type or extending the interface becomes a pain.

It's also much more difficult to specify a text-base interface 
completey, compared to a C api (where sometimes all you need is the 
header and a few comments).



--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

2007-12-11 Thread Richard W.M. Jones


Avi Kivity wrote:
libqemumonitor.so is an excellent idea. perhaps the libvirt code can be 
used as a base?


We should also provide bindings to the saner languages that management 
apps are typically written in.


Libvirt has most of the major languages covered now.  The only language 
I'm aware of that we are missing (and people request) is PHP.


Rich.

--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

2007-12-11 Thread Fabrice Bellard


Daniel P. Berrange wrote:

On Tue, Dec 11, 2007 at 09:16:43AM +0200, Yuval Kashtan wrote:

- This is very useful when you want to manage and control QEMU, for instance
developing a GUI to attach and detach usb devices or controlling more than
one instance of QEMU from a single management point, receiving parameters
externally and more.


This capability is already possible using the monitor API. I've implemented
it in libvirt, and in virt-manager and can easily hotplug/remove USB devices.
So DBus is not required to do this and does not really make it any easier
to use. DBus is very verbose to use from languages like C, so switching from
the monitor to DBus API would not really help simplify my existing code. On
the other hand, having a library providing a simple client side C API to 
send  receive monitor commands, would be beneficial


For the short term I think it is better as you said to rely on libvirt 
which already has some support for QEMU.


As it was suggested, improving the monitor seems the easiest, maybe with 
an additionnal mode to provide a standardized way to get a return value 
for each command. Providing an example client code to directly use the 
monitor seems a good idea too.


Regarding the configuration, I can assure there will be soon a QEMU 
configuration file. The question is whether it will be included before 
the next release is out !


Regards,

Fabrice.

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Paul Brook wrote:

Why can't we make the monitor interface a formal interface?
  

Because then fixing a type or extending the interface becomes a pain.

It's also much more difficult to specify a text-base interface
completey, compared to a C api (where sometimes all you need is the
header and a few comments).



I disagree.

It's entirely possible to fully specify a text protocol, 


Of course it's possible; it has been done many times.  I've printed out 
several pounds of http myself.  It isn't easy, especially starting from 
something intended for human consumption.


and it's just as easy 
to extend it in a backwards compatible way. 


It's hard to correct a typo in a backwards compatible way.  I think it's 
best to separate the human readable protocol from the machine readable 
protocol.


A C API is about the most fixed 
interface you could possible use. 


But it's easy to add things without breaking it.

A C API also requires that both sides of 
the interface be part of the same process on the same machine. 


My plan was for the library to connect to the managing process using a 
protocol of its choice.  But I'm withdrawing it in favor of Dan 
Berrange's idea of having a client library.


If you prefer a dedicated machine readable protocol, then I think that's 
workable too.  But it has to be decoupled from the human readable 
monitor protocol.


--
error compiling committee.c: too many arguments to function

[Qemu-devel] [BUG][PATCH] execve processesing NULL args

Here's a patch to avoid processing NULL args in execve.  It prevents
trying to dereference NULL.

Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c	2007-11-19 20:45:20.0 -0700
+++ qemu/linux-user/syscall.c	2007-11-19 20:48:54.0 -0700
@@ -3515,7 +3515,7 @@
 
 argc = 0;
 guest_argp = arg2;
-for (gp = guest_argp; ; gp += sizeof(abi_ulong)) {
+for (gp = guest_argp; gp; gp += sizeof(abi_ulong)) {
 if (get_user_ual(addr, gp))
 goto efault;
 if (!addr)
@@ -3524,7 +3524,7 @@
 }
 envc = 0;
 guest_envp = arg3;
-for (gp = guest_envp; ; gp += sizeof(abi_ulong)) {
+for (gp = guest_envp; gp; gp += sizeof(abi_ulong)) {
 if (get_user_ual(addr, gp))
 goto efault;
 if (!addr)
@@ -3535,7 +3535,7 @@
 argp = alloca((argc + 1) * sizeof(void *));
 envp = alloca((envc + 1) * sizeof(void *));
 
-for (gp = guest_argp, q = argp; ;
+for (gp = guest_argp, q = argp; gp;
   gp += sizeof(abi_ulong), q++) {
 if (get_user_ual(addr, gp))
 goto execve_efault;
@@ -3546,7 +3546,7 @@
 }
 *q = NULL;
 
-for (gp = guest_envp, q = envp; ;
+for (gp = guest_envp, q = envp; gp;
   gp += sizeof(abi_ulong), q++) {
 if (get_user_ual(addr, gp))
 goto execve_efault;
@@ -3568,14 +3568,14 @@
 ret = -TARGET_EFAULT;
 
 execve_end:
-for (gp = guest_argp, q = argp; *q;
+for (gp = guest_argp, q = argp; gp  *q;
   gp += sizeof(abi_ulong), q++) {
 if (get_user_ual(addr, gp)
 || !addr)
 break;
 unlock_user(*q, addr, 0);
 }
-for (gp = guest_envp, q = envp; *q;
+for (gp = guest_envp, q = envp; gp  *q;
   gp += sizeof(abi_ulong), q++) {
 if (get_user_ual(addr, gp)
 || !addr)

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API


Daniel P. Berrange wrote:

On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote:
  

Richard W.M. Jones wrote:

Actually, this was the original intention of the -name parameter.  What 
a management tool would want to do is:


1) if -name is specified by user, generate one with uuidgen
2) pass -name name and -pidfile /path/to/well/known/location/name.pid

This will ensure uniqueness of name without requiring the creation tool 
to maintain any state (so no daemon is required).  Right now, you would 
also have to store a monitor socket in that well known path.  However, 
I'm working on a VNC tunnels patch right now that would allow the 
monitor to be tunneled through a VNC session.  The idea here is that a 
management tool could just store a hint about the VNC location and then 
you can get at the rest of the character devices through the VNC session.


Otherwise, you end up with a bunch of temporary sockets for things like 
the monitor, serial devices, parallel devices, etc.



Tunnelling things like the serial devices / parallel devices over VNC
would be very useful, as using a pty/file isn't useful for remote
management. Tunnelling the monitor over VNC is questionable though because
it has very significant security implications - if you can connect to the
VNC server, you essentially own the entire user account that the VM is
running under since the monitor can be used to map arbitrary files into
the guest VM. Now this may be useful in some cases, but for libvirt we
really just want the monitor accessible locally via a well-known UNIX
socket. Also, VNC ports are typically auto-allocated at startup so not
neccessary a good predictable access method.
  


The monitor is already tunneled through VNC ala a 'vc'.  The tunnels 
extension I'm developing would just expose 'vc's as plain-text instead 
of rendered.  If your management tools policy is to not make the monitor 
exposed over a 'vc', then it wouldn't be exposed via VNC tunneling either.



The reason libvirt use the PTY  direct PID ownership was because we stared
off with QEMU 0.8.0. We should really just mandate use of QEMU 0.9.0 with
libvirt now since its been around quite a while. Then we could just run
with  -daemonize, -pidfile and -monitor unix:/well/known/path.
  


Yeah, it would be very nice to eliminate the extra daemon.

Regards,

Anthony Liguori


Dan.

Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

On Tue, Dec 11, 2007 at 10:49:05AM -0600, Anthony Liguori wrote:
 Daniel P. Berrange wrote:
 On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote:
   
 Richard W.M. Jones wrote:
 
 Actually, this was the original intention of the -name parameter.  What 
 a management tool would want to do is:
 
 1) if -name is specified by user, generate one with uuidgen
 2) pass -name name and -pidfile /path/to/well/known/location/name.pid
 
 This will ensure uniqueness of name without requiring the creation tool 
 to maintain any state (so no daemon is required).  Right now, you would 
 also have to store a monitor socket in that well known path.  However, 
 I'm working on a VNC tunnels patch right now that would allow the 
 monitor to be tunneled through a VNC session.  The idea here is that a 
 management tool could just store a hint about the VNC location and then 
 you can get at the rest of the character devices through the VNC session.
 
 Otherwise, you end up with a bunch of temporary sockets for things like 
 the monitor, serial devices, parallel devices, etc.
 
 
 Tunnelling things like the serial devices / parallel devices over VNC
 would be very useful, as using a pty/file isn't useful for remote
 management. Tunnelling the monitor over VNC is questionable though because
 it has very significant security implications - if you can connect to the
 VNC server, you essentially own the entire user account that the VM is
 running under since the monitor can be used to map arbitrary files into
 the guest VM. Now this may be useful in some cases, but for libvirt we
 really just want the monitor accessible locally via a well-known UNIX
 socket. Also, VNC ports are typically auto-allocated at startup so not
 neccessary a good predictable access method.
   
 
 The monitor is already tunneled through VNC ala a 'vc'.  The tunnels 
 extension I'm developing would just expose 'vc's as plain-text instead 
 of rendered.  If your management tools policy is to not make the monitor 
 exposed over a 'vc', then it wouldn't be exposed via VNC tunneling either.

Ah, ok that makes alot more sense now. We already disable 'vc' for the
monitor so that wouldn't be an issue.

 The reason libvirt use the PTY  direct PID ownership was because we stared
 off with QEMU 0.8.0. We should really just mandate use of QEMU 0.9.0 with
 libvirt now since its been around quite a while. Then we could just run
 with  -daemonize, -pidfile and -monitor unix:/well/known/path.
 
 Yeah, it would be very nice to eliminate the extra daemon.

Of course libvirt daemon provides other things besides just managing the
QEMU process, but yes fixing the hard parent-child relationship between
the two would be good.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Qemu-devel] [PATCH] linux-user, Add missing break just before execve.

2007-12-11 Thread Takashi Yoshii

Small patch around execve again.
Now unlinkat() goes through into execve. Here is the fix.
/yoshii

diff -u -p -r1.157 syscall.c
--- a/linux-user/syscall.c  9 Dec 2007 23:12:55 -   1.157
+++ b/linux-user/syscall.c  11 Dec 2007 17:02:11 -
@@ -3177,6 +3176,7 @@ abi_long do_syscall(void *cpu_env, int n
 goto efault;
 ret = get_errno(sys_unlinkat(arg1, p, arg3));
 unlock_user(p, arg2, 0);
+break;
 #endif
 case TARGET_NR_execve:
 {

[Qemu-devel] [PATCH] SH4, Add more float instructions.

2007-12-11 Thread Takashi Yoshii

Hi,
I found some instructions missing on SH4, and added some.
Graphics extentions(like sin/cos/sqrt/vector op) are still missing,
 but I believe no one need them, at least, so far.

fneg is implemented as 32bit op, according to the programming manual.
/yoshii

diff -u -p -r1.10 op.c
--- a/target-sh4/op.c   2 Dec 2007 06:18:24 -   1.10
+++ b/target-sh4/op.c   11 Dec 2007 17:24:31 -
@@ -797,6 +797,36 @@ void OPPROTO op_ftrc_DT(void)
 RETURN();
 }
 
+void OPPROTO op_fneg_frN(void)
+{
+env-fregs[PARAM1] = float32_chs(env-fregs[PARAM1]);
+RETURN();
+}
+
+void OPPROTO op_fabs_FT(void)
+{
+FT0 = float32_abs(FT0);
+RETURN();
+}
+
+void OPPROTO op_fabs_DT(void)
+{
+DT0 = float64_abs(DT0);
+RETURN();
+}
+
+void OPPROTO op_fcnvsd_DT(void)
+{
+DT0 = float32_to_float64(env-fpul, env-fp_status);
+RETURN();
+}
+
+void OPPROTO op_fcnvds_DT(void)
+{
+env-fpul = float64_to_float32(DT0, env-fp_status);
+RETURN();
+}
+
 void OPPROTO op_fmov_T0_frN(void)
 {
 *(unsigned int *)env-fregs[PARAM1] = T0;
diff -u -p -r1.21 translate.c
--- a/target-sh4/translate.c2 Dec 2007 06:10:04 -   1.21
+++ b/target-sh4/translate.c11 Dec 2007 17:24:31 -
@@ -1123,6 +1123,23 @@ void _decode_opc(DisasContext * ctx)
gen_op_ftrc_FT();
}
return;
+case 0xf04d: /* fneg FRn/DRn - FPSCR: Nothing */
+   gen_op_fneg_frN(FREG(B11_8));
+   return;
+case 0xf05d: /* fabs FRn/DRn */
+   if (ctx-fpscr  FPSCR_PR) {
+   if (ctx-opcode  0x0100)
+   break; /* illegal instruction */
+   gen_op_fmov_drN_DT0(DREG(B11_8));
+   gen_op_fabs_DT();
+   gen_op_fmov_DT0_drN(DREG(B11_8));
+   }
+   else {
+   gen_op_fmov_frN_FT0(FREG(B11_8));
+   gen_op_fabs_FT();
+   gen_op_fmov_FT0_frN(FREG(B11_8));
+   }
+   return;
 case 0xf08d: /* fldi0 FRn - FPSCR: R[PR] */
if (!(ctx-fpscr  FPSCR_PR)) {
gen_op_movl_imm_T0(0);
@@ -1137,6 +1154,14 @@ void _decode_opc(DisasContext * ctx)
return;
}
break;
+case 0xf0ad: /* cnvsd FPUL,DRn */
+   gen_op_fcnvsd_DT();
+   gen_op_fmov_DT0_drN(DREG(B11_8));
+   return;
+case 0xf0bd: /* cnvds DRn,FPUL */
+   gen_op_fmov_drN_DT0(DREG(B11_8));
+   gen_op_fcnvds_DT();
+   return;
 }
 
 fprintf(stderr, unknown instruction 0x%04x at pc 0x%08x\n,

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

2007-12-11 Thread Blue Swirl

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1  07/12/11 19:33:21

Modified files:
pc-bios: README openbios-sparc32 openbios-sparc64 

Log message:
Update OpenBIOS images to SVN revision 181. Changes:
r177:
Reset fixes:
 * recalculate CRC to avoid error message and halt after reset
 * fix bug that crashed SS10/SMP when reset
r178: Remove unused variable
r179: Improved Module ID generation
r180: Add support for eccmemctl
r181: Add support for SPARCstation 20 machine type

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemur1=1.18r2=1.19
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemurev=1.13
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemurev=1.6

[Qemu-devel] qemu cpu-exec.c exec-all.h exec.c translate-all.c

2007-12-11 Thread Blue Swirl

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1  07/12/11 19:35:45

Modified files:
.  : cpu-exec.c exec-all.h exec.c translate-all.c 

Log message:
 Fix code generation buffer overflow reported by TeLeMan

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.128r2=1.129
http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemur1=1.72r2=1.73
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.117r2=1.118
http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.23r2=1.24

[Qemu-devel] qemu Makefile.target cpu-exec.c target-sparc/op.c

2007-12-11 Thread Blue Swirl

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1  07/12/11 19:39:25

Modified files:
.  : Makefile.target cpu-exec.c 
target-sparc   : op.c 

Log message:
 Partial fix to Sparc32 Linux host global register mangling problem

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.231r2=1.232
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.129r2=1.130
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.45r2=1.46

[Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present

2007-12-11 Thread Ryan Harper

3 files changed, 38 insertions(+), 2 deletions(-)
Makefile.target |5 -
configure   |   26 ++
smbios.c|9 -


# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1197402122 21600
# Node ID 115f40a4994be1d5b44ef193b3ccbe8e26410eef
# Parent  e81bef5fa072360d12b87b3237b7d3f72c9b9784
Optionally link against libuuid if present.

This patch makes libuuid optional.  If not detected, SMBIOS tables will use
canned UUID.

Signed-off-by: Ryan Harper [EMAIL PROTECTED]

diff -r e81bef5fa072 -r 115f40a4994b Makefile.target
--- a/Makefile.target   Tue Dec 11 13:42:01 2007 -0600
+++ b/Makefile.target   Tue Dec 11 13:42:02 2007 -0600
@@ -402,6 +402,9 @@ VL_OBJS+=block-raw.o
 
 ifdef CONFIG_ALSA
 LIBS += -lasound
+endif
+ifdef CONFIG_UUID
+LIBS += -luuid
 endif
 ifdef CONFIG_DSOUND
 LIBS += -lole32 -ldxguid
@@ -535,7 +538,7 @@ ifndef CONFIG_DARWIN
 ifndef CONFIG_DARWIN
 ifndef CONFIG_WIN32
 ifndef CONFIG_SOLARIS
-VL_LIBS+=-lutil -luuid
+VL_LIBS+=-lutil
 endif
 endif
 endif
diff -r e81bef5fa072 -r 115f40a4994b configure
--- a/configure Tue Dec 11 13:42:01 2007 -0600
+++ b/configure Tue Dec 11 13:42:02 2007 -0600
@@ -89,6 +89,7 @@ dsound=no
 dsound=no
 coreaudio=no
 alsa=no
+uuid=yes
 fmod=no
 fmod_lib=
 fmod_inc=
@@ -260,6 +261,8 @@ for opt do
   ;;
   --enable-alsa) alsa=yes
   ;;
+  --enable-uuid) uuid=yes
+  ;;
   --enable-dsound) dsound=yes
   ;;
   --enable-fmod) fmod=yes
@@ -404,6 +407,7 @@ echo   --enable-adlib   enable 
 echo   --enable-adlib   enable Adlib emulation
 echo   --enable-coreaudio   enable Coreaudio audio driver
 echo   --enable-alsaenable ALSA audio driver
+echo   --enable-uuidenable UUID generation for machines
 echo   --enable-fmodenable FMOD audio driver
 echo   --enable-dsound  enable DirectSound audio driver
 echo   --disable-vnc-tlsdisable TLS encryption for VNC server
@@ -662,6 +666,23 @@ EOF
   fi
 fi
 
+##
+# uuid library
+if test $uuid = yes ; then
+  cat  $TMPC  EOF
+#include uuid/uuid.h
+int main(void) { uuid_t u; return 0; }
+EOF
+  if $cc -o $TMPE $TMPC -luuid 2 /dev/null ; then
+:
+  else
+echo
+echo Error: Could not find uuid
+echo Make sure to have the uuid libs and headers installed.
+echo
+exit 1
+  fi
+fi
 # Check if tools are available to build documentation.
 if [ -x `which texi2html 2/dev/null` ]  \
[ -x `which pod2man 2/dev/null` ]; then
@@ -716,6 +737,7 @@ echo Adlib support $adlib
 echo Adlib support $adlib
 echo CoreAudio support $coreaudio
 echo ALSA support  $alsa
+echo UUID support  $uuid
 echo DSound support$dsound
 if test $fmod = yes; then
 if test -z $fmod_lib || test -z $fmod_inc; then
@@ -901,6 +923,10 @@ if test $alsa = yes ; then
   echo CONFIG_ALSA=yes  $config_mak
   echo #define CONFIG_ALSA 1  $config_h
 fi
+if test $uuid = yes ; then
+  echo CONFIG_UUID=yes  $config_mak
+  echo #define CONFIG_UUID 1  $config_h
+fi
 if test $dsound = yes ; then
   echo CONFIG_DSOUND=yes  $config_mak
   echo #define CONFIG_DSOUND 1  $config_h
diff -r e81bef5fa072 -r 115f40a4994b smbios.c
--- a/smbios.c  Tue Dec 11 13:42:01 2007 -0600
+++ b/smbios.c  Tue Dec 11 13:42:02 2007 -0600
@@ -25,11 +25,14 @@
 #include stdio.h
 #include stdint.h
 #include string.h
-#include uuid/uuid.h
 #include hw/hw.h
 #include sysemu.h
 #include smbios_types.h
 #include config-host.h
+
+#ifdef CONFIG_UUID
+#include uuid/uuid.h
+#endif
 
 /* Write a two-character hex representation of 'byte' to digits[].
Pre-condition: sizeof(digits) = 2 */
@@ -489,9 +492,13 @@ load_smbios_tables(uint8_t *entry, uint8
 int len;
 uint32_t major_version = 0;
 uint32_t minor_version = 9;
+#ifdef CONFIG_UUID
 uuid_t uuid;
 
 uuid_generate(uuid);
+#else
+uint8_t uuid[16] = QEMUQEMUQEMUQEMU;
+#endif
 
 len = write_smbios_tables(entry, table, phys_table_start,
   smp_cpus, (ram_size  20),

[Qemu-devel] [PATCH 0 of 3] Add SMBIOS/DMI table generation to PC machine

2007-12-11 Thread Ryan Harper

This patchset introduces SMBIOS/DMI table generation to qemu for PC machines.
The intial patch includes all changes needed to create the tables and load
them into memory.  This patch depends on libuuid.  The subsequent patches
detect for libuuid and optionally link to the library if present.  The final
patch adds a -uuid option for a user to specify their own uuid.

These patches should apply against qemu-cvs.  Tested on target x86_64-softmmu.

Updates:

- moved smbios.o into i386 target section
- removed open segment in hw/pc.c and moved variable declaration
- removed some uneeded externs from smbios.c
- added uuid_parse implementation allowing -uuid to be available with or 
without  linking against libuuid.
- reduced the number of CONFIG_UUID defines

Signed-off-by: Ryan Harper [EMAIL PROTECTED]

7 files changed, 848 insertions(+), 11 deletions(-)
Makefile.target |9 
configure   |   26 ++
hw/pc.c |   45 
smbios.c|  584 ++-
smbios_types.h  |  182 +
sysemu.h|5 
vl.c|8

[Qemu-devel] [PATCH 1 of 3] export SMBIOS/DMI tables to PC machines

2007-12-11 Thread Ryan Harper

5 files changed, 749 insertions(+), 3 deletions(-)
Makefile.target |4 
hw/pc.c |   45 
smbios.c|  517 +++
smbios_types.h  |  182 +++
sysemu.h|4 


# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1197402121 21600
# Node ID e81bef5fa072360d12b87b3237b7d3f72c9b9784
# Parent  25082b761acbe8b7fa535dedb4a53e02ef74128d
export SMBIOS/DMI tables to PC machines.

This patch introduces code to generate PC SMBIOS/DMI tables and load them
into machine memory.  The resultant machine can use standard tools like
dmidecode to examine the in-memory generated table.

Moved smbios.o to TARGET_BASE_ARCH=i386 section of Makefile.target
Removed inner scoping for smbios table call in hw/pc.c

Signed-off-by: Ryan Harper [EMAIL PROTECTED]

diff -r 25082b761acb -r e81bef5fa072 Makefile.target
--- a/Makefile.target   Wed Dec 05 03:23:38 2007 +
+++ b/Makefile.target   Tue Dec 11 13:42:01 2007 -0600
@@ -440,7 +440,7 @@ VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SO
 VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
 VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
 VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
+VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o smbios.o
 CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
 endif
 ifeq ($(TARGET_BASE_ARCH), ppc)
@@ -535,7 +535,7 @@ ifndef CONFIG_DARWIN
 ifndef CONFIG_DARWIN
 ifndef CONFIG_WIN32
 ifndef CONFIG_SOLARIS
-VL_LIBS+=-lutil
+VL_LIBS+=-lutil -luuid
 endif
 endif
 endif
diff -r 25082b761acb -r e81bef5fa072 hw/pc.c
--- a/hw/pc.c   Wed Dec 05 03:23:38 2007 +
+++ b/hw/pc.c   Tue Dec 11 13:42:01 2007 -0600
@@ -44,6 +44,13 @@
 
 #define MAX_IDE_BUS 2
 
+/* Hole in BIOS space between 0xF and 0xFFF0 for DMI entry point */
+#define SMBIOS_ENTRY 0x000fac00
+
+/* ensure SMBIOS tables have enough room to support MAX_CPUS number of
+ * processor entries */
+#define SMBIOS_EXTRA (5  12)
+
 static fdctrl_t *floppy_controller;
 static RTCState *rtc_state;
 static PITState *pit;
@@ -706,7 +713,9 @@ static void pc_init1(int ram_size, int v
 char buf[1024];
 int ret, linux_boot, i;
 ram_addr_t ram_addr, vga_ram_addr, bios_offset, vga_bios_offset;
-int bios_size, isa_bios_size, vga_bios_size;
+ram_addr_t smbios_offset, entrypoint_offset, smbios_base;
+uint32_t smbios_phys;
+int bios_size, isa_bios_size, vga_bios_size, smbios_size;
 PCIBus *pci_bus;
 int piix3_devfn = -1;
 CPUState *env;
@@ -832,6 +841,40 @@ static void pc_init1(int ram_size, int v
 }
 }
 
+/* phys_ram_base + bios_offset implies 0xe in guest ram */
+smbios_base = (ram_addr_t)phys_ram_base + bios_offset;
+
+/* take a guess at smbios size */
+smbios_size = (SMBIOS_EXTRA-1)  ~4095;
+
+/* we only have 32k of space between rombios32 and rombios16 */
+if (smbios_size  SMBIOS_MAXIMUM_SIZE) {
+  fprintf(stderr, qemu: SMBIOS image size too big (%u), max %u\n,
+  smbios_size, SMBIOS_MAXIMUM_SIZE);
+  exit(1);
+}
+
+/* smbios is composed of two regions, an entry point table and
+* a second table of all of the data.  These regions will live
+* at different phyiscal addresses so we need to reserve space
+* for two locations
+* NB: Entry point is a fixed size (0x1f)
+*/
+
+/* use the hole between end of rombios32 and start of 
+ * rombios16 @ 0xf */
+smbios_phys = 0xf - smbios_size;
+smbios_offset = (ram_addr_t)(smbios_phys - 0xe);
+entrypoint_offset = (ram_addr_t)(SMBIOS_ENTRY - 0xe);
+
+ret = load_smbios_tables((uint8_t *)smbios_base + entrypoint_offset,
+ (uint8_t *)smbios_base + smbios_offset,
+ smbios_phys);
+if (ret  0) {
+   fprintf(stderr, qemu: could not generate SMBIOS\n);
+   exit(1);
+}
+
 /* map all the bios at the top of memory */
 cpu_register_physical_memory((uint32_t)(-bios_size),
  bios_size, bios_offset | IO_MEM_ROM);
diff -r 25082b761acb -r e81bef5fa072 smbios.c
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/smbios.c  Tue Dec 11 13:42:01 2007 -0600
@@ -0,0 +1,517 @@
+/*
+ * smbios.c - Generate SMBIOS tables for Xen HVM domU's.
+ *  - Adapted for QEMU/KVM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU

[Qemu-devel] qemu qemu-doc.texi

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/11 21:56:43

Modified files:
.  : qemu-doc.texi 

Log message:
Update documention with '-drive' usage (Laurent Vivier).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.168r2=1.169

[Qemu-devel] qemu/hw ide.c

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/11 22:15:29

Modified files:
hw : ide.c 

Log message:
IDE should send irq after WIN_DIAGNOSE (Tristan Gingold).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemur1=1.73r2=1.74

[Qemu-devel] qemu vnc.c

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/11 22:31:32

Modified files:
.  : vnc.c 

Log message:
Fix fragments due to incomplete dirty tracking in CGA mode (Anthony 
Liguori).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.29r2=1.30

Re: [Qemu-devel] [PATCH] Capture network traffic to a tcpdump file - updated

2007-12-11 Thread Paul Brook

On Tuesday 11 December 2007, andrzej zaborowski wrote:
 On 10/12/2007, Balazs Attila-Mihaly (Cd-MaN) [EMAIL PROTECTED] wrote:
  Here goes v0.2 for my patch :-)
  Changes
  - now the option is a separate command line switch:
-net capture,vlan=2,file=test.pcap
  - it is also available from the monitor
  - added some more constants / defines to avoid repeating portions of the
  code

 Would it be possible to implement this as simply another vlan client
 that does the logging in it's fd_read callback?  I think this would be
 cleaner, we would avoid the special case and an additional condition
 check in every qemu_send_packet().

That's exactly what I was imagining when I suggested making it a -net option.

Paul

[Qemu-devel] qemu vl.c linux-user/syscall.c

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/11 23:23:52

Modified files:
.  : vl.c 
linux-user : syscall.c 

Log message:
Add missing break just before execve, by Takashi Yoshii.
Fix a comment typo.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.378r2=1.379
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.157r2=1.158

[Qemu-devel] [PATCH] print default cpu_model

The linux-user qemu help usage doesn't output the default cpu_model in
the usage.  This patch is a minimal code change to output the default
cpu_model.
Index: qemu/linux-user/main.c
===
--- qemu.orig/linux-user/main.c	2007-12-11 16:14:01.0 -0700
+++ qemu/linux-user/main.c	2007-12-11 16:54:32.0 -0700
@@ -1890,6 +1890,43 @@
 }
 #endif /* TARGET_ALPHA */
 
+static const char *get_cpu_model_default()
+{
+const char *cpu_model = any;
+
+#if defined(TARGET_I386)
+#ifdef TARGET_X86_64
+cpu_model = qemu64;
+#else
+cpu_model = qemu32;
+#endif
+#elif defined(TARGET_ARM)
+cpu_model = arm926;
+#elif defined(TARGET_M68K)
+cpu_model = any;
+#elif defined(TARGET_SPARC)
+#ifdef TARGET_SPARC64
+cpu_model = TI UltraSparc II;
+#else
+cpu_model = Fujitsu MB86904;
+#endif
+#elif defined(TARGET_MIPS)
+#if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
+cpu_model = 20Kc;
+#else
+cpu_model = 24Kf;
+#endif
+#elif defined(TARGET_PPC)
+#ifdef TARGET_PPC64
+cpu_model = 970;
+#else
+cpu_model = 750;
+#endif
+#endif
+
+return cpu_model;
+}
+
 void usage(void)
 {
 printf(qemu- TARGET_ARCH  version  QEMU_VERSION , Copyright (c) 2003-2007 Fabrice Bellard\n
@@ -1900,7 +1937,7 @@
-g port   wait gdb connection to port\n
-L path   set the elf interpreter prefix (default=%s)\n
-s size   set the stack size in bytes (default=%ld)\n
-   -cpu modelselect CPU (-cpu ? for list)\n
+   -cpu modelselect CPU (default=\%s\; -cpu ? for list)\n
-drop-ld-preload  drop LD_PRELOAD for target process\n
\n
debug options:\n
@@ -1910,6 +1947,7 @@
TARGET_ARCH,
interp_prefix,
x86_stack_size,
+   get_cpu_model_default(),
DEBUG_LOGFILE);
 _exit(1);
 }
@@ -2023,38 +2061,9 @@
 init_paths(interp_prefix);
 
 if (cpu_model == NULL) {
-#if defined(TARGET_I386)
-#ifdef TARGET_X86_64
-cpu_model = qemu64;
-#else
-cpu_model = qemu32;
-#endif
-#elif defined(TARGET_ARM)
-cpu_model = arm926;
-#elif defined(TARGET_M68K)
-cpu_model = any;
-#elif defined(TARGET_SPARC)
-#ifdef TARGET_SPARC64
-cpu_model = TI UltraSparc II;
-#else
-cpu_model = Fujitsu MB86904;
-#endif
-#elif defined(TARGET_MIPS)
-#if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
-cpu_model = 20Kc;
-#else
-cpu_model = 24Kf;
-#endif
-#elif defined(TARGET_PPC)
-#ifdef TARGET_PPC64
-cpu_model = 970;
-#else
-cpu_model = 750;
-#endif
-#else
-cpu_model = any;
-#endif
+cpu_model = get_cpu_model_default();
 }
+
 /* NOTE: we need to init the CPU at this stage to get
qemu_host_page_size */
 env = cpu_init(cpu_model);

[Qemu-devel] qemu hw/sh_serial.c linux-user/syscall.c

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/12 00:40:25

Modified files:
hw : sh_serial.c 
linux-user : syscall.c 

Log message:
sh_serial: enable tx after reset (Magnus Damm).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh_serial.c?cvsroot=qemur1=1.3r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.158r2=1.159

[Qemu-devel] [PATCH] arm eabi TLS

I believe Paul Brook did the original patch for arm eabi TLS.  The patch
has bounced around for a bit but hasn't been applied.  We've been using
this patch for a while and have tweaked it to be a bit more correct as
far as code organization.

Please let me know what else should be improved for this so that it can
be applied.

Thanks.
Index: qemu/configure
===
--- qemu.orig/configure	2007-12-11 10:16:49.0 -0700
+++ qemu/configure	2007-12-11 10:16:50.0 -0700
@@ -105,6 +105,7 @@
 darwin_user=no
 build_docs=no
 uname_release=
+nptl=yes
 
 # OS specific
 targetos=`uname -s`
@@ -318,6 +319,8 @@
   ;;
   *) echo ERROR: unknown option $opt; show_help=yes
   ;;
+  --disable-nptl) nptl=no
+  ;;
   esac
 done
 
@@ -413,6 +416,7 @@
 echo   --disable-linux-user disable all linux usermode emulation targets
 echo   --enable-darwin-user enable all darwin usermode emulation targets
 echo   --disable-darwin-userdisable all darwin usermode emulation targets
+echo   --disable-nptl   disable usermode NPTL guest support
 echo   --fmod-lib   path to FMOD library
 echo   --fmod-inc   path to FMOD includes
 echo   --enable-uname-release=R Return R for uname -r in usermode emulation
@@ -579,6 +583,23 @@
 }
 EOF
 
+# check NPTL support
+cat  $TMPC EOF
+#include sched.h
+void foo()
+{
+#ifndef CLONE_SETTLS
+#error bork
+#endif
+}
+EOF
+
+if $cc -c -o $TMPO $TMPC 2 /dev/null ; then
+  :
+else
+   nptl=no
+fi
+
 ##
 # SDL probe
 
@@ -743,6 +764,7 @@
 echo Documentation $build_docs
 [ ! -z $uname_release ]  \
 echo uname -r  $uname_release
+echo NPTL support  $nptl
 
 if test $sdl_too_old = yes; then
 echo - Your SDL version is too old - please upgrade to have SDL support
@@ -948,6 +970,7 @@
 echo SDL_CFLAGS=`$sdl_config --cflags`  $config_mak
   fi
 fi
+
 if test $cocoa = yes ; then
 echo #define CONFIG_COCOA 1  $config_h
 echo CONFIG_COCOA=yes  $config_mak
@@ -1183,6 +1206,15 @@
   echo #define TARGET_HAS_ELFLOAD32 1  $config_h
 fi
 
+if test $nptl = yes ; then
+case $target_cpu in
+  arm | armeb | ppc | ppc64)
+echo USE_NPTL=yes  $config_mak
+echo #define USE_NPTL 1  $config_h
+  ;;
+esac
+fi
+
 test -f ${config_h}~  cmp -s $config_h ${config_h}~  mv ${config_h}~ $config_h
 
 done # for target in $targets
Index: qemu/exec-all.h
===
--- qemu.orig/exec-all.h	2007-12-11 10:16:49.0 -0700
+++ qemu/exec-all.h	2007-12-11 10:16:50.0 -0700
@@ -340,170 +340,7 @@
 extern CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
 extern void *io_mem_opaque[IO_MEM_NB_ENTRIES];
 
-#if defined(__powerpc__)
-static inline int testandset (int *p)
-{
-int ret;
-__asm__ __volatile__ (
-  0:lwarx %0,0,%1\n
-xor. %0,%3,%0\n
-bne 1f\n
-stwcx. %2,0,%1\n
-bne- 0b\n
-  1:
-  : =r (ret)
-  : r (p), r (1), r (0)
-  : cr0, memory);
-return ret;
-}
-#elif defined(__i386__)
-static inline int testandset (int *p)
-{
-long int readval = 0;
-
-__asm__ __volatile__ (lock; cmpxchgl %2, %0
-  : +m (*p), +a (readval)
-  : r (1)
-  : cc);
-return readval;
-}
-#elif defined(__x86_64__)
-static inline int testandset (int *p)
-{
-long int readval = 0;
-
-__asm__ __volatile__ (lock; cmpxchgl %2, %0
-  : +m (*p), +a (readval)
-  : r (1)
-  : cc);
-return readval;
-}
-#elif defined(__s390__)
-static inline int testandset (int *p)
-{
-int ret;
-
-__asm__ __volatile__ (0: cs%0,%1,0(%2)\n
-			 jl0b
-			  : =d (ret)
-			  : r (1), a (p), 0 (*p)
-			  : cc, memory );
-return ret;
-}
-#elif defined(__alpha__)
-static inline int testandset (int *p)
-{
-int ret;
-unsigned long one;
-
-__asm__ __volatile__ (0:	mov 1,%2\n
-			  	ldl_l %0,%1\n
-			  	stl_c %2,%1\n
-			  	beq %2,1f\n
-			  .subsection 2\n
-			  1:	br 0b\n
-			  .previous
-			  : =r (ret), =m (*p), =r (one)
-			  : m (*p));
-return ret;
-}
-#elif defined(__sparc__)
-static inline int testandset (int *p)
-{
-	int ret;
-
-	__asm__ __volatile__(ldstub	[%1], %0
-			 : =r (ret)
-			 : r (p)
-			 : memory);
-
-	return (ret ? 1 : 0);
-}
-#elif defined(__arm__)
-static inline int testandset (int *spinlock)
-{
-register unsigned int ret;
-__asm__ __volatile__(swp %0, %1, [%2]
- : =r(ret)
- : 0(1), r(spinlock));
-
-return ret;
-}
-#elif defined(__mc68000)
-static inline int testandset (int *p)
-{
-

[Qemu-devel] [PATCH] futimesat()

This futimesat() patch for linux-user was never applied.
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c	2007-11-20 21:02:40.0 -0700
+++ qemu/linux-user/syscall.c	2007-11-20 21:03:59.0 -0700
@@ -154,6 +154,7 @@
 #define __NR_sys_faccessat __NR_faccessat
 #define __NR_sys_fchmodat __NR_fchmodat
 #define __NR_sys_fchownat __NR_fchownat
+#define __NR_sys_futimesat __NR_futimesat
 #define __NR_sys_getcwd1 __NR_getcwd
 #define __NR_sys_getdents __NR_getdents
 #define __NR_sys_getdents64 __NR_getdents64
@@ -197,6 +198,10 @@
 _syscall5(int,sys_fchownat,int,dirfd,const char *,pathname,
   uid_t,owner,gid_t,group,int,flags)
 #endif
+#if defined(TARGET_NR_futimesat)  defined(__NR_futimesat)
+_syscall3(int,sys_futimesat,int,dirfd,const char *,pathname,
+  const struct timeval *,times)
+#endif
 _syscall2(int,sys_getcwd1,char *,buf,size_t,size)
 _syscall3(int, sys_getdents, uint, fd, struct dirent *, dirp, uint, count);
 #if defined(TARGET_NR_getdents64)  defined(__NR_getdents64)
@@ -5747,6 +5752,25 @@
 	break;
 #endif
 
+#if defined(TARGET_NR_futimesat)  defined(__NR_futimesat)
+case TARGET_NR_futimesat:
+{
+struct timeval tv[2];
+if (copy_from_user_timeval(tv, arg3)
+|| copy_from_user_timeval(tv+1, arg3+sizeof(struct target_timeval))) {
+goto efault;
+}
+if (!arg2)
+ret = get_errno(sys_futimesat(arg1, NULL, tv));
+else {
+p = lock_user_string(arg2);
+ret = get_errno(sys_futimesat(arg1, path(p), tv));
+unlock_user(p, arg2, 0);
+}
+}
+break;
+#endif
+
 #ifdef TARGET_NR_set_robust_list
 case TARGET_NR_set_robust_list:
 	goto unimplemented_nowarn;

Re: [Qemu-devel] high resolution timer question

2007-12-11 Thread Robert Reif


Blue Swirl wrote:


On 12/10/07, Robert Reif [EMAIL PROTECTED] wrote:
 


Writing data to a serial port on the sparc emulation happens immediately.
I would like to throttle the write speed to match the actual baud rate.
What's the best way to do this in qemu?  Will QEMUTimer work for a
1 millisecond timer?
   



Do you mean that you want the serial port to match the host speed so
that for example, at 9600 baud, target would only receive 9600 bits
per second? Or do you mean that the emulated CPU should see bits
arriving at the same rate that the real CPU would see compared to CPU
execution speed?

On the positive side, this would fix a bug with serial interrupts
arriving too fast which can trigger Linux panics. But this would also
complicate the design because currently the devices do not need to
emulate any internal buffers.

 


The problem I'm having is with sparc32 using a sun openboot image in
nographics mode where the prom uses serial port A as the system console.
The serial port output shows up in the host terminal window that qemu
was started in.

Characters written to serial port A are not reliably making it to the 
screen.

Turning on serial debugging shows that the characters are written to the
serial port.  The characters do make it to the screen when debugging.

If characters are not queued, then that might explain the loss but it looks
like the characters are going to a write(fd, ...) so is stdio loosing 
the characters?


I thought slowing down the rate to realistic speeds might help but that 
doesn't

seem to be where the problem really is.

[Qemu-devel] qemu/hw sh.h sh7750.c sh_timer.c

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/12 01:11:43

Modified files:
hw : sh.h sh7750.c sh_timer.c 

Log message:
Adds interrupt support to the sh specific timer code (Magnus Damm).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh.h?cvsroot=qemur1=1.1r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh7750.c?cvsroot=qemur1=1.12r2=1.13
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh_timer.c?cvsroot=qemur1=1.3r2=1.4

[Qemu-devel] qemu cpu-all.h exec.c linux-user/mmap.c

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/12/12 01:16:24

Modified files:
.  : cpu-all.h exec.c 
linux-user : mmap.c 

Log message:
Mark host pages as reserved (Magnus Damm).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.79r2=1.80
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.118r2=1.119
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mmap.c?cvsroot=qemur1=1.19r2=1.20

Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device

2007-12-11 Thread Rusty Russell

On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
 If QEMU ever got true SMP support, then virtio would not work as it
 requires 16-bit atomic writes which AFAIK is not possible on a number of
 non-x86 architectures.

Hmm?  Where is this requirement coming from?

I think everyone should stop using the word atomic in virtio discussions; 
it's confusing.

Rusty.

Re: [Qemu-devel] [PATCH] arm eabi TLS

2007-12-11 Thread Paul Brook

On Wednesday 12 December 2007, Thayne Harbaugh wrote:
 I believe Paul Brook did the original patch for arm eabi TLS.  The patch
 has bounced around for a bit but hasn't been applied.  We've been using
 this patch for a while and have tweaked it to be a bit more correct as
 far as code organization.

 Please let me know what else should be improved for this so that it can
 be applied.

Implementing clone(CLONE_VM) is a bad idea. We should only do that after we've 
fixed everything else that breaks with multiple threads

You're also missing some of the ARM kernel helper routines.

Paul

Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device


Rusty Russell wrote:

On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
  

If QEMU ever got true SMP support, then virtio would not work as it
requires 16-bit atomic writes which AFAIK is not possible on a number of
non-x86 architectures.



Hmm?  Where is this requirement coming from?

I think everyone should stop using the word atomic in virtio discussions; 
it's confusing.
  


The virtio ring queue indices are 16-bit and are readable to one end 
while writable on the other end.  To ensure that this can be done in a 
lock-less way, it's necessary to atomically update the index.  Atomic is 
the right word here because if the 16-bit write gets converted into two 
8-bit writes, then very bad things could happen with SMP.


Regards,

Anthony Liguori


Rusty.

[Qemu-devel] [Patch 1/2][PXA27x] initial keypad support

2007-12-11 Thread Armin


Hello,

Please consider this for inclusion
Here is an attempt to add PXA27x keypad support. It currently only 
supports the matrix type interface. It still needs direct and 
mulitswitch support added.


Just wanted to get something out there for folks to pound on.

Comment and feedback welcome.

-Armin
Index: qemu/hw/pxa.h
===
--- qemu.orig/hw/pxa.h
+++ qemu/hw/pxa.h
@@ -13,6 +13,7 @@
 # define PXA2XX_PIC_SSP3	0
 # define PXA2XX_PIC_USBH2	2
 # define PXA2XX_PIC_USBH1	3
+# define PXA2XX_PIC_KEYPAD	4
 # define PXA2XX_PIC_PWRI2C	6
 # define PXA25X_PIC_HWUART	7
 # define PXA27X_PIC_OST_4_11	7
@@ -61,6 +62,52 @@
 # define PXA2XX_INTERNAL_BASE	0x5c00
 # define PXA2XX_INTERNAL_SIZE	0x4
 
+/* Keypad defines */
+#define KPC_AS  (0x1  30)  /* Automatic Scan bit */
+#define KPC_ASACT   (0x1  29)  /* Automatic Scan on Activity */
+#define KPC_MI  (0x1  22)  /* Matrix interrupt bit */
+#define KPC_IMKP(0x1  21)  /* Ignore Multiple Key Press */
+#define KPC_MS7 (0x1  20)  /* Matrix scan line 7 */
+#define KPC_MS6 (0x1  19)  /* Matrix scan line 6 */
+#define KPC_MS5 (0x1  18)  /* Matrix scan line 5 */
+#define KPC_MS4 (0x1  17)  /* Matrix scan line 4 */
+#define KPC_MS3 (0x1  16)  /* Matrix scan line 3 */
+#define KPC_MS2 (0x1  15)  /* Matrix scan line 2 */
+#define KPC_MS1 (0x1  14)  /* Matrix scan line 1 */
+#define KPC_MS0 (0x1  13)  /* Matrix scan line 0 */
+#define KPC_ME  (0x1  12)  /* Matrix Keypad Enable */
+#define KPC_MIE (0x1  11)  /* Matrix Interrupt Enable */
+#define KPC_DK_DEB_SEL  (0x1   9)  /* Direct Keypad Debounce Select */
+#define KPC_DI  (0x1   5)  /* Direct key interrupt bit */
+#define KPC_RE_ZERO_DEB (0x1   4)  /* Rotary Encoder Zero Debounce */
+#define KPC_REE1(0x1   3)  /* Rotary Encoder1 Enable */
+#define KPC_REE0(0x1   2)  /* Rotary Encoder0 Enable */
+#define KPC_DE  (0x1   1)  /* Direct Keypad Enable */
+#define KPC_DIE (0x1   0)  /* Direct Keypad interrupt Enable */
+
+#define KPDK_DKP(0x1  31)
+#define KPDK_DK7(0x1   7)
+#define KPDK_DK6(0x1   6)
+#define KPDK_DK5(0x1   5)
+#define KPDK_DK4(0x1   4)
+#define KPDK_DK3(0x1   3)
+#define KPDK_DK2(0x1   2)
+#define KPDK_DK1(0x1   1)
+#define KPDK_DK0(0x1   0)
+
+#define KPREC_OF1   (0x1  31)
+#define kPREC_UF1   (0x1  30)
+#define KPREC_OF0   (0x1  15)
+#define KPREC_UF0   (0x1  14)
+
+#define KPMK_MKP(0x1  31)
+#define KPAS_SO (0x1  31)
+#define KPASMKPx_SO (0x1  31)
+
+
+#define KPASMKPx_MKC(row, col)  (1  (row + 16 * (col % 2)))
+
+
 /* pxa2xx_pic.c */
 qemu_irq *pxa2xx_pic_init(target_phys_addr_t base, CPUState *env);
 
@@ -120,6 +167,13 @@ i2c_bus *pxa2xx_i2c_bus(struct pxa2xx_i2
 struct pxa2xx_i2s_s;
 struct pxa2xx_fir_s;
 
+/* pxa2xx_kpad.c */
+struct pxa2xx_keypad_s;
+struct pxa2xx_keypad_s *pxa27x_keypad_init(target_phys_addr_t base,
+qemu_irq irq);
+void pxa27_register_keyboard(struct pxa2xx_keypad_s *kp, int **keymap, int
+size);
+
 struct pxa2xx_state_s {
 CPUState *env;
 qemu_irq *pic;
@@ -133,6 +187,7 @@ struct pxa2xx_state_s {
 struct pxa2xx_pcmcia_s *pcmcia[2];
 struct pxa2xx_i2s_s *i2s;
 struct pxa2xx_fir_s *fir;
+struct pxa2xx_keypad_s *kp;
 
 /* Power management */
 target_phys_addr_t pm_base;
@@ -200,6 +255,25 @@ struct pxa2xx_i2s_s {
 uint32_t fifo[16];
 };
 
+#define PXAKBD_MAXROW   8
+#define PXAKBD_MAXCOL   8
+
+struct pxa2xx_keypad_s{
+target_phys_addr_t base;
+qemu_irq irq;
+	int keymap[PXAKBD_MAXCOL][PXAKBD_MAXROW];
+uint32_tkpc;
+uint32_tkpdk;
+uint32_tkprec;
+uint32_tkpmk;
+uint32_tkpas;
+uint32_tkpasmkp0;
+uint32_tkpasmkp1;
+uint32_tkpasmkp2;
+uint32_tkpasmkp3;
+uint32_tkpkdi;
+};
+
 # define PA_FMT			0x%08lx
 # define REG_FMT		0x TARGET_FMT_plx
 
Index: qemu/hw/pxa2xx.c
===
--- qemu.orig/hw/pxa2xx.c
+++ qemu/hw/pxa2xx.c
@@ -2156,6 +2156,7 @@ struct pxa2xx_state_s *pxa270_init(unsig
 /* GPIO1 resets the processor */
 /* The handler can be overridden by board-specific code */
 pxa2xx_gpio_out_set(s-gpio, 1, s-reset);
+	s-kp = pxa27x_keypad_init(0x4150, s-pic[PXA2XX_PIC_KEYPAD]);
 return s;
 }
 
Index: qemu/hw/pxa2xx_keypad.c
===
--- /dev/null
+++ qemu/hw/pxa2xx_keypad.c
@@ -0,0 +1,257 @@
+/*
+ * Intel PXA27X Keypad Controller emulation.
+ *
+ * Copyright (c) 2007
+ * Written by Armin Kuster [EMAIL PROTECTED] or
+ *			  			[EMAIL PROTECTED]
+ *
+ * This code is licensed under the GPLv2.
+ */
+
+#include hw.h
+#include pxa.h
+#include console.h
+
+/*
+ * Keypad
+ */
+#define KPC 0x00/* Keypad

[Qemu-devel] [Patch 2/2][PXA27x] Mainstone keypad support

2007-12-11 Thread Armin

This is the mainstone II keypad support for alpha numeric keypad. 
excludes the multiswitch and rotatory switch support

Needs [Patch 1/2][PXA27x] initial keypad support patch in order to work

- Armin
Index: qemu/hw/mainstone.c
===
--- qemu.orig/hw/mainstone.c
+++ qemu/hw/mainstone.c
@@ -78,6 +78,7 @@ static void mainstone_common_init(int ra
 }
 
 mst_irq = mst_irq_init(cpu, MST_FPGA_PHYS, PXA2XX_PIC_GPIO_0);
+ 	mst_keyboard_register(cpu-kp);
 
 /* MMC/SD host */
 pxa2xx_mmci_handlers(cpu-mmc, NULL, mst_irq[MMC_IRQ]);
Index: qemu/hw/mst_kpad.c
===
--- /dev/null
+++ qemu/hw/mst_kpad.c
@@ -0,0 +1,30 @@
+/*
+ * PXA270-based Intel Mainstone Keypad support.
+ *
+ * Copyright (c) 2007 by Armin Kuster [EMAIL PROTECTED] or
+ *[EMAIL PROTECTED]
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+
+#include hw.h
+#include pxa.h
+
+/* main keypad layout */
+int mst_keymap[PXAKBD_MAXROW][PXAKBD_MAXCOL] = {
+	{ 0x1e, 0x30, 0x2e, 0x20, 0x12, 0x21, -1, -1},
+	{ 0x22, 0x23, 0x17, 0x24, 0x25, 0x26, -1, -1},
+	{ 0x32, 0x31, 0x18, 0x19, 0x10, 0x13, -1, -1},
+	{ 0x1f, 0x14, 0x16, 0x2f, 0x11, 0x2d, -1, -1},
+	{   -1,   -1, 0x15, 0x2c,   -1,   -1, -1, -1},
+	{ 0xc7, 0x2a, 0x39, 0x39,   -1, 0x1c, -1, -1},
+	{ 0xc8, 0xd0, 0xcb, 0xcd,   -1,   -1, -1, -1},
+	{   -1,   -1,   -1,   -1,   -1,   -1, -1, -1}
+};
+
+void mst_keyboard_register(struct pxa2xx_keypad_s *kp)
+{
+	pxa27_register_keyboard(kp, mst_keymap, sizeof(mst_keymap));
+
+}
Index: qemu/hw/mainstone.h
===
--- qemu.orig/hw/mainstone.h
+++ qemu/hw/mainstone.h
@@ -34,5 +34,5 @@
 
 extern qemu_irq
 *mst_irq_init(struct pxa2xx_state_s *cpu, uint32_t base, int irq);
-
+extern void mst_keyboard_register(struct pxa2xx_keypad_s *kp);
 #endif /* __MAINSTONE_H__ */
Index: qemu/Makefile.target
===
--- qemu.orig/Makefile.target
+++ qemu/Makefile.target
@@ -499,7 +499,7 @@ VL_OBJS+= pflash_cfi01.o gumstix.o
 VL_OBJS+= spitz.o ide.o serial.o nand.o ecc.o
 VL_OBJS+= omap.o omap_lcdc.o omap1_clk.o omap_mmc.o omap_i2c.o
 VL_OBJS+= palm.o tsc210x.o
-VL_OBJS+= mst_fpga.o mainstone.o
+VL_OBJS+= mst_fpga.o mainstone.o mst_kpad.o
 CPPFLAGS += -DHAS_AUDIO
 endif
 ifeq ($(TARGET_BASE_ARCH), sh4)

Re: [Qemu-devel] high resolution timer question

2007-12-11 Thread Robert Reif


Robert Reif wrote:


The problem I'm having is with sparc32 using a sun openboot image in
nographics mode where the prom uses serial port A as the system console.
The serial port output shows up in the host terminal window that qemu
was started in.

Characters written to serial port A are not reliably making it to the 
screen.

Turning on serial debugging shows that the characters are written to the
serial port.  The characters do make it to the screen when debugging.


The problem seems to be caused by multiple streams outputting to the screen.
It looks like different ways of outputting to the same device may use 
different

streams!

[Qemu-devel] [PATCH] QEMU_STRACE documentation