[Qemu-devel] [PATCH 0/3] Monitor commands for 'simple' trace backend

[Prerna Saxena]

This patchset is based on Stefan's trace framework:
( http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg02407.html )

This adds the following monitor commands for the 'simple' backend:
- trace : to view current contents of the trace buffer
- info tracepoints  : to view all available tracepoints and their 
  state.
- tracepoint NAME on|off: to enable/disable the logging of data from 
  tracepoint 'NAME'.

-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

[Qemu-devel] [PATCH] Re: Tracing backends : Fix for building with --prefix

[Prerna Saxena]

This patch is a minor fix over Stefan's tracing framework, to enable 
compilation when the build directory is different from source.

Signed-off-by: Prerna Saxena 
---
 Makefile |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index a9f79a9..ef4ae55 100644
--- a/Makefile
+++ b/Makefile
@@ -130,10 +130,10 @@ bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS)
 
 iov.o: iov.c iov.h
 
-trace.h: trace-events
+trace.h: $(SRC_PATH)/trace-events
$(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h < 
$< > $@,"  GEN   $@")
 
-trace.c: trace-events
+trace.c: $(SRC_PATH)/trace-events
$(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -c < 
$< > $@,"  GEN   $@")
 
 trace.o: trace.c
-- 
1.6.2.5



-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

[Qemu-devel] Re: [PATCH v3 00/17] clean up vl.c code

[Jes Sorensen]

On 06/07/10 23:41, Juan Quintela wrote:
> Acked-by: Juan Quintela 
> 
> Nice, thanks.  Once there, perhaps you want to look about moving osdep.c
> definitions to os-{posix,win32}.c.  And no, that file is not nice
> either.

Good idea!

Once I see the first set in Anthony's tree, I'll have a look at osdep.c

Cheers,
Jes

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Avi Kivity]

On 06/08/2010 01:23 AM, Anthony Liguori wrote:
A better example would be a generic counter kernel mechanism.  I can 
envision such a device as doing nothing more than providing a 
read-only view of a counter with a userspace configurable divider 
and width.  Any write to the counter or read of any other byte 
outside the counter register would result in a trap to userspace.


What about latches?  byte access to word registers?  There will be as 
many special cases as there are timers.


If the kernel supported a bytecode/jit facility I'd happily use that 
to download portions of the device model into the kernel.




That should allow both the PIT and the HPET to be accelerated with 
minimal effort in the kernel.


IMO it's probably more effort than porting HPET to the kernel.  Try 
outlining an interface that supports PIT, HPET, RTC, and ACPI PMTIMER.



I was referring specifically to time sources, not time events.

An accelerated counter for HPET is pretty trivial.  It's a 32-bit 
register that's actually a nanosecond value in qemu.  We need to be 
able to set an offset from the host wall clock time, a means to stop 
it, and a means to start it.


The PIT is latched so the kernel needs to know enough about how to 
decode the PIT state to understand the latching.  There's very little 
state associated with latching though so I don't think this is a huge 
problem.  It's a fixed value write to a fixed register followed by a 
read to a fixed register.  The act of latching doesn't effect the 
state beyond the fact that you need to save the latched value in the 
event that you have a live migration before reading the latched value.


The PMTIMER is also pretty straight forward.  It's a variable port 
address (that's fixed during execution).


Even if we require three separate interfaces, the interfaces are so 
simply that it seems like an obvious win.


So a non-generic interface - 4x the interfaces (including RTC).

Those counters raise interrupts when they expire, and set various status 
bits in their hardware.  So we need 4x of:


  set counter value, frequency, and reload interval
  raise alarm to userspace on expiration
  set counter memory/ioport location and availability
  read counter value

and we haven't solved interrupt coalescing.






5. Risk

We may find out after all this is implemented that performance is 
not acceptable and all the work will have to be dropped.


That's another advantage to a straight port to userspace.  We can 
collect performance data with only a modest amount of engineering 
effort.


Port what exactly?  We have a userspace irqchip implementation.  What 
we don't have is just the ioapic/pic/pit in userspace, and the only 
way to try it out is to implement the whole thing.


If you take the kernel code and do a pretty straight port: switching 
kernel functions to libc functions and maintaining all the existing 
locking via pthreads, you could then implement a very simple MMIO/PIO 
dispatch mechanism in the kvm code that shortcutted those devices 
before we ever hit the qemu_mutex and the traditional qemu code 
paths.  It should be a relatively easy conversion and it gives a 
proper vehicle for doing experimentations.


Those devices don't exist independently of the rest of the devices.  If 
they need to post interrupts, they will need the traditional qemu code 
paths.


(I'm trying to view the move from the POV of the kernel first, assuming 
userspace is as efficient as possible; so I'm not arguing qemu 
inefficiencies should prevent us from doing it.  But they do add up 
considerably to the amount of work involved)




In fact, you could pretty quickly determine viability by porting the 
PIT to userspace and implementing a vpit interface in the kernel that 
allowed the channel 0 counters to be latched and read within 
lightweight exits.



Just looking at it shows the interface is incredibly messy.  You have to 
maintain the control word in the kernel (since it tells you which 
counter to read or write), so now you need a userspace interface to read 
and write the control word.  With the current interface, you have the 
entire thing in a black box that you don't need to worry about (except 
for the speaker port...).



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] [PATCH 0/5] Add '-device help' output for device params and help text

[Amit Shah]

On (Mon) Jun 07 2010 [11:09:32], Anthony Liguori wrote:
> On 05/31/2010 07:41 AM, Amit Shah wrote:
> >Hello,
> >
> >This patch series adds support to specify some descriptive help text
> >to qdev device parameters. This series adds some help text to the
> >virtserialport and net family of devices as an example, and the new
> >output is shown in the respective commits.
> >
> >This series also adds a new '-device help' option that lists all the
> >available qdev devices (which is avl. via -device ? now), and adds
> >each device's parameters to the output listing. This output also shows
> >the descriptive text.
> >
> >The idea is to auto-generate documentation from code and to populate
> >some wiki / qemu-doc.texi using this new target.
> 
> I really dislike having options print their own help.

Why? I really like it, coders can embed help exactly in the same place
they're adding / changing options and there's much less chance of
someone missing updating help strings when updating / adding options.

> Maybe we can introduce a proper -help option that takes an argument
> that can display subsystem specific help?
> 
> For instance:
> 
> qemu -help device
> 
> Would display the help output in this series.

What I'm adding here is similar; instead of -help device, I'm adding
-device help, and I think it's nicer because it fits directly in the
qdev code.

> My other concern is that we now have a big mess of properties that
> don't have help text.  What are the chances that anyone is going to
> go through and do this?
> 
> I'd rather we bite the bullet and add help everywhere before merging
> any of this because experience has shown that existing code usually
> never gets converted if not converted all at once.

Let me put my community contributor hat on: we're not really giving away
vibes that qemu has to be 100% enterprise-ready at each commit, are we?
qemu is a *development* project, and development happens one small
commit at a time, commit early and often. If I'm going to have to
maintiain hundreds of small help-related patches, it's soon going to
grow stale as people change related code and in the end I'll grow
frustrated and drop then entire exercise. Not the first time that
would've happened.

On the other hand, we commit this right away, and interested developers
in their own domains start contributing the small one-liners which
brings their subsystem up to the mark for documentation.

I think this is the best way to contribute such patches.

If you think some devices are going to go documentation-less, instead of
empty strings, I can do "description needed" strings, which can even
invite first-time contributors grep through this and contribute the
one-liners.

If the enterprise people want this fixed before any enterprise release,
they better commit resources to ensure they don't release anything that
has a 'documentation needed!' line. :-)

Amit

Re: [Qemu-devel] [PATCH 5/5] qdev: Add new '-device help' option, shows all devices and properties

[Amit Shah]

On (Mon) Jun 07 2010 [16:43:05], Markus Armbruster wrote:
> 
> There is "-device \?" and "-device help", but the user interface
> provides no clue about the difference between them.
> 
> "-device help" loses when we ever pick up a device model with name
> "help".  Not that "?" was a particularly smart choice...
> 
> Do we really need two kinds of help output?  Where the second is
> basically the same as "-device FOO,\?" for all FOO?  Is that convenience
> worth the extra UI complexity?

OK, so my big plan is to have something like this:

---

./qemu -device help

...
name "virtserialport", bus virtio-serial-bus
nr=uint32, The 'number' for the port for predictable port numbers.
chardev=chr, The chardev to associate this port with.
name=string, Name for the port that's exposed to the guest for port 
discovery.
...

---

./qemu -device virtserialport,?

virtserialport.nr=uint32, The 'number' for the port for predictable port 
numbers.

   Use this to spawn ports if you plan to migrate the guest and perform
   hot-plug and unplug operations.

virtserialport.chardev=chr, The chardev to associate this port with.

   External programs can communicate with the guest side of the channel
   using chardev

virtserialport.name=string, Name for the port that's exposed to the guest for 
port discovery.

   The name is exposed in Linux guests via sysfs and udev rules can be
   written to create symlinks to the ports. Apps in the guest can then
   easily find these ports and start communication.

---

So basically -device help gives a short, one-liner help message and the
-device ? option gives a slightly detailed message, if one is available.

How to do that: I'm thinking of two ways:

1)

DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID,
   "The 'number' for the port for predictable port 
numbers.",
   "Use this to spawn ports if you plan to migrate the 
guest and perform \n"
   "hot-plug and unplug operations." ),

ie, two different strings for the short and long descriptions

2)

DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID,
   "The 'number' for the port for predictable port 
numbers.\n"
   "Use this to spawn ports if you plan to migrate the 
guest and perform \n"
   "hot-plug and unplug operations." ),

ie, the same string, but the short and long descriptions are separated
by a '\n'.

Doing it the adds parsing to the printing routine for no extra benefit,
so I'm inclined to go with 1. Thoughts?

Amit

Re: [Qemu-devel] [PATCH v4] savevm: Really verify if a drive supports snapshots

[MORITA Kazutaka]

At Fri,  4 Jun 2010 16:35:59 -0300,
Miguel Di Ciurcio Filho wrote:
> 
> Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
> 
> First issue: Their names implies different porpouses, but they do the same 
> thing
> and have exactly the same code. Maybe copied and pasted and forgotten?
> bdrv_has_snapshot() is called in various places for actually checking if there
> is snapshots or not.
> 
> Second issue: the way bdrv_can_snapshot() verifies if a block driver supports 
> or
> not snapshots does not catch all cases. E.g.: a raw image.
> 
> So when do_savevm() is called, first thing it does is to set a global
> BlockDriverState to save the VM memory state calling get_bs_snapshots().
> 
> static BlockDriverState *get_bs_snapshots(void)
> {
> BlockDriverState *bs;
> DriveInfo *dinfo;
> 
> if (bs_snapshots)
> return bs_snapshots;
> QTAILQ_FOREACH(dinfo, &drives, next) {
> bs = dinfo->bdrv;
> if (bdrv_can_snapshot(bs))
> goto ok;
> }
> return NULL;
>  ok:
> bs_snapshots = bs;
> return bs;
> }
> 
> bdrv_can_snapshot() may return a BlockDriverState that does not support
> snapshots and do_savevm() goes on.
> 
> Later on in do_savevm(), we find:
> 
> QTAILQ_FOREACH(dinfo, &drives, next) {
> bs1 = dinfo->bdrv;
> if (bdrv_has_snapshot(bs1)) {
> /* Write VM state size only to the image that contains the state 
> */
> sn->vm_state_size = (bs == bs1 ? vm_state_size : 0);
> ret = bdrv_snapshot_create(bs1, sn);
> if (ret < 0) {
> monitor_printf(mon, "Error while creating snapshot on '%s'\n",
>bdrv_get_device_name(bs1));
> }
> }
> }
> 
> bdrv_has_snapshot(bs1) is not checking if the device does support or has
> snapshots as explained above. Only in bdrv_snapshot_create() the device is
> actually checked for snapshot support.
> 
> So, in cases where the first device supports snapshots, and the second does 
> not,
> the snapshot on the first will happen anyways. I believe this is not a good
> behavior. It should be an all or nothing process.
> 
> This patch addresses these issues by making bdrv_can_snapshot() actually do
> what it must do and enforces better tests to avoid errors in the middle of
> do_savevm(). bdrv_has_snapshot() is removed and replaced by 
> bdrv_can_snapshot()
> where appropriate.
> 
> bdrv_can_snapshot() was moved from savevm.c to block.c. It makes more sense 
> to me.
> 
> The loadvm_state() function was updated too to enforce that when loading a VM 
> at
> least all writable devices must support snapshots too.
> 
> Signed-off-by: Miguel Di Ciurcio Filho 
> ---
>  block.c  |   11 +++
>  block.h  |1 +
>  savevm.c |   58 --
>  3 files changed, 48 insertions(+), 22 deletions(-)
> 
> diff --git a/block.c b/block.c
> index cd70730..ace3cdb 100644
> --- a/block.c
> +++ b/block.c
> @@ -1720,6 +1720,17 @@ void bdrv_debug_event(BlockDriverState *bs, 
> BlkDebugEvent event)
>  /**/
>  /* handling of snapshots */
>  
> +int bdrv_can_snapshot(BlockDriverState *bs)
> +{
> +BlockDriver *drv = bs->drv;
> +if (!drv || !drv->bdrv_snapshot_create || bdrv_is_removable(bs) ||
> +bdrv_is_read_only(bs)) {
> +return 0;
> +}
> +
> +return 1;
> +}
> +

The underlying protocol could support snapshots, so I think we should
check against bs->file too.

--- a/block.c
+++ b/block.c
@@ -1671,6 +1671,9 @@ int bdrv_can_snapshot(BlockDriverState *bs)
 BlockDriver *drv = bs->drv;
 if (!drv || !drv->bdrv_snapshot_create || bdrv_is_removable(bs) ||
 bdrv_is_read_only(bs)) {
+if (bs->file) {
+return bdrv_can_snapshot(bs->file);
+}
 return 0;
 }
 
Regards,

Kazutaka

Re: [Qemu-devel] [PATCH 0/22] Refactor machine support

[Paul Brook]

> This series introduces a rather radical change in the way we deal with
> machine definitions in QEMU.

I think we should aim to eliminate machine_register_core, and design 
appropriately.  In particular I'd try and avoid adding options that become 
trivially redundant once you can easily change the device trees.

I'm undecided how much parameterisation it's worth trying to support in the 
device tree. IMO the current code has way too much magic, because creating a 
new variant involves hacking and rebuilding pc.c.

I'm extremely tempted by the extreme approach of punting everything to an 
external device tree builder. i.e. remove automagical device reation 
altogether. If you want USB and 6 virtio disks then ask your device tree 
builder to create a machine description that includes pci-ohci and a bunch of 
virtio-blk-pci devices. The virtio-blk devices reference "drives" by id, so 
the same host configuration can be used with a scsi HBA. A small shell script 
should be sufficient to replicate the limited machine variants currently 
supported.

The problem with doing clever device tree generation/manipulation inside qemu 
is that for anything vaguely nonstandard you're likely to have to hack your 
own device tree anyway. Even ram allocation is nontrivial, e.g. the hole below 
4G on the PC, and that's before you start with numa-like layouts.

On a similar note, I don't see any point having machine_create_from_core,
we can just ship appropriate config files.

Paul

Re: [Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option

[Paul Brook]

> max_cpus is complicated because it was used for multiple purposes.

I don't see any such uses.

> > This is a fundamental property/limitation of the hardware. Expect qemu to
> > crash if the value is modified.
> 
> In this case, the machine cores should be rejecting totally invalid
> values to prevent crashes from occurring.  My reading of realview does
> not suggest that a crash would occur.  Are you speaking in general terms
> or do you think it will actually fail in realview?

qemu_irq cpu_irq[4];
...
for (n = 0; n < smp_cpus; n++) {
cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];

I'm pretty sure bad things will happen there if smp_cpus is > 4.
Similar assumptions exist in apic.c, and probably others.

Paul

Re: [Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option

[Anthony Liguori]

On 06/07/2010 08:01 PM, Paul Brook wrote:

diff --git a/hw/realview.c b/hw/realview.c
index a36bdbe..8dcef80 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = {
  .init = realview_eb_mpcore_init,
  .opts_default = (QemuOptValue[]) {
  QOPT_VALUE("default_drive", "scsi"),
+QOPT_VALUE("max_cpus", "4"),
  { /* end of list */ }
  },
-.max_cpus = 4,
  };
 

By my reading this allows the user to modify this value. If so it is wrong.
   


max_cpus is complicated because it was used for multiple purposes.

I think max_cpus ought to be configurable.  The reason it's useful to 
configure it that it lets a downstream specify a recommended max cpu 
that's mostly relevant from a scalability perspective.  For instance, 
you may want to set the pc max_cpus to 64 since this is the highest that 
KVM supports today.



This is a fundamental property/limitation of the hardware. Expect qemu to
crash if the value is modified.
   


In this case, the machine cores should be rejecting totally invalid 
values to prevent crashes from occurring.  My reading of realview does 
not suggest that a crash would occur.  Are you speaking in general terms 
or do you think it will actually fail in realview?


Regards,

Anthony Liguori



Paul

   

Re: [Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option

[Paul Brook]

> diff --git a/hw/realview.c b/hw/realview.c
> index a36bdbe..8dcef80 100644
> --- a/hw/realview.c
> +++ b/hw/realview.c
> @@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = {
>  .init = realview_eb_mpcore_init,
>  .opts_default = (QemuOptValue[]) {
>  QOPT_VALUE("default_drive", "scsi"),
> +QOPT_VALUE("max_cpus", "4"),
>  { /* end of list */ }
>  },
> -.max_cpus = 4,
>  };

By my reading this allows the user to modify this value. If so it is wrong. 

This is a fundamental property/limitation of the hardware. Expect qemu to 
crash if the value is modified.

Paul

Re: [Qemu-devel] [PATCH 22/22] machine: introduce -machine-def option to define a machine via config

[Anthony Liguori]

On 06/07/2010 06:52 PM, Anthony Liguori wrote:

Since we have MachineCore and can represent a machine entirely via default
options, we can introduce a new option that let's us dynamically register a
machine based on those options.

For instance, we could add the following to target-x86_64.conf:

[machine-def]
  name = "pc-0.11"
  desc = "Standard PC"
  acpi = "on"
  pci = "on"
  cpu = "qemu64"
  max_cpus = "255"
  virtio-blk-pci.vectors = "0"
  virtio-serial-pci.max_nr_ports = "1"
  virtio-serial-pci.vectors = "0"
  ide-drive.ver = "0.11"
  scsi-disk.ver = "0.11"
  PCI.rombar = "0"

What's really exciting, is that a user can then define their own machines
that better suite their desires:

[kvmpc]
  name = "kvmpc"
  accel = "kvm|tcg"
  ram_size = "512M"
  max_cpus = "64"
  sockets = "16"
  default_drive = "virtio"

I'd eventually like to move all PC compatibility machines to the default
config but for now, I wanted to keep this simple.

Signed-off-by: Anthony Liguori
   


From the perspective of a tool like libvirt, I think there are a couple 
ways it could handle something like this and I think it's worth 
discussing the options.


Assume we move all the compat machine definitions into a config file, 
since libvirt presumably uses -nodefconfig today, it could simply 
include it's own machine definitions for each qemu version based on the 
definitions we ship.  That makes sure that the definition is always 
static for libvirt.


Another option would be for libvirt to not use -nodefconfig, and instead 
to let the user's global configs be read.  libvirt would then read the 
config file from the running qemu instance to sync it's state up.


The later option is a bit more work up front but longer term, I think it 
addresses a couple things nicely.  It provides a way for a user 
specified config to co-exist with libvirt.  It also let's tools tweak 
power config options in a way that's compatible with libvirt.


If libvirt can embed the qemu config description in its own XML, then 
there is no problem for libvirt to recreate the system on a different 
box even if the global configuration is different.


Regards,

Anthony Liguori


diff --git a/qemu-config.c b/qemu-config.c
index a0cb34f..9b5415d 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -345,6 +345,15 @@ QemuOptsList qemu_machine_opts = {
  },
  };

+QemuOptsList qemu_machine_def_opts = {
+.name = "machine-def",
+.implied_opt_name = "name",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_machine_def_opts.head),
+.desc = {
+{ /* end of list */ }
+},
+};
+
  static QemuOptsList *vm_config_groups[] = {
  &qemu_drive_opts,
  &qemu_chardev_opts,
@@ -356,6 +365,7 @@ static QemuOptsList *vm_config_groups[] = {
  &qemu_mon_opts,
  &qemu_cpudef_opts,
  &qemu_machine_opts,
+&qemu_machine_def_opts,
  NULL,
  };

diff --git a/qemu-config.h b/qemu-config.h
index 6f52188..1b7324c 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -15,6 +15,7 @@ extern QemuOptsList qemu_global_opts;
  extern QemuOptsList qemu_mon_opts;
  extern QemuOptsList qemu_cpudef_opts;
  extern QemuOptsList qemu_machine_opts;
+extern QemuOptsList qemu_machine_def_opts;

  QemuOptsList *qemu_find_opts(const char *group);
  int qemu_set_option(const char *str);
diff --git a/qemu-options.hx b/qemu-options.hx
index 32fd32a..2bafe22 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -43,6 +43,14 @@ STEXI
  Select the emulated @var{machine}
  ETEXI

+DEF("machine-def", HAS_ARG, QEMU_OPTION_machine_def,
+"-machine-def name[,opt=val...] define a new machine\n", QEMU_ARCH_ALL)
+STEXI
+...@item -machine-def @var{name}[,@var{op...@var{val}...]
+...@findex -machine-def
+Define a new machine
+ETEXI
+
  DEF("cpu", HAS_ARG, QEMU_OPTION_cpu,
  "-cpu cpuselect CPU (-cpu ? for list)\n", QEMU_ARCH_ALL)
  STEXI
diff --git a/vl.c b/vl.c
index 150dd41..7797187 100644
--- a/vl.c
+++ b/vl.c
@@ -1683,6 +1683,59 @@ void machine_set_default(const char *name)
  default_machine = name;
  }

+typedef struct MachineDefineHelper
+{
+QemuOptValue *defaults;
+int length;
+int capacity;
+} MachineDefineHelper;
+
+static void helper_grow(MachineDefineHelper *helper)
+{
+if ((helper->capacity - helper->length)<  2) {
+helper->capacity += 100;
+helper->defaults = qemu_realloc(helper->defaults,
+helper->capacity * 
sizeof(QemuOptValue));
+}
+}
+
+static int machine_define_prop(const char *name, const char *value, void 
*opaque)
+{
+MachineDefineHelper *helper = opaque;
+QemuOptValue *v;
+
+if (strcmp(name, "core") == 0) {
+return 0;
+}
+
+helper_grow(helper);
+v =&helper->defaults[helper->length++];
+v->name = qemu_strdup(name);
+v->value = qemu_strdup(value);
+
+return 0;
+}
+
+static int machine_define(QemuOpts *opts, void *opaque)
+{
+MachineDefineHelper *helper;
+const char *core;
+
+core = qemu_opt_get(opts, "core");
+if (!core

[Qemu-devel] [PATCH 18/22] machine: final conversion to pure QemuOpts

[Anthony Liguori]

All we need to do is convert name and desc over and we're now purely opts
driven.

Signed-off-by: Anthony Liguori 

diff --git a/hw/an5206.c b/hw/an5206.c
index 0d6a6f0..5dd679c 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -88,9 +88,12 @@ static void an5206_init(QemuOpts *opts)
 }
 
 static QEMUMachine an5206_machine = {
-.name = "an5206",
-.desc = "Arnewsh 5206",
 .init = an5206_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "an5206"),
+QOPT_VALUE("desc", "Arnewsh 5206"),
+{ /* end of list */ },
+},
 };
 
 static void an5206_machine_init(void)
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index 7999d47..f1ac577 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -386,9 +386,12 @@ void axisdev88_init (QemuOpts *opts)
 }
 
 static QEMUMachine axisdev88_machine = {
-.name = "axis-dev88",
-.desc = "AXIS devboard 88",
 .init = axisdev88_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "axis-dev88"),
+QOPT_VALUE("desc", "AXIS devboard 88"),
+{ /* end of list */ },
+},
 };
 
 static void axisdev88_machine_init(void)
diff --git a/hw/boards.h b/hw/boards.h
index a4dde9f..947fa33 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,24 +5,18 @@
 
 #include "qdev.h"
 
-typedef struct QEMUMachine QEMUMachine;
-
 typedef void QEMUMachineInitFunc(QemuOpts *opts);
 
-struct QEMUMachine {
-const char *name;
-const char *desc;
+typedef struct QEMUMachine {
 QEMUMachineInitFunc *init;
 QemuOptDesc *opts_desc;
 QemuOptValue *opts_default;
-struct QEMUMachine *next;
-};
+QTAILQ_ENTRY(QEMUMachine) node;
+} QEMUMachine;
 
-int qemu_register_machine(QEMUMachine *m);
+int qemu_register_machine(QEMUMachine *machine);
 void machine_set_default(const char *name);
 
-extern QEMUMachine *current_machine;
-
 #define QOPT_COMPAT(driver, property, value) \
 QOPT_VALUE(driver "." property, value)
 
@@ -31,9 +25,15 @@ extern QEMUMachine *current_machine;
 
 #define COMMON_MACHINE_OPTS()  \
 {   \
+.name = "name", \
+.type = QEMU_OPT_STRING,\
+},{ \
 .name = "driver",   \
 .type = QEMU_OPT_STRING,\
 },{ \
+.name = "desc", \
+.type = QEMU_OPT_STRING,\
+},{ \
 .name = "ram_size", \
 .type = QEMU_OPT_SIZE,  \
 },{ \
diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
index db94251..e102a74 100644
--- a/hw/dummy_m68k.c
+++ b/hw/dummy_m68k.c
@@ -67,9 +67,12 @@ static void dummy_m68k_init(QemuOpts *opts)
 }
 
 static QEMUMachine dummy_m68k_machine = {
-.name = "dummy",
-.desc = "Dummy board",
 .init = dummy_m68k_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "dummy"),
+QOPT_VALUE("desc", "Dummy board"),
+{ /* end of list */ },
+},
 };
 
 static void dummy_m68k_machine_init(void)
diff --git a/hw/etraxfs.c b/hw/etraxfs.c
index e41d1ce..7fbf366 100644
--- a/hw/etraxfs.c
+++ b/hw/etraxfs.c
@@ -173,9 +173,12 @@ void bareetraxfs_init (QemuOpts *opts)
 }
 
 static QEMUMachine bareetraxfs_machine = {
-.name = "bareetraxfs",
-.desc = "Bare ETRAX FS board",
 .init = bareetraxfs_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "bareetraxfs"),
+QOPT_VALUE("desc", "Bare ETRAX FS board"),
+{ /* end of list */ },
+},
 };
 
 static void bareetraxfs_machine_init(void)
diff --git a/hw/gumstix.c b/hw/gumstix.c
index 6739332..659863c 100644
--- a/hw/gumstix.c
+++ b/hw/gumstix.c
@@ -113,15 +113,21 @@ static void verdex_init(QemuOpts *opts)
 }
 
 static QEMUMachine connex_machine = {
-.name = "connex",
-.desc = "Gumstix Connex (PXA255)",
 .init = connex_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "connex"),
+QOPT_VALUE("desc", "Gumstix Connex (PXA255)"),
+{ /* end of list */ },
+},
 };
 
 static QEMUMachine verdex_machine = {
-.name = "verdex",
-.desc = "Gumstix Verdex (PXA270)",
 .init = verdex_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "verdex"),
+QOPT_VALUE("desc", "Gumstix Verdex (PXA270)"),
+{ /* end of list */ },
+},
 };
 
 static void gumstix_machine_init(void)
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index b505773..110cb4c 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -512,9 +512,12 @@ static void integratorcp_init(QemuOpts *opts)
 }
 
 static QEMUMachine integratorcp_machine = {
-.name = "integratorcp",
-.desc = "ARM Integrator/CP (ARM926EJ-S)",
 .init = integratorcp_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("name", "integratorcp"),
+QOPT_VALUE("desc", "ARM Integrator/CP (ARM926EJ-S)"

[Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option

[Anthony Liguori]

max_cpus is a weird property today.  On the one hand, it represents the maximum
CPUs a board can support and is used to validate the number of vcpus requested
by the user.

On the other hand, max_cpus can be set by the user in which case it is taken
to mean the number of physical sockets that should be advertised by the
firmware.  Furthermore, if max_cpus isn't explicitly set by the user, it's
defaulted to the number of smp_cpus.  But there's actually a second copy of
max_cpus that still represents the maximum cpus spported by the platform.

Yes, it's confusing.  So let's be a bit more obvious.  This patch introduces
a sockets parameter that allows a user to explicitly set the number of
advertised sockets apart from the number of maximum cpus.

This is something of a stop gap.  We really ought to specify a more rich
NUMA topology as machine options but that will come later.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 887487e..5176e95 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -14,7 +14,6 @@ struct QEMUMachine {
 const char *alias;
 const char *desc;
 QEMUMachineInitFunc *init;
-int max_cpus;
 int is_default;
 QemuOptDesc *opts_desc;
 QemuOptValue *opts_default;
@@ -77,6 +76,12 @@ extern QEMUMachine *current_machine;
 },{ \
 .name = "default_drive",\
 .type = QEMU_OPT_STRING,\
+},{ \
+.name = "max_cpus", \
+.type = QEMU_OPT_NUMBER,\
+},{ \
+.name = "sockets",  \
+.type = QEMU_OPT_NUMBER,\
 }
 
 
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 22ebb50..de4454f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -321,7 +321,8 @@ int fw_cfg_add_file(FWCfgState *s,  const char *dir, const 
char *filename,
 }
 
 FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
-target_phys_addr_t ctl_addr, target_phys_addr_t 
data_addr)
+target_phys_addr_t ctl_addr, target_phys_addr_t 
data_addr,
+QemuOpts *opts)
 {
 FWCfgState *s;
 int io_ctl_memory, io_data_memory;
@@ -349,7 +350,8 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t 
data_port,
 fw_cfg_add_bytes(s, FW_CFG_UUID, qemu_uuid, 16);
 fw_cfg_add_i16(s, FW_CFG_NOGRAPHIC, (uint16_t)(display_type == 
DT_NOGRAPHIC));
 fw_cfg_add_i16(s, FW_CFG_NB_CPUS, (uint16_t)smp_cpus);
-fw_cfg_add_i16(s, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
+fw_cfg_add_i16(s, FW_CFG_MAX_CPUS,
+   (uint16_t)qemu_opt_get_number(opts, "sockets", smp_cpus));
 fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
 
 vmstate_register(-1, &vmstate_fw_cfg, s);
diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h
index 4d13a4f..bdf9227 100644
--- a/hw/fw_cfg.h
+++ b/hw/fw_cfg.h
@@ -63,7 +63,8 @@ int fw_cfg_add_callback(FWCfgState *s, uint16_t key, 
FWCfgCallback callback,
 int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
 uint8_t *data, uint32_t len);
 FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
-target_phys_addr_t crl_addr, target_phys_addr_t 
data_addr);
+target_phys_addr_t crl_addr, target_phys_addr_t 
data_addr,
+QemuOpts *opts);
 
 #endif /* NO_QEMU_PROTOS */
 
diff --git a/hw/multiboot.c b/hw/multiboot.c
index a1b665c..7cdc77b 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -22,6 +22,8 @@
  * THE SOFTWARE.
  */
 
+#include "qemu-common.h"
+#include "qemu-option.h"
 #include "hw.h"
 #include "fw_cfg.h"
 #include "multiboot.h"
diff --git a/hw/pc.c b/hw/pc.c
index 44f5b62..55681d8 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -449,7 +449,7 @@ int e820_add_entry(uint64_t address, uint64_t length, 
uint32_t type)
 return e820_table.count;
 }
 
-static void *bochs_bios_init(void)
+static void *bochs_bios_init(QemuOpts *opts)
 {
 void *fw_cfg;
 uint8_t *smbios_table;
@@ -468,7 +468,7 @@ static void *bochs_bios_init(void)
 register_ioport_write(0x500, 1, 1, bochs_bios_write, NULL);
 register_ioport_write(0x503, 1, 1, bochs_bios_write, NULL);
 
-fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
+fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0, opts);
 
 fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
 fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
@@ -804,7 +804,8 @@ void pc_memory_init(ram_addr_t ram_size,
 const char *kernel_cmdline,
 const char *initrd_filename,
 ram_addr_t *below_4g_mem_size_p,
-ram_addr_t *above_4g_mem_size_p)
+ram_addr_t *above_4g_mem_size_p,
+QemuOpts *opts)
 {
 char *filename;
 int ret, linux_boot, i;
@@ -882,7 +883,7 @@ void pc_memory_init(ram_addr_t ram_size,

[Qemu-devel] [PATCH 21/22] machine: convert pc machines to split core vs machine API

[Anthony Liguori]

Signed-off-by: Anthony Liguori 

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 5696aa7..c7c1bd7 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -162,134 +162,113 @@ static void pc_init(QemuOpts *opts)
 }
 }
 
-static QemuOptDesc pc_opts_desc[] = {
-COMMON_MACHINE_OPTS(),
-{
-.name = "acpi",
-.type = QEMU_OPT_BOOL,
-},
-{
-.name = "pci",
-.type = QEMU_OPT_BOOL,
-},
-{ /* end of list */ },
-};
-
 #ifdef TARGET_X86_64
 #define PC_DEFAULT_CPU_MODEL "qemu64"
 #else
 #define PC_DEFAULT_CPU_MODEL "qemu32"
 #endif
 
-static QEMUMachine pc_machine = {
-.init = pc_init,
-.opts_desc = pc_opts_desc,
-.opts_default = (QemuOptValue[]) {
-QOPT_VALUE("name", "pc"),
-QOPT_VALUE("desc", "Standard PC"),
-QOPT_VALUE("acpi", "on"),
-QOPT_VALUE("pci", "on"),
-QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
-QOPT_VALUE("max_cpus", "255"),
-{ /* end of list */ }
-},
+static QemuOptValue pc_machine[] = {
+QOPT_VALUE("name", "pc"),
+QOPT_VALUE("desc", "Standard PC"),
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_VALUE("max_cpus", "255"),
+{ /* end of list */ }
 };
 
-static QEMUMachine pc_machine_v0_13 = {
-.init = pc_init,
-.opts_desc = pc_opts_desc,
-.opts_default = (QemuOptValue[]) {
-QOPT_VALUE("name", "pc-0.13"),
-QOPT_VALUE("desc", "Standard PC"),
-QOPT_VALUE("acpi", "on"),
-QOPT_VALUE("pci", "on"),
-QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
-QOPT_VALUE("max_cpus", "255"),
-{ /* end of list */ }
-},
+static QemuOptValue pc_machine_v0_13[] = {
+QOPT_VALUE("name", "pc-0.13"),
+QOPT_VALUE("desc", "Standard PC"),
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_VALUE("max_cpus", "255"),
+{ /* end of list */ }
 };
 
-static QEMUMachine pc_machine_v0_12 = {
-.init = pc_init,
-.opts_desc = pc_opts_desc,
-.opts_default = (QemuOptValue[]) {
-QOPT_VALUE("name", "pc-0.12"),
-QOPT_VALUE("desc", "Standard PC"),
-QOPT_VALUE("acpi", "on"),
-QOPT_VALUE("pci", "on"),
-QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
-QOPT_VALUE("max_cpus", "255"),
-QOPT_COMPAT_INT("virtio-serial-pci", "max_nr_ports", 1),
-QOPT_COMPAT_INT("virtio-serial-pci", "vectors", 0),
-{ /* end of list */ }
-},
+static QemuOptValue pc_machine_v0_12[] = {
+QOPT_VALUE("name", "pc-0.12"),
+QOPT_VALUE("desc", "Standard PC"),
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_VALUE("max_cpus", "255"),
+QOPT_COMPAT_INT("virtio-serial-pci", "max_nr_ports", 1),
+QOPT_COMPAT_INT("virtio-serial-pci", "vectors", 0),
+{ /* end of list */ }
 };
 
-static QEMUMachine pc_machine_v0_11 = {
-.init = pc_init,
-.opts_desc = pc_opts_desc,
-.opts_default = (QemuOptValue[]) {
-QOPT_VALUE("name", "pc-0.11"),
-QOPT_VALUE("desc", "Standard PC, qemu 0.11"),
-QOPT_VALUE("acpi", "on"),
-QOPT_VALUE("pci", "on"),
-QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
-QOPT_VALUE("max_cpus", "255"),
-QOPT_COMPAT_INT("virtio-blk-pci", "vectors", 0),
-QOPT_COMPAT_INT("virtio-serial-pci", "max_nr_ports", 1),
-QOPT_COMPAT_INT("virtio-serial-pci", "vectors", 0),
-QOPT_COMPAT("ide-drive", "ver", "0.11"),
-QOPT_COMPAT("scsi-disk", "ver", "0.11"),
-QOPT_COMPAT_INT("PCI", "rombar", 0),
-{ /* end of list */ }
-}
+static QemuOptValue pc_machine_v0_11[] = {
+QOPT_VALUE("name", "pc-0.11"),
+QOPT_VALUE("desc", "Standard PC, qemu 0.11"),
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_VALUE("max_cpus", "255"),
+QOPT_COMPAT_INT("virtio-blk-pci", "vectors", 0),
+QOPT_COMPAT_INT("virtio-serial-pci", "max_nr_ports", 1),
+QOPT_COMPAT_INT("virtio-serial-pci", "vectors", 0),
+QOPT_COMPAT("ide-drive", "ver", "0.11"),
+QOPT_COMPAT("scsi-disk", "ver", "0.11"),
+QOPT_COMPAT_INT("PCI", "rombar", 0),
+{ /* end of list */ }
 };
 
-static QEMUMachine pc_machine_v0_10 = {
-.init = pc_init,
-.opts_desc = pc_opts_desc,
-.opts_default = (QemuOptValue[]) {
-QOPT_VALUE("name", "pc-0.10"),
-QOPT_VALUE("desc", "Standard PC, qemu 0.10"),
-QOPT_VALUE("acpi", "on"),
-QOPT_VALUE("pci", "on"),
-QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
-QOPT_VALUE("max_cpu", "255"),
-QOPT_COMPAT_INT("virtio-blk-pci", "class", PCI_CLASS_STORAGE_OTHER),
-QOPT_COMPAT_INT("virtio-serial-pci", "class", PCI_CLASS_DISPLAY_OTHER),
-QOPT_COMPAT_INT("virtio-net-pci", "vectors", 0),
-QOPT_COMPAT_INT("virtio-blk-pci", "vectors", 0),
-QOPT_COMPAT_INT("

[Qemu-devel] [PATCH 12/22] machine: some sugary macros to simplify machine default options

[Anthony Liguori]

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index c7358ae..e05637b 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -33,6 +33,12 @@ int qemu_register_machine(QEMUMachine *m);
 
 extern QEMUMachine *current_machine;
 
+#define QOPT_COMPAT(driver, property, value) \
+QOPT_VALUE(driver "." property, value)
+
+#define QOPT_COMPAT_INT(driver, property, value) \
+QOPT_VALUE(driver "." property, stringify(value))
+
 #define COMMON_MACHINE_OPTS()  \
 {   \
 .name = "driver",   \
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 28c1408..104206c 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -190,18 +190,9 @@ static QEMUMachine pc_machine = {
 .is_default = 1,
 .opts_desc = pc_opts_desc,
 .opts_default = (QemuOptValue[]) {
-{
-.name  = "acpi",
-.value = "on",
-},
-{
-.name  = "pci",
-.value = "on",
-},
-{
-.name = "cpu",
-.value = PC_DEFAULT_CPU_MODEL,
-},
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
 { /* end of list */ }
 },
 };
@@ -213,25 +204,11 @@ static QEMUMachine pc_machine_v0_12 = {
 .max_cpus = 255,
 .opts_desc = pc_opts_desc,
 .opts_default = (QemuOptValue[]) {
-{
-.name  = "acpi",
-.value = "on",
-},
-{
-.name  = "pci",
-.value = "on",
-},
-{
-.name = "cpu",
-.value = PC_DEFAULT_CPU_MODEL,
-},
-{
-.name = "virtio-serial-pci.max_nr_ports",
-.value = stringify(1),
-},{
-.name = "virtio-serial-pci.vectors",
-.value = stringify(0),
-},
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_COMPAT_INT("virtio-serial-pci", "max_nr_ports", 1),
+QOPT_COMPAT_INT("virtio-serial-pci", "vectors", 0),
 { /* end of list */ }
 },
 };
@@ -243,37 +220,15 @@ static QEMUMachine pc_machine_v0_11 = {
 .max_cpus = 255,
 .opts_desc = pc_opts_desc,
 .opts_default = (QemuOptValue[]) {
-{
-.name  = "acpi",
-.value = "on",
-},
-{
-.name  = "pci",
-.value = "on",
-},
-{
-.name = "cpu",
-.value = PC_DEFAULT_CPU_MODEL,
-},
-{
-.name = "virtio-blk-pci.vectors",
-.value = stringify(0),
-},{
-.name = "virtio-serial-pci.max_nr_ports",
-.value = stringify(1),
-},{
-.name = "virtio-serial-pci.vectors",
-.value = stringify(0),
-},{
-.name = "ide-drive.ver",
-.value = "0.11",
-},{
-.name = "scsi-disk.ver",
-.value = "0.11",
-},{
-.name = "PCI.rombar",
-.value = stringify(0),
-},
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_COMPAT_INT("virtio-blk-pci", "vectors", 0),
+QOPT_COMPAT_INT("virtio-serial-pci", "max_nr_ports", 1),
+QOPT_COMPAT_INT("virtio-serial-pci", "vectors", 0),
+QOPT_COMPAT("ide-drive", "ver", "0.11"),
+QOPT_COMPAT("scsi-disk", "ver", "0.11"),
+QOPT_COMPAT_INT("PCI", "rombar", 0),
 { /* end of list */ }
 }
 };
@@ -285,46 +240,18 @@ static QEMUMachine pc_machine_v0_10 = {
 .max_cpus = 255,
 .opts_desc = pc_opts_desc,
 .opts_default = (QemuOptValue[]) {
-{
-.name  = "acpi",
-.value = "on",
-},
-{
-.name  = "pci",
-.value = "on",
-},
-{
-.name = "cpu",
-.value = PC_DEFAULT_CPU_MODEL,
-},
-{
-.name = "virtio-blk-pci.class",
-.value = stringify(PCI_CLASS_STORAGE_OTHER),
-},{
-.name = "virtio-serial-pci.class",
-.value = stringify(PCI_CLASS_DISPLAY_OTHER),
-},{
-.name = "virtio-serial-pci.max_nr_ports",
-.value = stringify(1),
-},{
-.name = "virtio-serial-pci.vectors",
-.value = stringify(0),
-},{
-.name = "virtio-net-pci.vectors",
-.value = stringify(0),
-},{
-.name = "virtio-blk-pci.vectors",
-.value = stringify(0),
-},{
-.name = "ide-drive.ver",
-.value = "0.10",
-},{
-.name = "scsi-disk.ver",
-.value = "0.10",
-},{
-.name = "PCI.rombar",
-.value = stringify(0),
-},
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+Q

[Qemu-devel] [PATCH 19/22] machine: introduce accel option to allow selection of kvm or tcg

[Anthony Liguori]

Syntax is -machine accel=kvm
  -machine accel=tcg
  -machine accel=kvm|tcg

kvm|tcg tries kvm and fallbacks on tcg if kvm support isn't available.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 947fa33..1097561 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -81,6 +81,9 @@ void machine_set_default(const char *name);
 },{ \
 .name = "sockets",  \
 .type = QEMU_OPT_NUMBER,\
+},{ \
+.name = "accel",\
+.type = QEMU_OPT_STRING,\
 }
 
 
diff --git a/vl.c b/vl.c
index d84fc65..7cb5865 100644
--- a/vl.c
+++ b/vl.c
@@ -2654,6 +2654,8 @@ int main(int argc, char **argv, char **envp)
 int defconfig = 1;
 QemuOpts *machine_opts = NULL;
 int max_cpus = 0;
+const char *accel;
+int tcg_fallback = 0;
 
 error_set_progname(argv[0]);
 
@@ -3272,7 +3274,10 @@ int main(int argc, char **argv, char **envp)
 do_smbios_option(optarg);
 break;
 case QEMU_OPTION_enable_kvm:
-kvm_allowed = 1;
+if (!qemu_opts_parsef(&qemu_machine_opts, "accel=kvm")) {
+printf("failed\n");
+exit(1);
+}
 break;
 case QEMU_OPTION_usb:
 usb_enabled = 1;
@@ -3629,15 +3634,36 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 
+accel = qemu_opt_get(machine_opts, "accel");
+if (accel) {
+if (!strcmp(accel, "kvm")) {
+kvm_allowed = 1;
+} else if (!strcmp(accel, "tcg")) {
+kvm_allowed = 0;
+} else if (!strcmp(accel, "kvm|tcg")) {
+kvm_allowed = 1;
+tcg_fallback = 1;
+} else {
+fprintf(stderr, "accel: invalid option %s\n", accel);
+exit(1);
+}
+}
+
 if (kvm_allowed) {
 int ret = kvm_init(smp_cpus);
 if (ret < 0) {
 if (!kvm_available()) {
 printf("KVM not supported for this target\n");
+exit(1);
 } else {
 fprintf(stderr, "failed to initialize KVM: %s\n", 
strerror(-ret));
+
+if (tcg_fallback) {
+kvm_allowed = 0;
+} else {
+exit(1);
+}
 }
-exit(1);
 }
 }
 
-- 
1.7.0.4

[Qemu-devel] [PATCH 11/22] machine: replace compat_props with opts_default

[Anthony Liguori]

Right now, machine structs can hard code GlobalProperty lists of default qdev
global properties.  This doesn't generalize well to a config file though because
there are three parameters: driver, property, value.

This patch moves this data to the generic machine opts default list.  In the
process, it converts the form to driver.property=value.  Now any option with
a '.' in the name is treated as a compat global property.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 06b9f73..c7358ae 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -24,7 +24,6 @@ struct QEMUMachine {
 no_cdrom:1,
 no_sdcard:1;
 int is_default;
-GlobalProperty *compat_props;
 QemuOptDesc *opts_desc;
 QemuOptValue *opts_default;
 struct QEMUMachine *next;
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0ad1145..28c1408 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -225,20 +225,15 @@ static QEMUMachine pc_machine_v0_12 = {
 .name = "cpu",
 .value = PC_DEFAULT_CPU_MODEL,
 },
-{ /* end of list */ }
-},
-.compat_props = (GlobalProperty[]) {
 {
-.driver   = "virtio-serial-pci",
-.property = "max_nr_ports",
-.value= stringify(1),
+.name = "virtio-serial-pci.max_nr_ports",
+.value = stringify(1),
 },{
-.driver   = "virtio-serial-pci",
-.property = "vectors",
-.value= stringify(0),
+.name = "virtio-serial-pci.vectors",
+.value = stringify(0),
 },
 { /* end of list */ }
-}
+},
 };
 
 static QEMUMachine pc_machine_v0_11 = {
@@ -260,33 +255,24 @@ static QEMUMachine pc_machine_v0_11 = {
 .name = "cpu",
 .value = PC_DEFAULT_CPU_MODEL,
 },
-{ /* end of list */ }
-},
-.compat_props = (GlobalProperty[]) {
 {
-.driver   = "virtio-blk-pci",
-.property = "vectors",
-.value= stringify(0),
+.name = "virtio-blk-pci.vectors",
+.value = stringify(0),
 },{
-.driver   = "virtio-serial-pci",
-.property = "max_nr_ports",
-.value= stringify(1),
+.name = "virtio-serial-pci.max_nr_ports",
+.value = stringify(1),
 },{
-.driver   = "virtio-serial-pci",
-.property = "vectors",
-.value= stringify(0),
+.name = "virtio-serial-pci.vectors",
+.value = stringify(0),
 },{
-.driver   = "ide-drive",
-.property = "ver",
-.value= "0.11",
+.name = "ide-drive.ver",
+.value = "0.11",
 },{
-.driver   = "scsi-disk",
-.property = "ver",
-.value= "0.11",
+.name = "scsi-disk.ver",
+.value = "0.11",
 },{
-.driver   = "PCI",
-.property = "rombar",
-.value= stringify(0),
+.name = "PCI.rombar",
+.value = stringify(0),
 },
 { /* end of list */ }
 }
@@ -311,45 +297,33 @@ static QEMUMachine pc_machine_v0_10 = {
 .name = "cpu",
 .value = PC_DEFAULT_CPU_MODEL,
 },
-{ /* end of list */ }
-},
-.compat_props = (GlobalProperty[]) {
 {
-.driver   = "virtio-blk-pci",
-.property = "class",
-.value= stringify(PCI_CLASS_STORAGE_OTHER),
+.name = "virtio-blk-pci.class",
+.value = stringify(PCI_CLASS_STORAGE_OTHER),
 },{
-.driver   = "virtio-serial-pci",
-.property = "class",
-.value= stringify(PCI_CLASS_DISPLAY_OTHER),
+.name = "virtio-serial-pci.class",
+.value = stringify(PCI_CLASS_DISPLAY_OTHER),
 },{
-.driver   = "virtio-serial-pci",
-.property = "max_nr_ports",
-.value= stringify(1),
+.name = "virtio-serial-pci.max_nr_ports",
+.value = stringify(1),
 },{
-.driver   = "virtio-serial-pci",
-.property = "vectors",
-.value= stringify(0),
+.name = "virtio-serial-pci.vectors",
+.value = stringify(0),
 },{
-.driver   = "virtio-net-pci",
-.property = "vectors",
-.value= stringify(0),
+.name = "virtio-net-pci.vectors",
+.value = stringify(0),
 },{
-.driver   = "virtio-blk-pci",
-.property = "vectors",
-.value= stringify(0),
+.name = "virtio-blk-pci.vectors",
+.value = stringify(0),
 },{
-.driver   = "ide-drive",
-.property = "ver",
-.value= "0.10",
+.name = "ide-drive.ver",
+.value = "0.10",
 },{
-   

[Qemu-devel] [PATCH 16/22] machine: move default machine out of machine definitions

[Anthony Liguori]

There can only be one default machine so instead of setting in each machine
whether it's the default, simply declare what the name of the default machine
is.  A nice characteristic of this is that we technically don't need to
describe the default machine in QEMU anymore.  Instead, it could be described
in a config file but this patch doesn't do that.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 5176e95..b99dc68 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -14,13 +14,13 @@ struct QEMUMachine {
 const char *alias;
 const char *desc;
 QEMUMachineInitFunc *init;
-int is_default;
 QemuOptDesc *opts_desc;
 QemuOptValue *opts_default;
 struct QEMUMachine *next;
 };
 
 int qemu_register_machine(QEMUMachine *m);
+void machine_set_default(const char *name);
 
 extern QEMUMachine *current_machine;
 
diff --git a/hw/etraxfs.c b/hw/etraxfs.c
index 1cb6052..e41d1ce 100644
--- a/hw/etraxfs.c
+++ b/hw/etraxfs.c
@@ -176,12 +176,12 @@ static QEMUMachine bareetraxfs_machine = {
 .name = "bareetraxfs",
 .desc = "Bare ETRAX FS board",
 .init = bareetraxfs_init,
-.is_default = 1,
 };
 
 static void bareetraxfs_machine_init(void)
 {
 qemu_register_machine(&bareetraxfs_machine);
+machine_set_default("bareetraxfs");
 }
 
 machine_init(bareetraxfs_machine_init);
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index 36ebaf0..b505773 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -515,12 +515,12 @@ static QEMUMachine integratorcp_machine = {
 .name = "integratorcp",
 .desc = "ARM Integrator/CP (ARM926EJ-S)",
 .init = integratorcp_init,
-.is_default = 1,
 };
 
 static void integratorcp_machine_init(void)
 {
 qemu_register_machine(&integratorcp_machine);
+machine_set_default("integratorcp");
 }
 
 machine_init(integratorcp_machine_init);
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index b6eb94d..1ed8871 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -293,12 +293,12 @@ static QEMUMachine mcf5208evb_machine = {
 .name = "mcf5208evb",
 .desc = "MCF5206EVB",
 .init = mcf5208evb_init,
-.is_default = 1,
 };
 
 static void mcf5208evb_machine_init(void)
 {
 qemu_register_machine(&mcf5208evb_machine);
+machine_set_default("mcf5208evb");
 }
 
 machine_init(mcf5208evb_machine_init);
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index 0ef0090..f89be6d 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -993,12 +993,12 @@ static QEMUMachine mips_malta_machine = {
 .name = "malta",
 .desc = "MIPS Malta Core LV",
 .init = mips_malta_init,
-.is_default = 1,
 };
 
 static void mips_malta_machine_init(void)
 {
 qemu_register_machine(&mips_malta_machine);
+machine_set_default("malta");
 }
 
 machine_init(mips_malta_machine_init);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index d02bf20..1bb6bee 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -186,7 +186,6 @@ static QEMUMachine pc_machine = {
 .alias = "pc",
 .desc = "Standard PC",
 .init = pc_init,
-.is_default = 1,
 .opts_desc = pc_opts_desc,
 .opts_default = (QemuOptValue[]) {
 QOPT_VALUE("acpi", "on"),
@@ -277,6 +276,7 @@ static void pc_machine_init(void)
 qemu_register_machine(&pc_machine_v0_11);
 qemu_register_machine(&pc_machine_v0_10);
 qemu_register_machine(&isapc_machine);
+machine_set_default("pc");
 }
 
 machine_init(pc_machine_init);
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 5cc5787..5528960 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -201,12 +201,12 @@ static QEMUMachine petalogix_s3adsp1800_machine = {
 .name = "petalogix-s3adsp1800",
 .desc = "Petalogix linux refdesign for xilinx Spartan 3ADSP1800",
 .init = petalogix_s3adsp1800_init,
-.is_default = 1
 };
 
 static void petalogix_s3adsp1800_machine_init(void)
 {
 qemu_register_machine(&petalogix_s3adsp1800_machine);
+machine_set_default("petalogix-s3adsp1800");
 }
 
 machine_init(petalogix_s3adsp1800_machine_init);
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index 3be0c2d..acc320a 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -446,14 +446,14 @@ static QEMUMachine core99_machine = {
 QOPT_VALUE("max_cpus", stringify(MAX_CPUS)),
 { /* end of list */ }
 },
-#ifdef TARGET_PPC64
-.is_default = 1,
-#endif
 };
 
 static void core99_machine_init(void)
 {
 qemu_register_machine(&core99_machine);
+#ifdef TARGET_PPC64
+machine_set_default("mac99");
+#endif
 }
 
 machine_init(core99_machine_init);
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 7fab893..365a2b6 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -418,14 +418,14 @@ static QEMUMachine heathrow_machine = {
 QOPT_VALUE("max_cpus", stringify(MAX_CPUS)),
 { /* end of list */ }
 },
-#ifndef TARGET_PPC64
-.is_default = 1,
-#endif
 };
 
 static void heathrow_machine_init(void)
 {
 qemu_

[Qemu-devel] [PATCH 17/22] machine: kill machine->alias

[Anthony Liguori]

Just duplicate the machine structure for now

diff --git a/hw/boards.h b/hw/boards.h
index b99dc68..a4dde9f 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -11,7 +11,6 @@ typedef void QEMUMachineInitFunc(QemuOpts *opts);
 
 struct QEMUMachine {
 const char *name;
-const char *alias;
 const char *desc;
 QEMUMachineInitFunc *init;
 QemuOptDesc *opts_desc;
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 1bb6bee..e043942 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -182,8 +182,21 @@ static QemuOptDesc pc_opts_desc[] = {
 #endif
 
 static QEMUMachine pc_machine = {
+.name = "pc",
+.desc = "Standard PC",
+.init = pc_init,
+.opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("acpi", "on"),
+QOPT_VALUE("pci", "on"),
+QOPT_VALUE("cpu", PC_DEFAULT_CPU_MODEL),
+QOPT_VALUE("max_cpus", "255"),
+{ /* end of list */ }
+},
+};
+
+static QEMUMachine pc_machine_v0_13 = {
 .name = "pc-0.13",
-.alias = "pc",
 .desc = "Standard PC",
 .init = pc_init,
 .opts_desc = pc_opts_desc,
@@ -272,6 +285,7 @@ static QEMUMachine isapc_machine = {
 static void pc_machine_init(void)
 {
 qemu_register_machine(&pc_machine);
+qemu_register_machine(&pc_machine_v0_13);
 qemu_register_machine(&pc_machine_v0_12);
 qemu_register_machine(&pc_machine_v0_11);
 qemu_register_machine(&pc_machine_v0_10);
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index 8ed4632..1650a17 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -173,8 +173,13 @@ static void bamboo_init(QemuOpts *opts)
 }
 
 static QEMUMachine bamboo_machine = {
+.name = "bamboo",
+.desc = "bamboo",
+.init = bamboo_init,
+};
+
+static QEMUMachine bamboo_machine_v0_13 = {
 .name = "bamboo-0.13",
-.alias = "bamboo",
 .desc = "bamboo",
 .init = bamboo_init,
 };
@@ -198,6 +203,7 @@ static QEMUMachine bamboo_machine_v0_12 = {
 static void bamboo_machine_init(void)
 {
 qemu_register_machine(&bamboo_machine);
+qemu_register_machine(&bamboo_machine_v0_13);
 qemu_register_machine(&bamboo_machine_v0_12);
 }
 
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 6c0f400..fd1fe52 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -269,8 +269,21 @@ static void s390_init(QemuOpts *opts)
 }
 
 static QEMUMachine s390_machine = {
+.name = "s390",
+.desc = "VirtIO based S390 machine",
+.init = s390_init,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("serial", "off"),
+QOPT_VALUE("parallel", "off"),
+QOPT_VALUE("virtcon", "on"),
+QOPT_VALUE("vga", "off"),
+QOPT_VALUE("max_cpus", "255"),
+{ /* end of list */ }
+},
+};
+
+static QEMUMachine s390_virtio_machine = {
 .name = "s390-virtio",
-.alias = "s390",
 .desc = "VirtIO based S390 machine",
 .init = s390_init,
 .opts_default = (QemuOptValue[]) {
@@ -286,7 +299,8 @@ static QEMUMachine s390_machine = {
 static void s390_machine_init(void)
 {
 qemu_register_machine(&s390_machine);
-machine_set_default("s390-virtio");
+qemu_register_machine(&s390_virtio_machine);
+machine_set_default("s390");
 }
 
 machine_init(s390_machine_init);
diff --git a/vl.c b/vl.c
index 3d49ba7..8fc89c1 100644
--- a/vl.c
+++ b/vl.c
@@ -1616,8 +1616,6 @@ static QEMUMachine *find_machine(const char *name)
 for(m = first_machine; m != NULL; m = m->next) {
 if (!strcmp(m->name, name))
 return m;
-if (m->alias && !strcmp(m->alias, name))
-return m;
 }
 return NULL;
 }
@@ -2758,13 +2756,9 @@ int main(int argc, char **argv, char **envp)
 QEMUMachine *m;
 printf("Supported machines are:\n");
 for(m = first_machine; m != NULL; m = m->next) {
-if (m->alias)
-printf("%-10s %s (alias of %s)\n",
-   m->alias, m->desc, m->name);
 printf("%-10s %s%s\n",
m->name, m->desc,
-   (!strcmp(m->name, default_machine) ||
-!strcmp(m->alias, default_machine)) ? 
+   !strcmp(m->name, default_machine) ?
" (default)" : "");
 }
 exit(0);
-- 
1.7.0.4

[Qemu-devel] [PATCH 22/22] machine: introduce -machine-def option to define a machine via config

[Anthony Liguori]

Since we have MachineCore and can represent a machine entirely via default
options, we can introduce a new option that let's us dynamically register a
machine based on those options.

For instance, we could add the following to target-x86_64.conf:

[machine-def]
 name = "pc-0.11"
 desc = "Standard PC"
 acpi = "on"
 pci = "on"
 cpu = "qemu64"
 max_cpus = "255"
 virtio-blk-pci.vectors = "0"
 virtio-serial-pci.max_nr_ports = "1"
 virtio-serial-pci.vectors = "0"
 ide-drive.ver = "0.11"
 scsi-disk.ver = "0.11"
 PCI.rombar = "0"

What's really exciting, is that a user can then define their own machines
that better suite their desires:

[kvmpc]
 name = "kvmpc"
 accel = "kvm|tcg"
 ram_size = "512M"
 max_cpus = "64"
 sockets = "16"
 default_drive = "virtio"

I'd eventually like to move all PC compatibility machines to the default
config but for now, I wanted to keep this simple.

Signed-off-by: Anthony Liguori 

diff --git a/qemu-config.c b/qemu-config.c
index a0cb34f..9b5415d 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -345,6 +345,15 @@ QemuOptsList qemu_machine_opts = {
 },
 };
 
+QemuOptsList qemu_machine_def_opts = {
+.name = "machine-def",
+.implied_opt_name = "name",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_machine_def_opts.head),
+.desc = {
+{ /* end of list */ }
+},
+};
+
 static QemuOptsList *vm_config_groups[] = {
 &qemu_drive_opts,
 &qemu_chardev_opts,
@@ -356,6 +365,7 @@ static QemuOptsList *vm_config_groups[] = {
 &qemu_mon_opts,
 &qemu_cpudef_opts,
 &qemu_machine_opts,
+&qemu_machine_def_opts,
 NULL,
 };
 
diff --git a/qemu-config.h b/qemu-config.h
index 6f52188..1b7324c 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -15,6 +15,7 @@ extern QemuOptsList qemu_global_opts;
 extern QemuOptsList qemu_mon_opts;
 extern QemuOptsList qemu_cpudef_opts;
 extern QemuOptsList qemu_machine_opts;
+extern QemuOptsList qemu_machine_def_opts;
 
 QemuOptsList *qemu_find_opts(const char *group);
 int qemu_set_option(const char *str);
diff --git a/qemu-options.hx b/qemu-options.hx
index 32fd32a..2bafe22 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -43,6 +43,14 @@ STEXI
 Select the emulated @var{machine}
 ETEXI
 
+DEF("machine-def", HAS_ARG, QEMU_OPTION_machine_def,
+"-machine-def name[,opt=val...] define a new machine\n", QEMU_ARCH_ALL)
+STEXI
+...@item -machine-def @var{name}[,@var{op...@var{val}...]
+...@findex -machine-def
+Define a new machine
+ETEXI
+
 DEF("cpu", HAS_ARG, QEMU_OPTION_cpu,
 "-cpu cpuselect CPU (-cpu ? for list)\n", QEMU_ARCH_ALL)
 STEXI
diff --git a/vl.c b/vl.c
index 150dd41..7797187 100644
--- a/vl.c
+++ b/vl.c
@@ -1683,6 +1683,59 @@ void machine_set_default(const char *name)
 default_machine = name;
 }
 
+typedef struct MachineDefineHelper
+{
+QemuOptValue *defaults;
+int length;
+int capacity;
+} MachineDefineHelper;
+
+static void helper_grow(MachineDefineHelper *helper)
+{
+if ((helper->capacity - helper->length) < 2) {
+helper->capacity += 100;
+helper->defaults = qemu_realloc(helper->defaults,
+helper->capacity * 
sizeof(QemuOptValue));
+}
+}
+
+static int machine_define_prop(const char *name, const char *value, void 
*opaque)
+{
+MachineDefineHelper *helper = opaque;
+QemuOptValue *v;
+
+if (strcmp(name, "core") == 0) {
+return 0;
+}
+
+helper_grow(helper);
+v = &helper->defaults[helper->length++];
+v->name = qemu_strdup(name);
+v->value = qemu_strdup(value);
+
+return 0;
+}
+
+static int machine_define(QemuOpts *opts, void *opaque)
+{
+MachineDefineHelper *helper;
+const char *core;
+
+core = qemu_opt_get(opts, "core");
+if (!core) {
+fprintf(stderr, "machine-def: No core specified\n");
+return -1;
+}
+
+helper = qemu_mallocz(sizeof(*helper));
+qemu_opt_foreach(opts, machine_define_prop, helper, 1);
+helper->defaults[helper->length].name = NULL;
+machine_create_from_core(core, helper->defaults);
+qemu_free(helper);
+
+return 0;
+}
+
 static Machine *find_machine(const char *name)
 {
 Machine *m;
@@ -2812,6 +2865,7 @@ int main(int argc, char **argv, char **envp)
 }
 }
 cpudef_init();
+qemu_opts_foreach(&qemu_machine_def_opts, machine_define, NULL, 1);
 
 /* second pass of option parsing */
 optind = 1;
@@ -2853,6 +2907,14 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 break;
+case QEMU_OPTION_machine_def:
+opts = qemu_opts_parse(&qemu_machine_def_opts, optarg, 1);
+if (!opts) {
+exit(1);
+}
+
+machine_define(opts, NULL);
+break;
 case QEMU_OPTION_cpu:
 /* hw initialization will check this */
 if (*optarg == '?') {
-- 
1.7.0.4

[Qemu-devel] [PATCH 20/22] machine: introduce machine core and split qemu_register_machine

[Anthony Liguori]

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 1097561..25881bb 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,18 +5,25 @@
 
 #include "qdev.h"
 
-typedef void QEMUMachineInitFunc(QemuOpts *opts);
+typedef void QEMUCoreInitFunc(QemuOpts *opts);
 
 typedef struct QEMUMachine {
-QEMUMachineInitFunc *init;
+QEMUCoreInitFunc *init;
 QemuOptDesc *opts_desc;
 QemuOptValue *opts_default;
-QTAILQ_ENTRY(QEMUMachine) node;
 } QEMUMachine;
 
 int qemu_register_machine(QEMUMachine *machine);
+
 void machine_set_default(const char *name);
 
+void machine_register_core(const char *name,
+   QEMUCoreInitFunc *init,
+   QemuOptDesc *opts_desc);
+
+int machine_create_from_core(const char *core,
+ QemuOptValue *opts_default);
+
 #define QOPT_COMPAT(driver, property, value) \
 QOPT_VALUE(driver "." property, value)
 
diff --git a/vl.c b/vl.c
index 7cb5865..150dd41 100644
--- a/vl.c
+++ b/vl.c
@@ -1590,38 +1590,105 @@ void qemu_del_wait_object(HANDLE handle, 
WaitObjectFunc *func, void *opaque)
 /***/
 /* machine registration */
 
-static QTAILQ_HEAD(, QEMUMachine) machine_list =
+typedef struct MachineCore {
+const char *name;
+QEMUCoreInitFunc *init;
+QemuOptDesc *desc;
+QTAILQ_ENTRY(MachineCore) node;
+} MachineCore;
+
+typedef struct Machine
+{
+MachineCore *core;
+QemuOptValue *defaults;
+QTAILQ_ENTRY(Machine) node;
+} Machine;
+
+static QTAILQ_HEAD(, MachineCore) machine_core_list =
+QTAILQ_HEAD_INITIALIZER(machine_core_list);
+static QTAILQ_HEAD(, Machine) machine_list =
 QTAILQ_HEAD_INITIALIZER(machine_list);
 static const char *default_machine = NULL;
 
-int qemu_register_machine(QEMUMachine *n)
+static const char *find_machine_defval(QemuOptValue *defaults, const char 
*name)
 {
-QTAILQ_INSERT_TAIL(&machine_list, n, node);
-return 0;
+int i;
+for (i = 0; defaults[i].name; i++) {
+if (!strcmp(defaults[i].name, name)) {
+return defaults[i].value;
+}
+}
+return NULL;
 }
 
-void machine_set_default(const char *name)
+void machine_register_core(const char *name,
+   QEMUCoreInitFunc *init,
+   QemuOptDesc *desc)
 {
-default_machine = name;
+MachineCore *c;
+
+c = qemu_mallocz(sizeof(*c));
+c->name = strdup(name);
+c->init = init;
+c->desc = desc;
+
+QTAILQ_INSERT_TAIL(&machine_core_list, c, node);
 }
 
-static const char *find_machine_defval(QEMUMachine *m, const char *name)
+static MachineCore *machine_core_find(const char *core)
 {
-int i;
-for (i = 0; m->opts_default[i].name; i++) {
-if (!strcmp(m->opts_default[i].name, name)) {
-return m->opts_default[i].value;
+MachineCore *c;
+
+QTAILQ_FOREACH(c, &machine_core_list, node) {
+if (strcmp(c->name, core) == 0) {
+return c;
 }
 }
+
 return NULL;
 }
 
-static QEMUMachine *find_machine(const char *name)
+int machine_create_from_core(const char *core,
+ QemuOptValue *opts_default)
+{
+MachineCore *c;
+Machine *m;
+
+c = machine_core_find(core);
+if (c == NULL) {
+return -1;
+}
+
+m = qemu_mallocz(sizeof(*m));
+m->core = c;
+m->defaults = opts_default;
+
+QTAILQ_INSERT_TAIL(&machine_list, m, node);
+
+return 0;
+}
+
+int qemu_register_machine(QEMUMachine *n)
+{
+const char *name;
+
+name = find_machine_defval(n->opts_default, "name");
+machine_register_core(name, n->init, n->opts_desc);
+
+return machine_create_from_core(name, n->opts_default);
+}
+
+void machine_set_default(const char *name)
+{
+default_machine = name;
+}
+
+static Machine *find_machine(const char *name)
 {
-QEMUMachine *m;
+Machine *m;
 
 QTAILQ_FOREACH(m, &machine_list, node) {
-const char *val = find_machine_defval(m, "name");
+const char *val = find_machine_defval(m->defaults, "name");
 if (strcmp(name, val) == 0) {
 return m;
 }
@@ -1629,7 +1696,7 @@ static QEMUMachine *find_machine(const char *name)
 return NULL;
 }
 
-static QEMUMachine *find_default_machine(void)
+static Machine *find_default_machine(void)
 {
 return find_machine(default_machine);
 }
@@ -2600,7 +2667,7 @@ static int machine_combine_opt(const char *name, const 
char *value, void *opaque
 
 static int machine_find(QemuOpts *opts, void *opaque)
 {
-QEMUMachine **machinep = opaque;
+Machine **machinep = opaque;
 const char *driver;
 
 driver = qemu_opt_get(opts, "driver");
@@ -2636,7 +2703,7 @@ int main(int argc, char **argv, char **envp)
 int optind;
 const char *optarg;
 const char *loadvm = NULL;
-QEMUMachine *machine = NULL;
+Machine *machine = NULL;
 const char *cpu_model;
 #ifndef _WIN32
 int fds[2];
@@ -2764,14 

[Qemu-devel] [PATCH 10/22] machine: allow boards to specify default values and use it in isapc

[Anthony Liguori]

Let boards describe default options.  Structuring this way is an important step
in making board definitions readable by a config file.

To use the new mechanism, introduce a pci=on|off option to the pc boards and
unify all of them into a single function.  isapc is now just another pc board
that happens to have different default values.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 0092557..06b9f73 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -26,6 +26,7 @@ struct QEMUMachine {
 int is_default;
 GlobalProperty *compat_props;
 QemuOptDesc *opts_desc;
+QemuOptValue *opts_default;
 struct QEMUMachine *next;
 };
 
diff --git a/hw/pc.c b/hw/pc.c
index 48b3730..44f5b62 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -794,15 +794,6 @@ void pc_cpus_init(const char *cpu_model)
 {
 int i;
 
-/* init CPUs */
-if (cpu_model == NULL) {
-#ifdef TARGET_X86_64
-cpu_model = "qemu64";
-#else
-cpu_model = "qemu32";
-#endif
-}
-
 for(i = 0; i < smp_cpus; i++) {
 pc_new_cpu(cpu_model);
 }
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 1830aca..0ad1145 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -40,7 +40,7 @@ static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
 static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 /* PC hardware initialisation */
-static void pc_init1(QemuOpts *opts, int pci_enabled)
+static void pc_init(QemuOpts *opts)
 {
 ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
 const char *boot_device = qemu_opt_get(opts, "boot_device");
@@ -48,6 +48,7 @@ static void pc_init1(QemuOpts *opts, int pci_enabled)
 const char *kernel_cmdline = qemu_opt_get(opts, "cmdline");
 const char *initrd_filename = qemu_opt_get(opts, "initrd");
 const char *cpu_model = qemu_opt_get(opts, "cpu");
+int pci_enabled = qemu_opt_get_bool(opts, "pci", 1);
 int i;
 ram_addr_t below_4g_mem_size, above_4g_mem_size;
 PCIBus *pci_bus;
@@ -161,45 +162,71 @@ static void pc_init1(QemuOpts *opts, int pci_enabled)
 }
 }
 
-static void pc_init_pci(QemuOpts *opts)
-{
-pc_init1(opts, 1);
-}
-
-static void pc_init_isa(QemuOpts *opts)
-{
-if (!qemu_opt_get(opts, "cpu")) {
-qemu_opt_set(opts, "cpu", "486");
-}
-
-pc_init1(opts, 0);
-}
-
 static QemuOptDesc pc_opts_desc[] = {
 COMMON_MACHINE_OPTS(),
 {
 .name = "acpi",
 .type = QEMU_OPT_BOOL,
 },
+{
+.name = "pci",
+.type = QEMU_OPT_BOOL,
+},
 { /* end of list */ },
 };
 
+#ifdef TARGET_X86_64
+#define PC_DEFAULT_CPU_MODEL "qemu64"
+#else
+#define PC_DEFAULT_CPU_MODEL "qemu32"
+#endif
+
 static QEMUMachine pc_machine = {
 .name = "pc-0.13",
 .alias = "pc",
 .desc = "Standard PC",
-.init = pc_init_pci,
+.init = pc_init,
 .max_cpus = 255,
 .is_default = 1,
 .opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+{
+.name  = "acpi",
+.value = "on",
+},
+{
+.name  = "pci",
+.value = "on",
+},
+{
+.name = "cpu",
+.value = PC_DEFAULT_CPU_MODEL,
+},
+{ /* end of list */ }
+},
 };
 
 static QEMUMachine pc_machine_v0_12 = {
 .name = "pc-0.12",
 .desc = "Standard PC",
-.init = pc_init_pci,
+.init = pc_init,
 .max_cpus = 255,
 .opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+{
+.name  = "acpi",
+.value = "on",
+},
+{
+.name  = "pci",
+.value = "on",
+},
+{
+.name = "cpu",
+.value = PC_DEFAULT_CPU_MODEL,
+},
+{ /* end of list */ }
+},
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-serial-pci",
@@ -217,9 +244,24 @@ static QEMUMachine pc_machine_v0_12 = {
 static QEMUMachine pc_machine_v0_11 = {
 .name = "pc-0.11",
 .desc = "Standard PC, qemu 0.11",
-.init = pc_init_pci,
+.init = pc_init,
 .max_cpus = 255,
 .opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+{
+.name  = "acpi",
+.value = "on",
+},
+{
+.name  = "pci",
+.value = "on",
+},
+{
+.name = "cpu",
+.value = PC_DEFAULT_CPU_MODEL,
+},
+{ /* end of list */ }
+},
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-blk-pci",
@@ -253,9 +295,24 @@ static QEMUMachine pc_machine_v0_11 = {
 static QEMUMachine pc_machine_v0_10 = {
 .name = "pc-0.10",
 .desc = "Standard PC, qemu 0.10",
-.init = pc_init_pci,
+.init = pc_init,
 .max_cpus = 255,
 .opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+{
+.name  = "acpi",
+.value = "on",
+},
+{
+.name  = "pci",
+ 

[Qemu-devel] [PATCH 06/22] Make -acpi-enable a machine specific option

[Anthony Liguori]

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index c3f4f68..728908b 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -25,6 +25,7 @@ struct QEMUMachine {
 no_sdcard:1;
 int is_default;
 GlobalProperty *compat_props;
+QemuOptDesc *opts_desc;
 struct QEMUMachine *next;
 };
 
@@ -32,4 +33,29 @@ int qemu_register_machine(QEMUMachine *m);
 
 extern QEMUMachine *current_machine;
 
+#define COMMON_MACHINE_OPTS()  \
+{   \
+.name = "ram_size", \
+.type = QEMU_OPT_SIZE,  \
+},{ \
+.name = "kernel",   \
+.type = QEMU_OPT_STRING,\
+},  \
+{   \
+.name = "cmdline",  \
+.type = QEMU_OPT_STRING,\
+},  \
+{   \
+.name = "initrd",   \
+.type = QEMU_OPT_STRING,\
+},  \
+{   \
+.name = "boot_device",  \
+.type = QEMU_OPT_STRING,\
+},  \
+{   \
+.name = "cpu",  \
+.type = QEMU_OPT_STRING,\
+}
+
 #endif
diff --git a/hw/pc.h b/hw/pc.h
index 0e52933..1ae61e0 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -110,7 +110,6 @@ typedef void (*cpu_set_smm_t)(int smm, void *arg);
 void cpu_smm_register(cpu_set_smm_t callback, void *arg);
 
 /* acpi.c */
-extern int acpi_enabled;
 extern char *acpi_tables;
 extern size_t acpi_tables_len;
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c58cd42..1830aca 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -40,14 +40,14 @@ static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 
};
 static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 /* PC hardware initialisation */
-static void pc_init1(ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename,
- const char *kernel_cmdline,
- const char *initrd_filename,
- const char *cpu_model,
- int pci_enabled)
+static void pc_init1(QemuOpts *opts, int pci_enabled)
 {
+ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
+const char *boot_device = qemu_opt_get(opts, "boot_device");
+const char *kernel_filename = qemu_opt_get(opts, "kernel");
+const char *kernel_cmdline = qemu_opt_get(opts, "cmdline");
+const char *initrd_filename = qemu_opt_get(opts, "initrd");
+const char *cpu_model = qemu_opt_get(opts, "cpu");
 int i;
 ram_addr_t below_4g_mem_size, above_4g_mem_size;
 PCIBus *pci_bus;
@@ -133,7 +133,7 @@ static void pc_init1(ram_addr_t ram_size,
 usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);
 }
 
-if (pci_enabled && acpi_enabled) {
+if (pci_enabled && qemu_opt_get_bool(opts, "acpi", 1)) {
 uint8_t *eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this 
persistent */
 i2c_bus *smbus;
 
@@ -163,32 +163,27 @@ static void pc_init1(ram_addr_t ram_size,
 
 static void pc_init_pci(QemuOpts *opts)
 {
-ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
-const char *boot_device = qemu_opt_get(opts, "boot_device");
-const char *kernel_filename = qemu_opt_get(opts, "kernel");
-const char *kernel_cmdline = qemu_opt_get(opts, "cmdline");
-const char *initrd_filename = qemu_opt_get(opts, "initrd");
-const char *cpu_model = qemu_opt_get(opts, "cpu");
-pc_init1(ram_size, boot_device,
- kernel_filename, kernel_cmdline,
- initrd_filename, cpu_model, 1);
+pc_init1(opts, 1);
 }
 
 static void pc_init_isa(QemuOpts *opts)
 {
-ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
-const char *boot_device = qemu_opt_get(opts, "boot_device");
-const char *kernel_filename = qemu_opt_get(opts, "kernel");
-const char *kernel_cmdline = qemu_opt_get(opts, "cmdline");
-const char *initrd_filename = qemu_opt_get(opts, "initrd");
-const char *cpu_model = qemu_opt_get(opts, "cpu");
-if (cpu_model == NULL)
-cpu_model = "486";
-pc_init1(ram_size, boot_device,
- kernel_filename, kernel_cmdline,
- initrd_filename, cpu_model, 0);
+if (!qemu_opt_get(opts, "cpu")) {
+qemu_opt_set(opts, "cpu", "486");
+}
+
+pc_init1(opts, 0);
 }
 
+static QemuOptDesc pc_opts_desc[] = {
+COMMON_MACHINE_OPTS(),
+{
+.name = "acpi",
+.type = QEMU_OPT_BOOL,
+},
+{ /* end of list */ },
+};
+
 static QEMUMachine pc_machine = {
 .name = "pc-0.13",
 .alias = "pc",
@@ -196,6 +191,7 @@ static QEMUMachine pc_machine = {
 .init = pc_init_pci,
 .max_cpus = 255,
 .is_default = 1,
+   

[Qemu-devel] [PATCH 13/22] machine: get rid of global default QEMUMachine members

[Anthony Liguori]

Right now, we have a lot of default device type options in the QEMUMachine
structure.  This is used by code within vl.c to determine whether it should
add classes of devices (like serial).

Really, vl.c has no business adding devices but all we need to do to support
this is create common machine options to describe whether there are default
devices of each class.  vl.c can then use that to determine whether to add
said devices.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index e05637b..f33c44b 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -16,13 +16,6 @@ struct QEMUMachine {
 QEMUMachineInitFunc *init;
 int use_scsi;
 int max_cpus;
-unsigned int no_serial:1,
-no_parallel:1,
-use_virtcon:1,
-no_vga:1,
-no_floppy:1,
-no_cdrom:1,
-no_sdcard:1;
 int is_default;
 QemuOptDesc *opts_desc;
 QemuOptValue *opts_default;
@@ -43,29 +36,46 @@ extern QEMUMachine *current_machine;
 {   \
 .name = "driver",   \
 .type = QEMU_OPT_STRING,\
-},  \
-{   \
+},{ \
 .name = "ram_size", \
 .type = QEMU_OPT_SIZE,  \
 },{ \
 .name = "kernel",   \
 .type = QEMU_OPT_STRING,\
-},  \
-{   \
+},{ \
 .name = "cmdline",  \
 .type = QEMU_OPT_STRING,\
-},  \
-{   \
+},{ \
 .name = "initrd",   \
 .type = QEMU_OPT_STRING,\
-},  \
-{   \
+},{ \
 .name = "boot_device",  \
 .type = QEMU_OPT_STRING,\
-},  \
-{   \
+},{ \
 .name = "cpu",  \
 .type = QEMU_OPT_STRING,\
+},{ \
+.name = "serial",   \
+.type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "parallel", \
+.type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "virtcon",  \
+.type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "vga",  \
+.type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "floppy",   \
+.type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "cdrom",\
+.type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "sdcard",   \
+.type = QEMU_OPT_BOOL,  \
 }
 
+
 #endif
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 70b88df..e4d6ecd 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -273,9 +273,13 @@ static QEMUMachine s390_machine = {
 .alias = "s390",
 .desc = "VirtIO based S390 machine",
 .init = s390_init,
-.no_serial = 1,
-.no_parallel = 1,
-.use_virtcon = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("serial", "off"),
+QOPT_VALUE("parallel", "off"),
+QOPT_VALUE("virtcon", "on"),
+QOPT_VALUE("vga", "off"),
+{ /* end of list */ }
+},
 .no_vga = 1,
 .max_cpus = 255,
 .is_default = 1,
diff --git a/vl.c b/vl.c
index 0a31a45..553da4d 100644
--- a/vl.c
+++ b/vl.c
@@ -3505,25 +3505,25 @@ int main(int argc, char **argv, char **envp)
 qemu_opts_foreach(&qemu_device_opts, default_driver_check, NULL, 0);
 qemu_opts_foreach(&qemu_global_opts, default_driver_check, NULL, 0);
 
-if (machine->no_serial) {
+if (!qemu_opt_get_bool(machine_opts, "serial", 1)) {
 default_serial = 0;
 }
-if (machine->no_parallel) {
+if (!qemu_opt_get_bool(machine_opts, "parallel", 1)) {
 default_parallel = 0;
 }
-if (!machine->use_virtcon) {
+if (!qemu_opt_get_bool(machine_opts, "virtcon", 0)) {
 default_virtcon = 0;
 }
-if (machine->no_vga) {
+if (!qemu_opt_get_bool(machine_opts, "vga", 1)) {
 default_vga = 0;
 }
-if (machine->no_floppy) {
+if (!qemu_opt_get_bool(machine_opts, "floppy", 1)) {
 default_floppy = 0;
 }
-if (machine->no_cdrom) {
+if (!qemu_opt_get_bool(machine_opts, "cdrom", 1)) {
 default_cdrom = 0;
 }
-if (machine->no_sdcard) {
+if (!qemu_opt_get_bool(machine_opts, "sdcard", 1))

[Qemu-devel] [PATCH 14/22] machine: replace QEMUMachine.use_scsi with -machine default_drive

[Anthony Liguori]

Some boards only support scsi and there's some ugliness to accomodate this.

This patch removes that and introduces a default_drive common option for
machines.  The absence of this option assumes ide.  It can be explicitly set
to scsi and this is used to replace all current occurrances of use_scsi.

As fall out to this patch, current_machine disappears because it's actually
not needed since we no longer access the machine state to check for use_scsi.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index f33c44b..887487e 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -14,7 +14,6 @@ struct QEMUMachine {
 const char *alias;
 const char *desc;
 QEMUMachineInitFunc *init;
-int use_scsi;
 int max_cpus;
 int is_default;
 QemuOptDesc *opts_desc;
@@ -75,6 +74,9 @@ extern QEMUMachine *current_machine;
 },{ \
 .name = "sdcard",   \
 .type = QEMU_OPT_BOOL,  \
+},{ \
+.name = "default_drive",\
+.type = QEMU_OPT_STRING,\
 }
 
 
diff --git a/hw/device-hotplug.c b/hw/device-hotplug.c
index 9cc8376..feb8aa3 100644
--- a/hw/device-hotplug.c
+++ b/hw/device-hotplug.c
@@ -38,7 +38,7 @@ DriveInfo *add_init_drive(const char *optstr)
 if (!opts)
 return NULL;
 
-dinfo = drive_init(opts, current_machine, &fatal_error);
+dinfo = drive_init(opts, NULL, &fatal_error);
 if (!dinfo) {
 qemu_opts_del(opts);
 return NULL;
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index 1ba9475..7e1e119 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -319,14 +319,20 @@ static QEMUMachine mips_magnum_machine = {
 .name = "magnum",
 .desc = "MIPS Magnum",
 .init = mips_magnum_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 };
 
 static QEMUMachine mips_pica61_machine = {
 .name = "pica61",
 .desc = "Acer Pica 61",
 .init = mips_pica61_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 };
 
 static void mips_jazz_machine_init(void)
diff --git a/hw/realview.c b/hw/realview.c
index 4364b7b..a36bdbe 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -432,14 +432,20 @@ static QEMUMachine realview_eb_machine = {
 .name = "realview-eb",
 .desc = "ARM RealView Emulation Baseboard (ARM926EJ-S)",
 .init = realview_eb_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 };
 
 static QEMUMachine realview_eb_mpcore_machine = {
 .name = "realview-eb-mpcore",
 .desc = "ARM RealView Emulation Baseboard (ARM11MPCore)",
 .init = realview_eb_mpcore_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 .max_cpus = 4,
 };
 
@@ -453,7 +459,10 @@ static QEMUMachine realview_pbx_a9_machine = {
 .name = "realview-pbx-a9",
 .desc = "ARM RealView Platform Baseboard Explore for Cortex-A9",
 .init = realview_pbx_a9_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 .max_cpus = 4,
 };
 
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 5aa3de1..a400530 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -1319,7 +1319,10 @@ static QEMUMachine ss5_machine = {
 .name = "SS-5",
 .desc = "Sun4m platform, SPARCstation 5",
 .init = ss5_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 .is_default = 1,
 };
 
@@ -1327,7 +1330,10 @@ static QEMUMachine ss10_machine = {
 .name = "SS-10",
 .desc = "Sun4m platform, SPARCstation 10",
 .init = ss10_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 .max_cpus = 4,
 };
 
@@ -1335,7 +1341,10 @@ static QEMUMachine ss600mp_machine = {
 .name = "SS-600MP",
 .desc = "Sun4m platform, SPARCserver 600MP",
 .init = ss600mp_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 .max_cpus = 4,
 };
 
@@ -1343,7 +1352,10 @@ static QEMUMachine ss20_machine = {
 .name = "SS-20",
 .desc = "Sun4m platform, SPARCstation 20",
 .init = ss20_init,
-.use_scsi = 1,
+.opts_default = (QemuOptValue[]) {
+QOPT_VALUE("default_drive", "scsi"),
+{ /* end of list */ }
+},
 .max_cpus = 4,
 };
 
@@ -1351,35 +1363,50 @@ static QEMUMachine voyager_machine = {
 .name = "Voyager",
 .desc = "Sun4m platform, SPARCsta

[Qemu-devel] [PATCH 07/22] machine: introduce -machine option

[Anthony Liguori]

This introduces a new -machine option that can be used to tweak machine specific
parameters.  One unusal feature of -machine is that there is only one machine
instance and all uses of -machine are combined together.  The last operation
to a parameter is given priority.

This let's a configuration file specify a set of default machine properties that
can then be overridden by a user.

This patch also makes -M a syntactic helper for -machine.

Signed-off-by: Anthony Liguori 

diff --git a/hw/boards.h b/hw/boards.h
index 728908b..0092557 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -35,6 +35,10 @@ extern QEMUMachine *current_machine;
 
 #define COMMON_MACHINE_OPTS()  \
 {   \
+.name = "driver",   \
+.type = QEMU_OPT_STRING,\
+},  \
+{   \
 .name = "ram_size", \
 .type = QEMU_OPT_SIZE,  \
 },{ \
diff --git a/qemu-config.c b/qemu-config.c
index 3679a9f..a0cb34f 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -338,6 +338,7 @@ QemuOptsList qemu_cpudef_opts = {
 
 QemuOptsList qemu_machine_opts = {
 .name = "machine",
+.implied_opt_name = "driver",
 .head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head),
 .desc = {
 { /* end of list */ }
diff --git a/qemu-option.c b/qemu-option.c
index b990cf5..61a2613 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -794,6 +794,27 @@ int qemu_opts_do_parse(QemuOpts *opts, const char *params, 
const char *firstname
 return 0;
 }
 
+QemuOpts *qemu_opts_parsev(QemuOptsList *list, const char *params,
+   va_list ap)
+{
+char buffer[4096];
+vsnprintf(buffer, sizeof(buffer), params, ap);
+return qemu_opts_parse(list, buffer, 0);
+}
+
+QemuOpts *qemu_opts_parsef(QemuOptsList *list, const char *params,
+   ...)
+{
+va_list ap;
+QemuOpts *opts;
+
+va_start(ap, params);
+opts = qemu_opts_parsev(list, params, ap);
+va_end(ap);
+
+return opts;
+}
+
 QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params,
   int permit_abbrev)
 {
diff --git a/qemu-option.h b/qemu-option.h
index 4a6717c..85ab58e 100644
--- a/qemu-option.h
+++ b/qemu-option.h
@@ -129,6 +129,8 @@ void qemu_opts_del(QemuOpts *opts);
 int qemu_opts_validate(QemuOpts *opts, const QemuOptDesc *desc);
 int qemu_opts_do_parse(QemuOpts *opts, const char *params, const char 
*firstname);
 QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params, int 
permit_abbrev);
+QemuOpts *qemu_opts_parsev(QemuOptsList *list, const char *params, va_list ap);
+QemuOpts *qemu_opts_parsef(QemuOptsList *list, const char *params, ...);
 QemuOpts *qemu_opts_from_qdict(QemuOptsList *list, const QDict *qdict);
 QDict *qemu_opts_to_qdict(QemuOpts *opts, QDict *qdict);
 
diff --git a/qemu-options.hx b/qemu-options.hx
index a6928b7..32fd32a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -35,6 +35,14 @@ STEXI
 Select the emulated @var{machine} (@code{-M ?} for list)
 ETEXI
 
+DEF("machine", HAS_ARG, QEMU_OPTION_machine,
+"-machine machine[,opt=val...] select emulated machine\n", QEMU_ARCH_ALL)
+STEXI
+...@item -machine @var{machine}[,@var{op...@var{val}...]
+...@findex -machine
+Select the emulated @var{machine}
+ETEXI
+
 DEF("cpu", HAS_ARG, QEMU_OPTION_cpu,
 "-cpu cpuselect CPU (-cpu ? for list)\n", QEMU_ARCH_ALL)
 STEXI
diff --git a/vl.c b/vl.c
index 4fc4c20..001adbe 100644
--- a/vl.c
+++ b/vl.c
@@ -2555,6 +2555,24 @@ static QemuOptDesc common_machine_opts[] = {
 { /* end of list */ },
 };
 
+static int machine_combine_opt(const char *name, const char *value, void 
*opaque)
+{
+QemuOpts *base_opts = opaque;
+qemu_opt_set(base_opts, name, value);
+return 0;
+}
+
+static int machine_combine_opts(QemuOpts *opts, void *opaque)
+{
+QemuOpts *base_opts = opaque;
+
+if (base_opts == opts) {
+return 0;
+}
+
+return qemu_opt_foreach(opts, machine_combine_opt, base_opts, 0);
+}
+
 int main(int argc, char **argv, char **envp)
 {
 const char *gdbstub_dev = NULL;
@@ -2571,7 +2589,7 @@ int main(int argc, char **argv, char **envp)
 int optind;
 const char *optarg;
 const char *loadvm = NULL;
-QEMUMachine *machine;
+QEMUMachine *machine = NULL;
 const char *cpu_model;
 #ifndef _WIN32
 int fds[2];
@@ -2587,6 +2605,7 @@ int main(int argc, char **argv, char **envp)
 #endif
 int show_vnc_port = 0;
 int defconfig = 1;
+QemuOpts *machine_opts = NULL;
 
 error_set_progname(argv[0]);
 
@@ -2626,7 +2645,6 @@ int main(int argc, char **argv, char **envp)
 #endif
 
 module_call_init(MODULE_INIT_MACHINE);
-machine = find_default_machine();
 cpu_model = NULL;
 initrd_filename = NULL;
 ram_size = 0;
@@ -2698,8 +2716,7 @@ int main(int argc, char **argv, char **envp)
 }
 

[Qemu-devel] [PATCH 05/22] machine: pass all init options as a single QemuOpts

[Anthony Liguori]

The current method of passing arguments to machine init functions is haphazard.
We pass some arguments as via the init function.  We pass a lot of other
arguments as global variables some that are supported by a lot of boards and
others that are only supported by one board.  It's very difficult to introduce
new parameters in the function signature because of the number of files that
have to be touched.  There is no central way to tie all of the machine options
into the configuration file.

This patch redefines the machine init signature to just take a QemuOpts.  It
also passes the machine as the first parameter to allow multiple boards to be
defined with one init function.

Signed-off-by: Anthony Liguori 

diff --git a/hw/an5206.c b/hw/an5206.c
index f584d88..0d6a6f0 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -29,11 +29,11 @@ void irq_info(Monitor *mon)
 
 /* Board init.  */
 
-static void an5206_init(ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
+static void an5206_init(QemuOpts *opts)
 {
+ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
+const char *kernel_filename = qemu_opt_get(opts, "kernel");
+const char *cpu_model = qemu_opt_get(opts, "cpu");
 CPUState *env;
 int kernel_size;
 uint64_t elf_entry;
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index 7d59c96..7999d47 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -264,11 +264,12 @@ static uint64_t translate_kernel_address(void *opaque, 
uint64_t addr)
 }
 
 static
-void axisdev88_init (ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
+void axisdev88_init (QemuOpts *opts)
 {
+ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
+const char *kernel_filename = qemu_opt_get(opts, "kernel");
+const char *kernel_cmdline = qemu_opt_get(opts, "cmdline");
+const char *cpu_model = qemu_opt_get(opts, "cpu");
 CPUState *env;
 DeviceState *dev;
 SysBusDevice *s;
diff --git a/hw/boards.h b/hw/boards.h
index 6f0f0d7..c3f4f68 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,14 +5,11 @@
 
 #include "qdev.h"
 
-typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename,
- const char *kernel_cmdline,
- const char *initrd_filename,
- const char *cpu_model);
-
-typedef struct QEMUMachine {
+typedef struct QEMUMachine QEMUMachine;
+
+typedef void QEMUMachineInitFunc(QemuOpts *opts);
+
+struct QEMUMachine {
 const char *name;
 const char *alias;
 const char *desc;
@@ -29,7 +26,7 @@ typedef struct QEMUMachine {
 int is_default;
 GlobalProperty *compat_props;
 struct QEMUMachine *next;
-} QEMUMachine;
+};
 
 int qemu_register_machine(QEMUMachine *m);
 
diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
index 9c9e6ff..db94251 100644
--- a/hw/dummy_m68k.c
+++ b/hw/dummy_m68k.c
@@ -16,11 +16,11 @@
 
 /* Board init.  */
 
-static void dummy_m68k_init(ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
+static void dummy_m68k_init(QemuOpts *opts)
 {
+ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
+const char *kernel_filename = qemu_opt_get(opts, "kernel");
+const char *cpu_model = qemu_opt_get(opts, "cpu");
 CPUState *env;
 int kernel_size;
 uint64_t elf_entry;
diff --git a/hw/etraxfs.c b/hw/etraxfs.c
index b88d00a..1cb6052 100644
--- a/hw/etraxfs.c
+++ b/hw/etraxfs.c
@@ -50,11 +50,12 @@ static uint64_t translate_kernel_address(void *opaque, 
uint64_t addr)
 }
 
 static
-void bareetraxfs_init (ram_addr_t ram_size,
-   const char *boot_device,
-   const char *kernel_filename, const char *kernel_cmdline,
-   const char *initrd_filename, const char *cpu_model)
+void bareetraxfs_init (QemuOpts *opts)
 {
+ram_addr_t ram_size = qemu_opt_get_size(opts, "ram_size", 0);
+const char *kernel_filename = qemu_opt_get(opts, "kernel");
+const char *kernel_cmdline = qemu_opt_get(opts, "cmdline");
+const char *cpu_model = qemu_opt_get(opts, "cpu");
 DeviceState *dev;
 SysBusDevice *s;
 CPUState *env;
diff --git a/hw/gumstix.c b/hw/gumstix.c
index b64e04e..6739332 100644
--- a/hw/gumstix.c
+++ b/hw/gumstix.c
@@ -41,10 +41,7 @@
 
 static const int sector_len = 128 * 1024;
 
-static void connex_init(ram_addr_t ram_size,
-const char *boot_device

[Qemu-devel] [PATCH 08/22] machine: implement -kernel/-append/-initrd options in term of -machine

[Anthony Liguori]

Signed-off-by: Anthony Liguori 

diff --git a/vl.c b/vl.c
index 001adbe..4553648 100644
--- a/vl.c
+++ b/vl.c
@@ -2577,10 +2577,8 @@ int main(int argc, char **argv, char **envp)
 {
 const char *gdbstub_dev = NULL;
 int i;
-int snapshot, linux_boot;
+int snapshot;
 const char *icount_option = NULL;
-const char *initrd_filename;
-const char *kernel_filename, *kernel_cmdline;
 char boot_devices[33] = "cad"; /* default to HD->floppy->CD-ROM */
 DisplayState *ds;
 DisplayChangeListener *dcl;
@@ -2646,11 +2644,8 @@ int main(int argc, char **argv, char **envp)
 
 module_call_init(MODULE_INIT_MACHINE);
 cpu_model = NULL;
-initrd_filename = NULL;
 ram_size = 0;
 snapshot = 0;
-kernel_filename = NULL;
-kernel_cmdline = "";
 cyls = heads = secs = 0;
 translation = BIOS_ATA_TRANSLATION_AUTO;
 
@@ -2746,7 +2741,7 @@ int main(int argc, char **argv, char **envp)
 }
 break;
 case QEMU_OPTION_initrd:
-initrd_filename = optarg;
+qemu_opts_parsef(&qemu_machine_opts, "initrd=%s", optarg);
 break;
 case QEMU_OPTION_hda:
 if (cyls == 0)
@@ -2856,10 +2851,10 @@ int main(int argc, char **argv, char **envp)
 graphic_rotate = 1;
 break;
 case QEMU_OPTION_kernel:
-kernel_filename = optarg;
+qemu_opts_parsef(&qemu_machine_opts, "kernel=%s", optarg);
 break;
 case QEMU_OPTION_append:
-kernel_cmdline = optarg;
+qemu_opts_parsef(&qemu_machine_opts, "cmdline=%s", optarg);
 break;
 case QEMU_OPTION_cdrom:
 drive_add(optarg, CDROM_ALIAS);
@@ -3629,17 +3624,6 @@ int main(int argc, char **argv, char **envp)
 fprintf(stderr, "qemu_init_main_loop failed\n");
 exit(1);
 }
-linux_boot = (kernel_filename != NULL);
-
-if (!linux_boot && *kernel_cmdline != '\0') {
-fprintf(stderr, "-append only allowed with -kernel option\n");
-exit(1);
-}
-
-if (!linux_boot && initrd_filename != NULL) {
-fprintf(stderr, "-initrd only allowed with -kernel option\n");
-exit(1);
-}
 
 #ifndef _WIN32
 /* Win32 doesn't support line-buffering and requires size >= 2 */
@@ -3766,16 +3750,6 @@ int main(int argc, char **argv, char **envp)
 }
 qemu_add_globals();
 
-if (kernel_filename) {
-qemu_opt_set(machine_opts, "kernel", kernel_filename);
-if (kernel_cmdline) {
-qemu_opt_set(machine_opts, "cmdline", kernel_cmdline);
-}
-if (initrd_filename) {
-qemu_opt_set(machine_opts, "initrd", initrd_filename);
-}
-}
-
 qemu_opt_set(machine_opts, "boot_device", boot_devices);
 
 if (cpu_model) {
-- 
1.7.0.4

[Qemu-devel] [PATCH 04/22] machine: package all init arguments into a QemuOpts (v2)

[Anthony Liguori]

This patch creates a QemuOpts structure and stores all of the machine init
arguments in that structure.  It introduces a temporary list of QemuOptDescs
in vl.c such that the current common options can be validated.

The long term vision is that that list becomes a #define and that each machine
can optionally provide it's own QemuOptDescs list using the common options as
a base.  This enables per-machine options.

Signed-off-by: Anthony Liguori 
--
v1 -> v2:
  - cpu_model -> cpu

diff --git a/hw/pc.c b/hw/pc.c
index 9b85c42..48b3730 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -534,6 +534,10 @@ static void load_linux(void *fw_cfg,
 FILE *f;
 char *vmode;
 
+if (!kernel_cmdline) {
+kernel_cmdline = "";
+}
+
 /* Align to 16 bytes as a paranoia measure */
 cmdline_size = (strlen(kernel_cmdline)+16) & ~15;
 
diff --git a/qemu-config.c b/qemu-config.c
index 5a4e61b..3679a9f 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -336,6 +336,14 @@ QemuOptsList qemu_cpudef_opts = {
 },
 };
 
+QemuOptsList qemu_machine_opts = {
+.name = "machine",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head),
+.desc = {
+{ /* end of list */ }
+},
+};
+
 static QemuOptsList *vm_config_groups[] = {
 &qemu_drive_opts,
 &qemu_chardev_opts,
@@ -346,6 +354,7 @@ static QemuOptsList *vm_config_groups[] = {
 &qemu_global_opts,
 &qemu_mon_opts,
 &qemu_cpudef_opts,
+&qemu_machine_opts,
 NULL,
 };
 
diff --git a/qemu-config.h b/qemu-config.h
index dca69d4..6f52188 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -14,6 +14,7 @@ extern QemuOptsList qemu_rtc_opts;
 extern QemuOptsList qemu_global_opts;
 extern QemuOptsList qemu_mon_opts;
 extern QemuOptsList qemu_cpudef_opts;
+extern QemuOptsList qemu_machine_opts;
 
 QemuOptsList *qemu_find_opts(const char *group);
 int qemu_set_option(const char *str);
diff --git a/vl.c b/vl.c
index 7121cd0..5349fd5 100644
--- a/vl.c
+++ b/vl.c
@@ -2550,6 +2550,35 @@ static const QEMUOption *lookup_opt(int argc, char 
**argv,
 return popt;
 }
 
+/* TEMP: until we have proper -machine support */
+static QemuOptDesc common_machine_opts[] = {
+{
+.name = "ram_size",
+.type = QEMU_OPT_SIZE,
+},
+{
+.name = "kernel",
+.type = QEMU_OPT_STRING,
+},
+{
+.name = "cmdline",
+.type = QEMU_OPT_STRING,
+},
+{
+.name = "initrd",
+.type = QEMU_OPT_STRING,
+},
+{
+.name = "boot_device",
+.type = QEMU_OPT_STRING,
+},
+{
+.name = "cpu",
+.type = QEMU_OPT_STRING,
+},
+{ /* end of list */ },
+};
+
 int main(int argc, char **argv, char **envp)
 {
 const char *gdbstub_dev = NULL;
@@ -3718,8 +3747,42 @@ int main(int argc, char **argv, char **envp)
 }
 qemu_add_globals();
 
-machine->init(ram_size, boot_devices,
-  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
+opts = qemu_opts_create(&qemu_machine_opts, NULL, 0);
+if (kernel_filename) {
+qemu_opt_set(opts, "kernel", kernel_filename);
+if (kernel_cmdline) {
+qemu_opt_set(opts, "cmdline", kernel_cmdline);
+}
+if (initrd_filename) {
+qemu_opt_set(opts, "initrd", initrd_filename);
+}
+}
+
+qemu_opt_set(opts, "boot_device", boot_devices);
+
+if (cpu_model) {
+qemu_opt_set(opts, "cpu", cpu_model);
+}
+
+if (ram_size) {
+char buffer[64];
+snprintf(buffer, sizeof(buffer),
+ "%" PRId64, ram_size);
+qemu_opt_set(opts, "ram_size", buffer);
+}
+
+if (qemu_opts_validate(opts, common_machine_opts) < 0) {
+exit(1);
+}
+
+machine->init(qemu_opt_get_size(opts, "ram_size"),
+  qemu_opt_get(opts, "boot_device"),
+  qemu_opt_get(opts, "kernel"),
+  qemu_opt_get(opts, "cmdline"),
+  qemu_opt_get(opts, "initrd"),
+  qemu_opt_get(opts, "cpu"));
+
+qemu_opts_del(opts);
 
 cpu_synchronize_all_post_init();
 
-- 
1.7.0.4

[Qemu-devel] [PATCH 09/22] machine: implement -m in terms of -machine

[Anthony Liguori]

Signed-off-by: Anthony Liguori 

diff --git a/vl.c b/vl.c
index 4553648..398d3b4 100644
--- a/vl.c
+++ b/vl.c
@@ -2968,35 +2968,14 @@ int main(int argc, char **argv, char **envp)
 version();
 exit(0);
 break;
-case QEMU_OPTION_m: {
-uint64_t value;
-char *ptr;
-
-value = strtoul(optarg, &ptr, 10);
-switch (*ptr) {
-case 0: case 'M': case 'm':
-value <<= 20;
-break;
-case 'G': case 'g':
-value <<= 30;
-break;
-default:
-fprintf(stderr, "qemu: invalid ram size: %s\n", optarg);
-exit(1);
-}
-
-/* On 32-bit hosts, QEMU is limited by virtual address space */
-if (value > (2047 << 20) && HOST_LONG_BITS == 32) {
-fprintf(stderr, "qemu: at most 2047 MB RAM can be 
simulated\n");
-exit(1);
-}
-if (value != (uint64_t)(ram_addr_t)value) {
-fprintf(stderr, "qemu: ram size too large\n");
-exit(1);
+case QEMU_OPTION_m:
+/* Default to 'M' which is not the normal behavior */
+if (*optarg && isdigit(optarg[strlen(optarg) - 1])) {
+qemu_opts_parsef(&qemu_machine_opts, "ram_size=%sM", 
optarg);
+} else {
+qemu_opts_parsef(&qemu_machine_opts, "ram_size=%s", 
optarg);
 }
-ram_size = value;
 break;
-}
 case QEMU_OPTION_mempath:
 mem_path = optarg;
 break;
@@ -3645,8 +3624,26 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 
 /* init the memory */
-if (ram_size == 0)
-ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
+ram_size = qemu_opt_get_size(machine_opts, "ram_size", 
+ DEFAULT_RAM_SIZE * 1024 * 1024);
+
+
+if (!qemu_opt_get(machine_opts, "ram_size")) {
+char buffer[64];
+snprintf(buffer, sizeof(buffer), "%" PRId64, ram_size);
+qemu_opt_set(machine_opts, "ram_size", buffer);
+}
+
+/* On 32-bit hosts, QEMU is limited by virtual address space */
+if (ram_size > (2047 << 20) && HOST_LONG_BITS == 32) {
+fprintf(stderr, "qemu: at most 2047 MB RAM can be simulated\n");
+exit(1);
+}
+
+if (ram_size != (uint64_t)(ram_addr_t)ram_size) {
+fprintf(stderr, "qemu: ram size too large\n");
+exit(1);
+}
 
 /* init the dynamic translator */
 cpu_exec_init_all(tb_size * 1024 * 1024);
-- 
1.7.0.4

[Qemu-devel] [PATCH 02/22] QemuOpts: make qemu_opts_validate() store the description list for later use

[Anthony Liguori]

Otherwise qemu_opt_set doesn't work as expected after a validate call

Signed-off-by: Anthony Liguori 

diff --git a/qemu-option.c b/qemu-option.c
index e0cb91b..03b1ef7 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -525,6 +525,7 @@ struct QemuOpt {
 struct QemuOpts {
 char *id;
 QemuOptsList *list;
+const QemuOptDesc *secondary_desc;
 Location loc;
 QTAILQ_HEAD(QemuOptHead, QemuOpt) head;
 QTAILQ_ENTRY(QemuOpts) next;
@@ -611,6 +612,10 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const 
char *value)
 const QemuOptDesc *desc = opts->list->desc;
 int i;
 
+if (desc[0].name == NULL && opts->secondary_desc) {
+desc = opts->secondary_desc;
+}
+
 for (i = 0; desc[i].name != NULL; i++) {
 if (strcmp(desc[i].name, name) == 0) {
 break;
@@ -927,6 +932,8 @@ int qemu_opts_validate(QemuOpts *opts, const QemuOptDesc 
*desc)
 }
 }
 
+opts->secondary_desc = desc;
+
 return 0;
 }
 
-- 
1.7.0.4

[Qemu-devel] [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice

[Anthony Liguori]

Right now, if you set a QemuOpts option in a section twice, when you get the
option you'll receive the value that was set the first time.  This is less than
ideal because if you're manipulating options in two places like a global config
followed by the command line, you really want the later to override the former.

This patch fixes this behavior.

Signed-off-by: Anthony Liguori 

diff --git a/qemu-option.c b/qemu-option.c
index acd74f9..e0cb91b 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -628,7 +628,7 @@ int qemu_opt_set(QemuOpts *opts, const char *name, const 
char *value)
 opt = qemu_mallocz(sizeof(*opt));
 opt->name = qemu_strdup(name);
 opt->opts = opts;
-QTAILQ_INSERT_TAIL(&opts->head, opt, next);
+QTAILQ_INSERT_HEAD(&opts->head, opt, next);
 if (desc[i].name != NULL) {
 opt->desc = desc+i;
 }
-- 
1.7.0.4

[Qemu-devel] [PATCH 0/22] Refactor machine support

[Anthony Liguori]

This series introduces a rather radical change in the way we deal with machine
definitions in QEMU.  Here are the features this series introduces:

 - Machines are definable via a -machine-def option or a [machine-def] config
   stanza
 - Parameters such as -kernel, -initrd, -append, -m, -acpi-enable, -enable-kvm,
   and potentially many more are now support via a config
 - It's possible to set a default block format (ide, scsi, virtio) for a machine
 - It's possible to make kvm enablement a property of a machine type.  The
   support modes are KVM enabled, TCG enabled, and KVM enabled with TCG
   fallback.
 - All properties of the default machine type are overridable via global config.
   IOW, you can make KVM enablement default without touching the source code.
   You can also increase the default ram size without touching any code.

Conceptually, it works by introducing a MachineCore concept.  A MachineCore is
a function that is able to create a machine based on a set of user specified
parameters.  These parameters may be high level properties (like ram size) or
qdev global properties (virtio-blk-pci.vectors).

A builtin Machine is an instance of a MachineCore that has a set of default
parameters set.

The concept of MachineCore is *not* a stop-gap measure for proper qdev
conversion.  Rather, the idea behind MachineCore is that it's a device tree
builder.

You certainly could still have a machine described purely by a device tree and
qdev properties but that's not enough to represent the UI that we currently
expose.  We need a way convert user visible operations like enable usb to
platform specific operations like add a PIIX3 USB hub.  This is what a
MachineCore does.

[Qemu-devel] [PATCH 03/22] QemuOpts: add function to set QemuOpts from defaults

[Anthony Liguori]

This lets us hard code a list of default QemuOpts values in a structured way.

Signed-off-by: Anthony Liguori 

diff --git a/qemu-option.c b/qemu-option.c
index 03b1ef7..b990cf5 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -954,3 +954,23 @@ int qemu_opts_foreach(QemuOptsList *list, 
qemu_opts_loopfunc func, void *opaque,
 loc_pop(&loc);
 return rc;
 }
+
+int qemu_opts_set_defaults(QemuOpts *opts, const QemuOptValue *defvals)
+{
+int i;
+
+for (i = 0; defvals[i].name; i++) {
+int ret;
+
+if (qemu_opt_get(opts, defvals[i].name)) {
+continue;
+}
+
+ret = qemu_opt_set(opts, defvals[i].name, defvals[i].value);
+if (ret < 0) {
+return ret;
+}
+}
+
+return 0;
+}
diff --git a/qemu-option.h b/qemu-option.h
index 4823219..4a6717c 100644
--- a/qemu-option.h
+++ b/qemu-option.h
@@ -104,6 +104,11 @@ struct QemuOptsList {
 QemuOptDesc desc[];
 };
 
+typedef struct QemuOptValue {
+const char *name;
+const char *value;
+} QemuOptValue;
+
 const char *qemu_opt_get(QemuOpts *opts, const char *name);
 int qemu_opt_get_bool(QemuOpts *opts, const char *name, int defval);
 uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t 
defval);
@@ -113,6 +118,8 @@ typedef int (*qemu_opt_loopfunc)(const char *name, const 
char *value, void *opaq
 int qemu_opt_foreach(QemuOpts *opts, qemu_opt_loopfunc func, void *opaque,
  int abort_on_failure);
 
+int qemu_opts_set_defaults(QemuOpts *opts, const QemuOptValue *defvals);
+
 QemuOpts *qemu_opts_find(QemuOptsList *list, const char *id);
 QemuOpts *qemu_opts_create(QemuOptsList *list, const char *id, int 
fail_if_exists);
 int qemu_opts_set(QemuOptsList *list, const char *id,
-- 
1.7.0.4

Re: [Qemu-devel] Getting tcg in a standalone library

[Alexander Graf]

On 07.06.2010, at 23:27, Peter Fritzsche wrote:

> Hi,
> 
> I am currently quite interesting in tcg for binary translation. There are 
> many 
> emulator projects (I mean mostly console emulators) out there which start to 
> implement more or less bad ILs to translate their specific cpu (for example 
> gameboy has z80, n64 has r4300i, gamecube has powerpc 750CXe, ...). These are 
> most of the time x86 only and very limited. But it seems that qemu's cpu 
> libraries aren't made for those cpu's and don't seem to provide the needed 
> infrastructure for emulating such highly integrated systems (please correct 
> me 
> if I am wrong).

The old stuff is pretty tough, as it's timing critical. Everything as of the GC 
should be fairly easy to emulate using tcg though, as you can just count the 
overall emulated instructions and throttle it lazily from there. That's 
basically what Dolphin does too.

For the 750CXe all that's left to do is to emulate the paired single 
instructions. And I have a full emulation of those in the KVM code already, so 
you could take it from there.

> I think that the best way to share code would be if other projects could also 
> use tcg for their translation needs. But it seems to me that it it to tightly 
> integrated into qemu and cannot be ripped out. Are their any plans to open it 
> for other projects as you have already done it with the emulation cores?

Yes, I agree. That would indeed be useful. Patches are welcome.


Alex

[Qemu-devel] Re: KVM call agenda for June 8

[Anthony Liguori]

On 06/07/2010 05:26 PM, Chris Wright wrote:

Please send in any agenda items you are interested in covering.

If we have a lack of agenda items I'll cancel the week's call.

   


- Accelerating counters (aka moving PIT to userspace, keeping HPET in 
userspace)

- Live migration + hotplug

Regards,

Anthony Liguori


thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
   

[Qemu-devel] KVM call agenda for June 8

[Chris Wright]

Please send in any agenda items you are interested in covering.

If we have a lack of agenda items I'll cancel the week's call.

thanks,
-chris

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Anthony Liguori]

On 06/07/2010 01:42 PM, Avi Kivity wrote:

On 06/07/2010 08:04 PM, Anthony Liguori wrote:


I think we could also move the local APIC.


I'm not even sure we can safely move the ioapic/pic (mostly due to 
churn).  But the local APIC is so heavily accessed by the guest that 
it's impossible to move it.  Run an ftrace one day, especially on an 
smp guest.  Every IPI requires several APIC accesses.  Before a halt a 
tickless kernel sets the wakeup timer.  EOIs.




To optimize device models, we've tended to put the full device model 
in the kernel whereas the hardware vendors have tended to put only 
the fast paths of the devices models in hardware.


For instance, we could introduce a userspace interface similar to 
vapic support whereas a shared page that mapped the APIC's layout was 
used with a mask to select which registers trapped on read/write.


That leads to very problematic interfaces.  When you separate along a 
device boundary, you have a spec that defines the software 
interfaces.  When you separate along a boundary that you define, it's 
up to you to get everything right.


In fact with the ioapic/pic/lapic one of the problems is that the 
interconnection between the devices that is not well defined, and 
that's where we have bugs.




That said, I can understand an argument that the local APIC is part 
of the CPU state since it's a very special type of device.


A better example would be a generic counter kernel mechanism.  I can 
envision such a device as doing nothing more than providing a 
read-only view of a counter with a userspace configurable divider and 
width.  Any write to the counter or read of any other byte outside 
the counter register would result in a trap to userspace.


What about latches?  byte access to word registers?  There will be as 
many special cases as there are timers.


If the kernel supported a bytecode/jit facility I'd happily use that 
to download portions of the device model into the kernel.




That should allow both the PIT and the HPET to be accelerated with 
minimal effort in the kernel.


IMO it's probably more effort than porting HPET to the kernel.  Try 
outlining an interface that supports PIT, HPET, RTC, and ACPI PMTIMER.


I was referring specifically to time sources, not time events.

An accelerated counter for HPET is pretty trivial.  It's a 32-bit 
register that's actually a nanosecond value in qemu.  We need to be able 
to set an offset from the host wall clock time, a means to stop it, and 
a means to start it.


The PIT is latched so the kernel needs to know enough about how to 
decode the PIT state to understand the latching.  There's very little 
state associated with latching though so I don't think this is a huge 
problem.  It's a fixed value write to a fixed register followed by a 
read to a fixed register.  The act of latching doesn't effect the state 
beyond the fact that you need to save the latched value in the event 
that you have a live migration before reading the latched value.


The PMTIMER is also pretty straight forward.  It's a variable port 
address (that's fixed during execution).


Even if we require three separate interfaces, the interfaces are so 
simply that it seems like an obvious win.




I'd be in favor of a straight port to userspace.  We already have the 
interfaces to communicate with an external device model for these 
devices so let's just take the kernel code and stick it into 
dedicated threads in userspace.


Currently we support an all-or-nothing approach.  I don't think local 
APIC in userspace is worthwhile.  Esp. as it will slow down vhost and 
assigned devices significantly - interrupts will have to be mediated 
by userspace.


Yeah, as I said, I can understand the arguments for keeping the lapic in 
the kernel.




I think it's easier to then work to merge the two bits of code in the 
same tree than it is to try and take out-of-tree code and merge it 
incrementally.


Are you talking about qemu.git/qemu-kvm.git?  That's the least of my 
concerns, I'm worried about kvm.git.


qemu.git.




5. Risk

We may find out after all this is implemented that performance is 
not acceptable and all the work will have to be dropped.


That's another advantage to a straight port to userspace.  We can 
collect performance data with only a modest amount of engineering 
effort.


Port what exactly?  We have a userspace irqchip implementation.  What 
we don't have is just the ioapic/pic/pit in userspace, and the only 
way to try it out is to implement the whole thing.


If you take the kernel code and do a pretty straight port: switching 
kernel functions to libc functions and maintaining all the existing 
locking via pthreads, you could then implement a very simple MMIO/PIO 
dispatch mechanism in the kvm code that shortcutted those devices before 
we ever hit the qemu_mutex and the traditional qemu code paths.  It 
should be a relatively easy conversion and it gives a proper vehicle for 
doing experimentations.


In fact, 

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Anthony Liguori]

On 06/07/2010 04:37 PM, Anthony Liguori wrote:

On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote:

On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote:

On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:

So I see two ways to go forward: switch default value in my patch,
or disable vlans unconditionally.


The problem with disabling vlans unconditionally is that you break -net
socket and -net dump.

If we can come up with an alternative way to do these things, I'm all
for removing it.

Hmm, I'll try to look at supporting -net socket in netdev.
Does -net dump do anything that can't be done with tap+tcpdump?


tap+tcpdump requires root privileges (even if you have a tap helper).

Plus tcpdump doesn't help with slirp and -net dump is very useful for 
debugging slirp.


Of course, you could add this functionality to netdev.  It's arguably 
better there too because then you can debug virtio-net+tap with full 
offload enabled (which you cannot do today).


Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH v3 00/17] clean up vl.c code

[Juan Quintela]

jes.soren...@redhat.com wrote:
> From: Jes Sorensen 
>
> Hi,
>
> Ok third time lucky ... I hope! This fixes the missing git add on
> qemu-options.h as building for win32 using mingw (thanks Paolo!).
>
> The patches try to clean up the vl.c code by separating out OS
> specific code into OS specific files. Basically it is focused on
> moving things into os-posix.c for most UNIX/Linux systems, and
> os-win32.c for win32 specific bits.
>
> I have tried to be as careful as I can to not break non Linux support,
> but so far the patch has only been tested on Linux.
>
> Oh and this time without 'I am not very clever' editor backup files!
>
> Thanks,
> Jes

Acked-by: Juan Quintela 

Nice, thanks.  Once there, perhaps you want to look about moving osdep.c
definitions to os-{posix,win32}.c.  And no, that file is not nice
either.

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Anthony Liguori]

On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote:

On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote:
   

On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:
 

So I see two ways to go forward: switch default value in my patch,
or disable vlans unconditionally.

   

The problem with disabling vlans unconditionally is that you break -net
socket and -net dump.

If we can come up with an alternative way to do these things, I'm all
for removing it.
 

Hmm, I'll try to look at supporting -net socket in netdev.
Does -net dump do anything that can't be done with tap+tcpdump?
   


tap+tcpdump requires root privileges (even if you have a tap helper).

Plus tcpdump doesn't help with slirp and -net dump is very useful for 
debugging slirp.


Regards,

Anthony Liguroi


Regards,

Anthony Liguori

 

Which will it be?


   

Paul



   

[Qemu-devel] Getting tcg in a standalone library

[Peter Fritzsche]

Hi,

I am currently quite interesting in tcg for binary translation. There are many 
emulator projects (I mean mostly console emulators) out there which start to 
implement more or less bad ILs to translate their specific cpu (for example 
gameboy has z80, n64 has r4300i, gamecube has powerpc 750CXe, ...). These are 
most of the time x86 only and very limited. But it seems that qemu's cpu 
libraries aren't made for those cpu's and don't seem to provide the needed 
infrastructure for emulating such highly integrated systems (please correct me 
if I am wrong).

I think that the best way to share code would be if other projects could also 
use tcg for their translation needs. But it seems to me that it it to tightly 
integrated into qemu and cannot be ripped out. Are their any plans to open it 
for other projects as you have already done it with the emulation cores?

Best regards,
Peter

Re: [Qemu-devel] Build problem on Mac OS 10.6.3

[Andreas Färber]

Am 07.06.2010 um 21:00 schrieb Programmingkid:


This is how I configured Qemu:

./configure --enable-cocoa --target-list=x86-softmmu

One thing I did notice is this message at the end of the configure  
output:


Unsupported target CPU


It's either x86_64-softmmu or i386-softmmu.

HTH,

Andreas

[Qemu-devel] Live Migration of 32-bit Linux guest broken since 2.6.32-rc2

[Peter Lieven]

Hi,

I freshly installed kernel 2.6.32-rc2 using userspace qemu-kvm 0.12.4.

When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
the following error after the mem transfer has finished:

kvm: unhandled exit 8022
kvm: kvm_run returned -22

cmdline:
/usr/bin/qemu-kvm-0.12.4  -net none  -drive 
format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native
  -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 'opensuse-11.2-i586'  
-boot order=dc,menu=on  -k de  -incoming tcp:172.21.55.20:5003  -pidfile 
/var/run/qemu/vm-154.pid  -mem-path /hugepages -mem-prealloc  -rtc base=utc 
-usb -usbdevice tablet -cpu qemu64,model_id='Intel(R) Xeon(R) CPU   
E5430  @ 2.66GHz'

Migrating the same VM worked with 2.6.34 kvm module.

Thanks,
Peter

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Michael S. Tsirkin]

On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote:
> On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:
>>
>> So I see two ways to go forward: switch default value in my patch,
>> or disable vlans unconditionally.
>>
>
> The problem with disabling vlans unconditionally is that you break -net  
> socket and -net dump.
>
> If we can come up with an alternative way to do these things, I'm all  
> for removing it.

Hmm, I'll try to look at supporting -net socket in netdev.
Does -net dump do anything that can't be done with tap+tcpdump?

> Regards,
>
> Anthony Liguori
>
>> Which will it be?
>>
>>
 Paul

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Anthony Liguori]

On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote:


So I see two ways to go forward: switch default value in my patch,
or disable vlans unconditionally.
   


The problem with disabling vlans unconditionally is that you break -net 
socket and -net dump.


If we can come up with an alternative way to do these things, I'm all 
for removing it.


Regards,

Anthony Liguori


Which will it be?

   

Paul


   

Re: [Qemu-devel] Re: [RFC] QMP: Introduce query-netdevices documentation

[Miguel Di Ciurcio Filho]

On Mon, Jun 7, 2010 at 12:01 PM, Markus Armbruster  wrote:
>>          {
>>             "device": "user.0",
>>             "type": "user",
>>             "info": {
>>                "net": "10.0.2.0",
>>                "netmask": "255.255.255.0"
>>             },
>>          },
>
> And this one's not connected to a VLAN.  It may or may not be connected
> to a single guest device.  If it is, then that device has a "netdev"
> property pointing to it.
>
> For what it's worth, "info network" shows that device as "peer=ID".

Yes, this information is important. Should I name it 'peer' or
'netdev'? I think 'peer' would be better, because the name 'netdev'
points to 'backend network device' IMHO.

Will it be better stored in the 'info' object or the device object? I
think it should go into the device object. There will be vlan or peer
or none of them in case the netdev is just there doing nothing (odd,
but still).

  {
 "device": "user.0",
 "type": "user",
 "peer": "e1000.0";
 "info": {
"net": "10.0.2.0",
"netmask": "255.255.255.0"
 },
  },

Regards,

Miguel

Re: [Qemu-devel] [PATCH 2/2] tcg-i386: Use segment registers to implement GUEST_BASE.

[Richard Henderson]

On 06/03/2010 11:35 PM, Alexander Graf wrote:
> 
> On 04.06.2010, at 02:35, Richard Henderson wrote:
> 
>> For 32-bit, using a segment override is smaller than the 4-byte 
>> immediate offset.  For 64-bit, segments can hold the entire 64-bit 
>> offset whereas the 4-byte immediate cannot.
> 
> Very nice idea indeed :). Have you found it to be faster? IIRC
> segment accesses are slower when seg_offs != 0. But then again the
> code is smaller, so it might weigh it up.

I've not yet tried to do any proper benchmarking.

I had thought that the segment access was slower only when limit != 4G,
i.e. when the segment boundaries need to be checked.  And that 64-bit
segments don't have boundaries, so the slowdown does not apply there either.

I'll put it on my queue for the weekend.


r~

[Qemu-devel] Re: [RFC] QMP: Introduce query-netdevices documentation

[Miguel Di Ciurcio Filho]

On Mon, Jun 7, 2010 at 11:48 AM, Anthony Liguori  wrote:
>>
>> How about this small draft:
>>
>> Possible values for "type": tap, user, vde and socket. The 'info'
>> object contains all the parameters available via -netdev type,args.
>>
>> Notice: vlan is still there, unless the support for it is removed, IMHO.
>>
>
> 'id' is missing.  Really, s/device/id/ is probably the right thing to do.
>

Following this logic, shouldn't query-block do the same?

-> { "execute": "query-block" }
<- {
  "return":[
 {
"device":"ide0-hd0",
"locked":false,
"removable":false,
"inserted":{
   "ro":false,
   "drv":"qcow2",
   "encrypted":false,
   "file":"disks/test.img"
},
"type":"hd"
 },

I actually decided to use 'device' after looking at query-block, to
keep things more uniform. I'm just an student :-D

> vlan's are a totally separate concept.  info netdev shouldn't return vlan
> devices IMHO.  We should have a separate info vlan command that shows the
> vlan topology.
>

As Markus said, if qemu supports the old vlan thing, the information
should be there. The 'vlan' attribute will be optional in the
specification anyway.

A different command to list the devices grouped by vlan is indeed a good idea.

Regards,

Miguel

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Michael S. Tsirkin]

On Mon, Jun 07, 2010 at 11:52:05AM -0500, Anthony Liguori wrote:
> On 06/07/2010 11:42 AM, Paul Brook wrote:
>>> On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
>>>  
> With -netdev, there now seems to be little need to support vlans,
> enabling them leads to user confusion and bad performance.
> Disable support for vlans by default, add config option to enable.
>  
 No. If you want to remove vlans, then actually do that.

>>> How is this not what this patch does?  You mean kill the code
>>> completely, not just --contigure option?
>>>  
>> Yes. Configure options are bad. If code isn't worth enabling by default then
>> you've got to have a very good reason why it exists at all.
>>
>
> Configure options are bad except when they are good.
>
> Distributions don't want to support every possible bell and whistle that  
> qemu supports.  By having configuration options upstream, we ensure that  
> everyone is consistently disabling thing in the same fashion and that  
> the interfaces presented to the users are consistent.
>
> I certainly believe that we should not disable features by default.  But  
> I think it's important that we support disabling features from a  
> downstream supportability perspective.
>
> Regards,
>
> Anthony Liguori

So I see two ways to go forward: switch default value in my patch,
or disable vlans unconditionally.

Which will it be?

>> Paul
>>
>>

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Avi Kivity]

On 06/07/2010 09:54 PM, David S. Ahern wrote:



So it's important to know how often your RHEL3/4 guest queries the PIT
(not just receives interrupts, actually reads the counter) under a
realistic load.  If you have such a number (in reads/sec) that would be
a good input to this discussion.

 

Aps that invoke gettimeofday a lot.


Ask a stupid question, get an "it depends on the workload" answer.


As I recall RHEL3 uses the TSC
between timer interrupts, but RHEL4 samples counters on each
gettimeofday call:

http://www.mail-archive.com/k...@vger.kernel.org/msg07231.html

Because of that performance of applications that timestamp log entries
(like a certain product I work on) takes a hit on KVM unless the TSC is
the clock source.
   


So it looks like dropping the PIT out of the kernel, let alone the 
PIC/IOAPIC, is out of the question.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] [PATCH 16/19] Add a query-netdev command to QMP

[Miguel Di Ciurcio Filho]

On Mon, Jun 7, 2010 at 11:42 AM, Daniel P. Berrange  wrote:
> This adds a new QMP command called query-netdev to provide information
> about the available netdev backends in the QEMU binary. There is no
> existing '-netdev ?' support, but if there was, this would obsolete it
>

Hi Daniel,

Could we work on a different name? Just a few hours ago on another
thread query-netdev, instead of the originaly proposed
query-netdevices, was proposed, with similar functionality. I see that
your patch shows the supported backends. I'm working on another patch
that actually shows the current used backend network devices.

Regards,

Miguel

[Qemu-devel] Build problem on Mac OS 10.6.3

[Programmingkid]

I would just like to know if anyone else has seen this build problem with Qemu 
when building on Mac OS 10.6.3:

Makefile:7: config-devices.mak: No such file or directory
make[1]: *** No rule to make target `config-devices.mak'.  Stop.
make: *** [subdir-x86-softmmu] Error 2


I am using the most recent version of Qemu, checked out with git. This is how I 
configured Qemu:

./configure --enable-cocoa --target-list=x86-softmmu

One thing I did notice is this message at the end of the configure output:

Unsupported target CPU


Anyone else seen this problem?

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[David S. Ahern]

On 06/07/10 12:46, Avi Kivity wrote:
> On 06/07/2010 07:31 PM, David S. Ahern wrote:
>>
>> On 06/07/10 09:26, Avi Kivity wrote:
>>
>>   
>>> The original motivation for moving the PIC and IOAPIC into the kernel
>>> was performance, especially for assigned devices.  Both devices are high
>>> interaction since they deal with interrupts; practically after every
>>> interrupt there is either a PIC ioport write, or an APIC bus message,
>>> both signalling an EOI operation.  Moving the PIT into the kernel
>>> allowed us to catch up with missed timer interrupt injections, and
>>> speeded up guests which read the PIT counters (e.g. tickless guests).
>>>
>>> However, modern guests running on modern qemu use MSI extensively; both
>>> virtio and assigned devices now have MSI support; and the planned VFIO
>>> only supports kernel delivery via MSI anyway; line based interrupts will
>>> need to be mediated by userspace.
>>>  
>> The "modern" guest comment is a bit concerning. 2.4 kernels (e.g.,
>> RHEL3) use the PIT for timekeeping and will still be around for a while.
>> RHEL4 and RHEL5 will be around for a long time to come. Not sure how
>> those fit within the "modern" label, though I see my RHEL4 guest is
>> using the pit as a timesource.
>>
> 
> First of all, the existing code will remain for a long while (several
> years).  We still have to support existing userspace.
> 
> But, that's not a satisfactory answer.  I don't want users to choose
> which device model to use according to their guest.  As far as I'm
> concerned all guests are triple-boot with the guest rebooting to a
> different OS every half hour.
> 
> So it's important to know how often your RHEL3/4 guest queries the PIT
> (not just receives interrupts, actually reads the counter) under a
> realistic load.  If you have such a number (in reads/sec) that would be
> a good input to this discussion.
> 

Aps that invoke gettimeofday a lot. As I recall RHEL3 uses the TSC
between timer interrupts, but RHEL4 samples counters on each
gettimeofday call:

http://www.mail-archive.com/k...@vger.kernel.org/msg07231.html

Because of that performance of applications that timestamp log entries
(like a certain product I work on) takes a hit on KVM unless the TSC is
the clock source.

David

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Avi Kivity]

On 06/07/2010 07:31 PM, David S. Ahern wrote:


On 06/07/10 09:26, Avi Kivity wrote:

   

The original motivation for moving the PIC and IOAPIC into the kernel
was performance, especially for assigned devices.  Both devices are high
interaction since they deal with interrupts; practically after every
interrupt there is either a PIC ioport write, or an APIC bus message,
both signalling an EOI operation.  Moving the PIT into the kernel
allowed us to catch up with missed timer interrupt injections, and
speeded up guests which read the PIT counters (e.g. tickless guests).

However, modern guests running on modern qemu use MSI extensively; both
virtio and assigned devices now have MSI support; and the planned VFIO
only supports kernel delivery via MSI anyway; line based interrupts will
need to be mediated by userspace.
 

The "modern" guest comment is a bit concerning. 2.4 kernels (e.g.,
RHEL3) use the PIT for timekeeping and will still be around for a while.
RHEL4 and RHEL5 will be around for a long time to come. Not sure how
those fit within the "modern" label, though I see my RHEL4 guest is
using the pit as a timesource.
   


First of all, the existing code will remain for a long while (several 
years).  We still have to support existing userspace.


But, that's not a satisfactory answer.  I don't want users to choose 
which device model to use according to their guest.  As far as I'm 
concerned all guests are triple-boot with the guest rebooting to a 
different OS every half hour.


So it's important to know how often your RHEL3/4 guest queries the PIT 
(not just receives interrupts, actually reads the counter) under a 
realistic load.  If you have such a number (in reads/sec) that would be 
a good input to this discussion.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Avi Kivity]

On 06/07/2010 08:04 PM, Anthony Liguori wrote:


I think we could also move the local APIC.


I'm not even sure we can safely move the ioapic/pic (mostly due to 
churn).  But the local APIC is so heavily accessed by the guest that 
it's impossible to move it.  Run an ftrace one day, especially on an smp 
guest.  Every IPI requires several APIC accesses.  Before a halt a 
tickless kernel sets the wakeup timer.  EOIs.




To optimize device models, we've tended to put the full device model 
in the kernel whereas the hardware vendors have tended to put only the 
fast paths of the devices models in hardware.


For instance, we could introduce a userspace interface similar to 
vapic support whereas a shared page that mapped the APIC's layout was 
used with a mask to select which registers trapped on read/write.


That leads to very problematic interfaces.  When you separate along a 
device boundary, you have a spec that defines the software interfaces.  
When you separate along a boundary that you define, it's up to you to 
get everything right.


In fact with the ioapic/pic/lapic one of the problems is that the 
interconnection between the devices that is not well defined, and that's 
where we have bugs.




That said, I can understand an argument that the local APIC is part of 
the CPU state since it's a very special type of device.


A better example would be a generic counter kernel mechanism.  I can 
envision such a device as doing nothing more than providing a 
read-only view of a counter with a userspace configurable divider and 
width.  Any write to the counter or read of any other byte outside the 
counter register would result in a trap to userspace.


What about latches?  byte access to word registers?  There will be as 
many special cases as there are timers.


If the kernel supported a bytecode/jit facility I'd happily use that to 
download portions of the device model into the kernel.




That should allow both the PIT and the HPET to be accelerated with 
minimal effort in the kernel.


IMO it's probably more effort than porting HPET to the kernel.  Try 
outlining an interface that supports PIT, HPET, RTC, and ACPI PMTIMER.




I'd be in favor of a straight port to userspace.  We already have the 
interfaces to communicate with an external device model for these 
devices so let's just take the kernel code and stick it into dedicated 
threads in userspace.


Currently we support an all-or-nothing approach.  I don't think local 
APIC in userspace is worthwhile.  Esp. as it will slow down vhost and 
assigned devices significantly - interrupts will have to be mediated by 
userspace.




I think it's easier to then work to merge the two bits of code in the 
same tree than it is to try and take out-of-tree code and merge it 
incrementally.


Are you talking about qemu.git/qemu-kvm.git?  That's the least of my 
concerns, I'm worried about kvm.git.





5. Risk

We may find out after all this is implemented that performance is not 
acceptable and all the work will have to be dropped.


That's another advantage to a straight port to userspace.  We can 
collect performance data with only a modest amount of engineering effort.


Port what exactly?  We have a userspace irqchip implementation.  What we 
don't have is just the ioapic/pic/pit in userspace, and the only way to 
try it out is to implement the whole thing.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Michael S. Tsirkin]

On Mon, Jun 07, 2010 at 05:42:55PM +0100, Paul Brook wrote:
> > On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
> > > > With -netdev, there now seems to be little need to support vlans,
> > > > enabling them leads to user confusion and bad performance.
> > > > Disable support for vlans by default, add config option to enable.
> > > 
> > > No. If you want to remove vlans, then actually do that.
> > 
> > How is this not what this patch does?  You mean kill the code
> > completely, not just --contigure option?
> 
> Yes. Configure options are bad. If code isn't worth enabling by default then 
> you've got to have a very good reason why it exists at all.
> 
> Paul

Everyone ok with disabling vlans with no config option?

-- 
MST

[Qemu-devel] [PATCH v5] block: add sheepdog driver for distributed storage support

[MORITA Kazutaka]

Sheepdog is a distributed storage system for QEMU. It provides highly
available block level storage volumes to VMs like Amazon EBS.  This
patch adds a qemu block driver for Sheepdog.

Sheepdog features are:
- No node in the cluster is special (no metadata node, no control
  node, etc)
- Linear scalability in performance and capacity
- No single point of failure
- Autonomous management (zero configuration)
- Useful volume management support such as snapshot and cloning
- Thin provisioning
- Autonomous load balancing

The more details are available at the project site:
http://www.osrg.net/sheepdog/

Signed-off-by: MORITA Kazutaka 
---
Changes from v4 to v5 are:
 - address the comments to the sheepdog driver (Thanks Kevin, Chris!)
 -- fix a coding style
 -- fix aio_cancel handling
 -- fix an overflow bug in coping hostname
 -- add comments to the non-trivial functions
 - remove already applied patches from the patchset

Changes from v3 to v4 are:
 - fix error handling in bdrv_snapshot_goto.

Changes from v2 to v3 are:

 - add drv->bdrv_close() and drv->bdrv_open() before and after
   bdrv_snapshot_goto() call of the protocol.
 - address the review comments on the sheepdog driver code.

Changes from v1 to v2 are:

 - rebase onto git://repo.or.cz/qemu/kevin.git block
 - modify the sheepdog driver as a protocol driver
 - add new patch to call the snapshot handler of the protocol

 Makefile.objs|2 +-
 block/sheepdog.c | 1905 ++
 2 files changed, 1906 insertions(+), 1 deletions(-)
 create mode 100644 block/sheepdog.c

diff --git a/Makefile.objs b/Makefile.objs
index 54dec26..070db8a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -14,7 +14,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
 
 block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o 
vvfat.o
 block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
-block-nested-y += parallels.o nbd.o blkdebug.o
+block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o
 block-nested-$(CONFIG_WIN32) += raw-win32.o
 block-nested-$(CONFIG_POSIX) += raw-posix.o
 block-nested-$(CONFIG_CURL) += curl.o
diff --git a/block/sheepdog.c b/block/sheepdog.c
new file mode 100644
index 000..a9477a5
--- /dev/null
+++ b/block/sheepdog.c
@@ -0,0 +1,1905 @@
+/*
+ * Copyright (C) 2009-2010 Nippon Telegraph and Telephone Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+#include 
+#include 
+
+#include "qemu-common.h"
+#include "qemu-error.h"
+#include "block_int.h"
+
+#define SD_PROTO_VER 0x01
+
+#define SD_DEFAULT_ADDR "localhost"
+#define SD_DEFAULT_PORT "7000"
+
+#define SD_OP_CREATE_AND_WRITE_OBJ  0x01
+#define SD_OP_READ_OBJ   0x02
+#define SD_OP_WRITE_OBJ  0x03
+
+#define SD_OP_NEW_VDI0x11
+#define SD_OP_LOCK_VDI   0x12
+#define SD_OP_RELEASE_VDI0x13
+#define SD_OP_GET_VDI_INFO   0x14
+#define SD_OP_READ_VDIS  0x15
+
+#define SD_FLAG_CMD_WRITE0x01
+#define SD_FLAG_CMD_COW  0x02
+
+#define SD_RES_SUCCESS   0x00 /* Success */
+#define SD_RES_UNKNOWN   0x01 /* Unknown error */
+#define SD_RES_NO_OBJ0x02 /* No object found */
+#define SD_RES_EIO   0x03 /* I/O error */
+#define SD_RES_VDI_EXIST 0x04 /* Vdi exists already */
+#define SD_RES_INVALID_PARMS 0x05 /* Invalid parameters */
+#define SD_RES_SYSTEM_ERROR  0x06 /* System error */
+#define SD_RES_VDI_LOCKED0x07 /* Vdi is locked */
+#define SD_RES_NO_VDI0x08 /* No vdi found */
+#define SD_RES_NO_BASE_VDI   0x09 /* No base vdi found */
+#define SD_RES_VDI_READ  0x0A /* Cannot read requested vdi */
+#define SD_RES_VDI_WRITE 0x0B /* Cannot write requested vdi */
+#define SD_RES_BASE_VDI_READ 0x0C /* Cannot read base vdi */
+#define SD_RES_BASE_VDI_WRITE   0x0D /* Cannot write base vdi */
+#define SD_RES_NO_TAG0x0E /* Requested tag is not found */
+#define SD_RES_STARTUP   0x0F /* Sheepdog is on starting up */
+#define SD_RES_VDI_NOT_LOCKED   0x10 /* Vdi is not locked */
+#define SD_RES_SHUTDOWN  0x11 /* Sheepdog is shutting down */
+#define SD_RES_NO_MEM0x12 /* Cannot allocate memory */
+#define SD_RES_FULL_VDI  0x13 /* we already have the maximum vdis */
+#define SD_RES_VER_MISMATCH  0x14 /* Protocol version mismatch */
+#define SD_RES_NO_SPACE  0x15 /* Server has no room for new objects */
+#define SD_RES_WAIT_FOR_FORMAT  0x16 /* Waiting for a format operation */
+#define SD_RES_WAIT_FOR_JOIN0x17 /* Waiting for other nodes joining */
+#define SD_RES_JOIN_FAILED   0x18 /* Target node had failed to join sheepdog */
+
+/*
+ * Object ID rules
+ *
+ *  0 - 19 (20 bits): data object space
+ * 20 - 31 (12 bit

[Qemu-devel] Re: FYI: Qemu support on s5pc110

[Ben Dooks]

On Sun, Jun 06, 2010 at 02:03:39PM +0900, Kyungmin Park wrote:
> Dear all,
> 
> FYI: My team release the qemu support on s5pc110 at
> http://en.sourceforge.jp/projects/sfnet_slp-emulator/

Interesting, any plans on merginging it back into qemu?
 
> You can find a s5pc110 files at hw directories.
> 
> The current mainline kernel, aquila and goni is will be run with this qemu.
> 
> Thank you,
> Kyungmin Park
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
-- 
Ben

Q:  What's a light-year?
A:  One-third less calories than a regular year.

Re: [Qemu-devel] [PATCH 10/19] Add a query-machines command to QMP

[Daniel P. Berrange]

On Mon, Jun 07, 2010 at 12:07:56PM -0500, Anthony Liguori wrote:
> On 06/07/2010 11:44 AM, Daniel P. Berrange wrote:
> >On Mon, Jun 07, 2010 at 10:13:27AM -0500, Anthony Liguori wrote:
> >   
> >>On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
> >> 
> >>>Add a new QMP monitor command 'query-machines' to discover what
> >>>machines are defined in the QEMU binary. This is an easily
> >>>parsable replacement for 'qemu -M ?'
> >>>
> >>> [
> >>> {
> >>> "name": "pc-0.13",
> >>> "description": "Standard PC",
> >>> "default": 0
> >>> },
> >>> {
> >>> "name": "pc",
> >>> "description": "Standard PC",
> >>> "canonical": "pc-0.13",
> >>> "default": 1
> >>> },
> >>> {
> >>> "name": "pc-0.12",
> >>> "description": "Standard PC",
> >>> "default": 0
> >>> },
> >>> 
> >>> ]
> >>>
> >>>No legacy readline monitor output is provided.
> >>>
> >>>In the future it would be desirable for each machine's QDict to
> >>>also include details of any qdev devices that are included by
> >>>default in the machine type.
> >>>
> >>>Signed-off-by: Daniel P. Berrange
> >>>---
> >>>  hw/boards.h |1 +
> >>>  monitor.c   |9 +++
> >>>  vl.c|   70
> >>>  +++
> >>>  3 files changed, 80 insertions(+), 0 deletions(-)
> >>>
> >>>diff --git a/hw/boards.h b/hw/boards.h
> >>>index 6f0f0d7..2f6003d 100644
> >>>--- a/hw/boards.h
> >>>+++ b/hw/boards.h
> >>>@@ -32,6 +32,7 @@ typedef struct QEMUMachine {
> >>>  } QEMUMachine;
> >>>
> >>>  int qemu_register_machine(QEMUMachine *m);
> >>>+void do_info_machines(Monitor *mon, QObject **data);
> >>>
> >>>  extern QEMUMachine *current_machine;
> >>>
> >>>diff --git a/monitor.c b/monitor.c
> >>>index f0406e8..b6aa2b4 100644
> >>>--- a/monitor.c
> >>>+++ b/monitor.c
> >>>@@ -55,6 +55,7 @@
> >>>  #include "json-streamer.h"
> >>>  #include "json-parser.h"
> >>>  #include "osdep.h"
> >>>+#include "hw/boards.h"
> >>>
> >>>  //#define DEBUG
> >>>  //#define DEBUG_COMPLETION
> >>>@@ -2449,6 +2450,14 @@ static const mon_cmd_t info_cmds[] = {
> >>>  .mhandler.info_new = do_info_version,
> >>>  },
> >>>  {
> >>>+.name   = "machines",
> >>>+.args_type  = "",
> >>>+.params = "",
> >>>+.help   = "show the machine boards",
> >>>+.user_print = monitor_user_noop,
> >>>+.mhandler.info_new = do_info_machines,
> >>>+},
> >>>+{
> >>>  .name   = "commands",
> >>>  .args_type  = "",
> >>>  .params = "",
> >>>diff --git a/vl.c b/vl.c
> >>>index 0b38d62..8043fac 100644
> >>>--- a/vl.c
> >>>+++ b/vl.c
> >>>@@ -1537,6 +1537,76 @@ static QEMUMachine *find_default_machine(void)
> >>>  return NULL;
> >>>  }
> >>>
> >>>+
> >>>+/**
> >>>+ * do_info_machines(): Show machine boards
> >>>+ *
> >>>+ * Returns a QList object listing all machine boards
> >>>+ * available with this QEMU target. Each element in
> >>>+ * the list is a QDict object containing the following
> >>>+ * keys
> >>>+ *
> >>>+ *  - "name": short name for the machine board
> >>>+ *  - "description": long description of the board
> >>>+ *  - "alias": name of an alias
> >>>+ *
> >>>+ * Example:
> >>>+ *
> >>>+ *  [
> >>>+ * {
> >>>+ *   "name": "pc-0.13",
> >>>+ *"description": "Standard PC",
> >>>+ *"default": 0
> >>>+ * },
> >>>+ * {
> >>>+ *   "name": "pc",
> >>>+ *   "description": "Standard PC",
> >>>+ *   "canonical": "pc-0.13",
> >>>+ *   "default": 1
> >>>+ * },
> >>>+ * {
> >>>+ *   "name": "pc-0.12",
> >>>+ *   "description": "Standard PC",
> >>>+ *   "default": 0
> >>>+ * },
> >>>+ * 
> >>>+ *  ]
> >>>+ *
> >>>+ */
> >>>
> >>>   
> >>My only suggestion would be to:
> >>
> >>{ 'default-machine': 'pc',
> >>'machines': [{
> >>  'name': 'pc',
> >>  'description': 'Standard PC',
> >>},...]
> >>}
> >>
> >>I'd drop 'canonical' too.  Aliasing is an implementation detail and
> >>should not be exposed via the ABI.
> >> 
> >The alias/canonical mapping is something that libvirt needs to know in
> >order guarentee stable guest ABI for all configs it has.
> >
> >What happens is that an app using libvirt will request a guest config
> >with machine type 'pc',
> 
> Does the guest config encode the machine type?  Does that mean that I 
> can't specify pc-0.12 or pc-0.13?

Yes, the XML lets you specify an explicit machine type yourself.

> Since most guests don't specify an explicit machine, can't libvirt just 
> use pc- and be done with it?

If we make sure the 'default-machine' pointed to the latest version
machine type ('pc-0.13' and not 'pc') we could just hardcode to use
the default machine type whenever we see 'pc' in libvirt. Currently
the 'default-machine' and 'pc' canonicalization are separately

Re: [Qemu-devel] [PATCH 10/19] Add a query-machines command to QMP

[Anthony Liguori]

On 06/07/2010 11:44 AM, Daniel P. Berrange wrote:

On Mon, Jun 07, 2010 at 10:13:27AM -0500, Anthony Liguori wrote:
   

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
 

Add a new QMP monitor command 'query-machines' to discover what
machines are defined in the QEMU binary. This is an easily
parsable replacement for 'qemu -M ?'

 [
 {
 "name": "pc-0.13",
 "description": "Standard PC",
 "default": 0
 },
 {
 "name": "pc",
 "description": "Standard PC",
 "canonical": "pc-0.13",
 "default": 1
 },
 {
 "name": "pc-0.12",
 "description": "Standard PC",
 "default": 0
 },
 
 ]

No legacy readline monitor output is provided.

In the future it would be desirable for each machine's QDict to
also include details of any qdev devices that are included by
default in the machine type.

Signed-off-by: Daniel P. Berrange
---
  hw/boards.h |1 +
  monitor.c   |9 +++
  vl.c|   70
  +++
  3 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/hw/boards.h b/hw/boards.h
index 6f0f0d7..2f6003d 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -32,6 +32,7 @@ typedef struct QEMUMachine {
  } QEMUMachine;

  int qemu_register_machine(QEMUMachine *m);
+void do_info_machines(Monitor *mon, QObject **data);

  extern QEMUMachine *current_machine;

diff --git a/monitor.c b/monitor.c
index f0406e8..b6aa2b4 100644
--- a/monitor.c
+++ b/monitor.c
@@ -55,6 +55,7 @@
  #include "json-streamer.h"
  #include "json-parser.h"
  #include "osdep.h"
+#include "hw/boards.h"

  //#define DEBUG
  //#define DEBUG_COMPLETION
@@ -2449,6 +2450,14 @@ static const mon_cmd_t info_cmds[] = {
  .mhandler.info_new = do_info_version,
  },
  {
+.name   = "machines",
+.args_type  = "",
+.params = "",
+.help   = "show the machine boards",
+.user_print = monitor_user_noop,
+.mhandler.info_new = do_info_machines,
+},
+{
  .name   = "commands",
  .args_type  = "",
  .params = "",
diff --git a/vl.c b/vl.c
index 0b38d62..8043fac 100644
--- a/vl.c
+++ b/vl.c
@@ -1537,6 +1537,76 @@ static QEMUMachine *find_default_machine(void)
  return NULL;
  }

+
+/**
+ * do_info_machines(): Show machine boards
+ *
+ * Returns a QList object listing all machine boards
+ * available with this QEMU target. Each element in
+ * the list is a QDict object containing the following
+ * keys
+ *
+ *  - "name": short name for the machine board
+ *  - "description": long description of the board
+ *  - "alias": name of an alias
+ *
+ * Example:
+ *
+ *  [
+ * {
+ *   "name": "pc-0.13",
+ *"description": "Standard PC",
+ *"default": 0
+ * },
+ * {
+ *   "name": "pc",
+ *   "description": "Standard PC",
+ *   "canonical": "pc-0.13",
+ *   "default": 1
+ * },
+ * {
+ *   "name": "pc-0.12",
+ *   "description": "Standard PC",
+ *   "default": 0
+ * },
+ * 
+ *  ]
+ *
+ */

   

My only suggestion would be to:

{ 'default-machine': 'pc',
'machines': [{
  'name': 'pc',
  'description': 'Standard PC',
},...]
}

I'd drop 'canonical' too.  Aliasing is an implementation detail and
should not be exposed via the ABI.
 

The alias/canonical mapping is something that libvirt needs to know in
order guarentee stable guest ABI for all configs it has.

What happens is that an app using libvirt will request a guest config
with machine type 'pc',


Does the guest config encode the machine type?  Does that mean that I 
can't specify pc-0.12 or pc-0.13?


Since most guests don't specify an explicit machine, can't libvirt just 
use pc- and be done with it?


Regards,

Anthony Liguori


  and libvirt resolves that to the canonical
type 'pc-0.12', and then launches QEMU with '-M pc-0.12' instead of
the '-M pc'. If libvirt passed '-M pc' and let QEMU do the canonicalization,
the guest ABI would no longer be stable across QEMU upgrades because the
canonicalization changes to point to the newer version.

Regards,
Daniel
   

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Anthony Liguori]

On 06/07/2010 10:26 AM, Avi Kivity wrote:
I am currently investigating a problem with the a guest running Linux 
malfunctioning in the NMI watchdog code.  The problem is that we don't 
handle NMI delivery mode for the local APIC LINT0 pin; instead we 
expect ExtInt deliver mode or that the line is disabled completely.  
In addition the i8254 timer is tied to the BSP, while in this case the 
timer can broadcast to all vcpus.


There is some code that tries to second-guess the guest and provide it 
the inputs it sees, but this is fragile.  The only way to get reliable 
operation is to emulate the hardware fully.


Now I'd much rather do that in userspace, since it's a lot of 
sensitive work.  I'll enumerate below the general motivation, 
advantages and disadvantages, and a plan for moving forward.


Motivation
==

The original motivation for moving the PIC and IOAPIC into the kernel 
was performance, especially for assigned devices.  Both devices are 
high interaction since they deal with interrupts; practically after 
every interrupt there is either a PIC ioport write, or an APIC bus 
message, both signalling an EOI operation.  Moving the PIT into the 
kernel allowed us to catch up with missed timer interrupt injections, 
and speeded up guests which read the PIT counters (e.g. tickless guests).


However, modern guests running on modern qemu use MSI extensively; 
both virtio and assigned devices now have MSI support; and the planned 
VFIO only supports kernel delivery via MSI anyway; line based 
interrupts will need to be mediated by userspace.


The only high frequency non-MSI interrupt sources remaining are the 
various timers; and the default one, HPET, is in userspace (and having 
its own scaling problems as a result).  So in theory we can move PIC, 
IOAPIC, and PIT support to userspace and not lose much performance.


I think we could also move the local APIC.

To optimize device models, we've tended to put the full device model in 
the kernel whereas the hardware vendors have tended to put only the fast 
paths of the devices models in hardware.


For instance, we could introduce a userspace interface similar to vapic 
support whereas a shared page that mapped the APIC's layout was used 
with a mask to select which registers trapped on read/write.


That said, I can understand an argument that the local APIC is part of 
the CPU state since it's a very special type of device.


A better example would be a generic counter kernel mechanism.  I can 
envision such a device as doing nothing more than providing a read-only 
view of a counter with a userspace configurable divider and width.  Any 
write to the counter or read of any other byte outside the counter 
register would result in a trap to userspace.


That should allow both the PIT and the HPET to be accelerated with 
minimal effort in the kernel.


Moving the implementation to userspace allows us more flexibility, and 
more consistency in the implementation of timekeeping for the various 
clock chips; it becomes easier to follow the nuances of real hardware 
in this area.


Interestingly, while the IOAPIC/PIC code was written we proposed 
making it independent of the local APIC; had we done so, the move 
would have been much easier (simply dropping the existing code).



Advantages of a move


1. Reduced kernel footprint

Good for security, and allows fixing bugs without reboots.

2. Centralized timekeeping

Instead of having one solution for PIT timekeeping, and another for 
RTC and HPET timekeeping, we can have all timer chips in userspace.  
The local APIC timer still needs to be in the kernel - it is much too 
high bandwidth to be in userspace; but on the other hand it is very 
different from the other timer chips.


3. Flexibility

Easier to have wierd board layouts (multiple IOAPICs, etc.).  Not a 
very strong advantage.


Disadvantages
=

1. Still need to keep the old code around for a long while

We can't just rip it out - old userspace depends on it.  So the 
security advantages are only with cooperating userspace, and the other 
advantages only show up.


2. Need to bring the qemu code up to date

The current qemu ioapic code lags some way behind the kernel; also 
need PIT timekeeping


3. May need kernel support for interval-timer-follows-thread

Currently the timekeeping code has an optimization which causes the 
hrtimer that models the PIT to follow the BSP (which is most likely to 
receive the interrupt); this reduces cpu cross-talk.


I don't think the kernel interval timer code has such an optimization; 
we may need to implement it.


4. Much churn

This is a lot of work.


I'd be in favor of a straight port to userspace.  We already have the 
interfaces to communicate with an external device model for these 
devices so let's just take the kernel code and stick it into dedicated 
threads in userspace.


I think it's easier to then work to merge the two bits of code in the 
same tree than it is 

Re: [Qemu-devel] [PATCH 10/19] Add a query-machines command to QMP

[Daniel P. Berrange]

On Mon, Jun 07, 2010 at 10:13:27AM -0500, Anthony Liguori wrote:
> On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
> >Add a new QMP monitor command 'query-machines' to discover what
> >machines are defined in the QEMU binary. This is an easily
> >parsable replacement for 'qemu -M ?'
> >
> > [
> > {
> > "name": "pc-0.13",
> > "description": "Standard PC",
> > "default": 0
> > },
> > {
> > "name": "pc",
> > "description": "Standard PC",
> > "canonical": "pc-0.13",
> > "default": 1
> > },
> > {
> > "name": "pc-0.12",
> > "description": "Standard PC",
> > "default": 0
> > },
> > 
> > ]
> >
> >No legacy readline monitor output is provided.
> >
> >In the future it would be desirable for each machine's QDict to
> >also include details of any qdev devices that are included by
> >default in the machine type.
> >
> >Signed-off-by: Daniel P. Berrange
> >---
> >  hw/boards.h |1 +
> >  monitor.c   |9 +++
> >  vl.c|   70 
> >  +++
> >  3 files changed, 80 insertions(+), 0 deletions(-)
> >
> >diff --git a/hw/boards.h b/hw/boards.h
> >index 6f0f0d7..2f6003d 100644
> >--- a/hw/boards.h
> >+++ b/hw/boards.h
> >@@ -32,6 +32,7 @@ typedef struct QEMUMachine {
> >  } QEMUMachine;
> >
> >  int qemu_register_machine(QEMUMachine *m);
> >+void do_info_machines(Monitor *mon, QObject **data);
> >
> >  extern QEMUMachine *current_machine;
> >
> >diff --git a/monitor.c b/monitor.c
> >index f0406e8..b6aa2b4 100644
> >--- a/monitor.c
> >+++ b/monitor.c
> >@@ -55,6 +55,7 @@
> >  #include "json-streamer.h"
> >  #include "json-parser.h"
> >  #include "osdep.h"
> >+#include "hw/boards.h"
> >
> >  //#define DEBUG
> >  //#define DEBUG_COMPLETION
> >@@ -2449,6 +2450,14 @@ static const mon_cmd_t info_cmds[] = {
> >  .mhandler.info_new = do_info_version,
> >  },
> >  {
> >+.name   = "machines",
> >+.args_type  = "",
> >+.params = "",
> >+.help   = "show the machine boards",
> >+.user_print = monitor_user_noop,
> >+.mhandler.info_new = do_info_machines,
> >+},
> >+{
> >  .name   = "commands",
> >  .args_type  = "",
> >  .params = "",
> >diff --git a/vl.c b/vl.c
> >index 0b38d62..8043fac 100644
> >--- a/vl.c
> >+++ b/vl.c
> >@@ -1537,6 +1537,76 @@ static QEMUMachine *find_default_machine(void)
> >  return NULL;
> >  }
> >
> >+
> >+/**
> >+ * do_info_machines(): Show machine boards
> >+ *
> >+ * Returns a QList object listing all machine boards
> >+ * available with this QEMU target. Each element in
> >+ * the list is a QDict object containing the following
> >+ * keys
> >+ *
> >+ *  - "name": short name for the machine board
> >+ *  - "description": long description of the board
> >+ *  - "alias": name of an alias
> >+ *
> >+ * Example:
> >+ *
> >+ *  [
> >+ * {
> >+ *   "name": "pc-0.13",
> >+ *"description": "Standard PC",
> >+ *"default": 0
> >+ * },
> >+ * {
> >+ *   "name": "pc",
> >+ *   "description": "Standard PC",
> >+ *   "canonical": "pc-0.13",
> >+ *   "default": 1
> >+ * },
> >+ * {
> >+ *   "name": "pc-0.12",
> >+ *   "description": "Standard PC",
> >+ *   "default": 0
> >+ * },
> >+ * 
> >+ *  ]
> >+ *
> >+ */
> >   
> 
> My only suggestion would be to:
> 
> { 'default-machine': 'pc',
>'machines': [{
>  'name': 'pc',
>  'description': 'Standard PC',
>},...]
> }
> 
> I'd drop 'canonical' too.  Aliasing is an implementation detail and 
> should not be exposed via the ABI.

The alias/canonical mapping is something that libvirt needs to know in
order guarentee stable guest ABI for all configs it has.

What happens is that an app using libvirt will request a guest config
with machine type 'pc', and libvirt resolves that to the canonical
type 'pc-0.12', and then launches QEMU with '-M pc-0.12' instead of
the '-M pc'. If libvirt passed '-M pc' and let QEMU do the canonicalization,
the guest ABI would no longer be stable across QEMU upgrades because the
canonicalization changes to point to the newer version.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH v6 5/6] Inter-VM shared memory PCI device

[Cam Macdonell]

On Sat, Jun 5, 2010 at 3:44 AM, Blue Swirl  wrote:
> On Fri, Jun 4, 2010 at 9:45 PM, Cam Macdonell  wrote:
>> Support an inter-vm shared memory device that maps a shared-memory object as 
>> a
>> PCI device in the guest.  This patch also supports interrupts between guest 
>> by
>> communicating over a unix domain socket.  This patch applies to the qemu-kvm
>> repository.
>>
>>    -device ivshmem,size=[,shm=]
>>
>> Interrupts are supported between multiple VMs by using a shared memory server
>> by using a chardev socket.
>>
>>    -device ivshmem,size=[,shm=]
>>           [,chardev=][,msi=on][,irqfd=on][,vectors=n][,role=peer|master]
>>    -chardev socket,path=,id=
>>
>> (shared memory server is qemu.git/contrib/ivshmem-server)
>>
>> Sample programs and init scripts are in a git repo here:
>>
>>    www.gitorious.org/nahanni
>> ---
>>  Makefile.target |    3 +
>>  hw/ivshmem.c    |  852 
>> +++
>>  qemu-char.c     |    6 +
>>  qemu-char.h     |    3 +
>>  qemu-doc.texi   |   43 +++
>>  5 files changed, 907 insertions(+), 0 deletions(-)
>>  create mode 100644 hw/ivshmem.c
>>
>> diff --git a/Makefile.target b/Makefile.target
>> index c4ba592..4888308 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -202,6 +202,9 @@ obj-$(CONFIG_USB_OHCI) += usb-ohci.o
>>  obj-y += rtl8139.o
>>  obj-y += e1000.o
>>
>> +# Inter-VM PCI shared memory
>> +obj-y += ivshmem.o
>> +
>
> Can this be compiled once, simply by moving this to Makefile.objs
> instead of Makefile.target? Also, because the code seems to be KVM
> specific, it can't be compiled unconditionally but depending on at
> least CONFIG_KVM and maybe CONFIG_EVENTFD.

The device uses eventfds for signalling, but never creates the
eventfds itself as they are passed from a server using SCM_RIGHTS.
So, it does not depend on the eventfd API.  Its dependence on
irqfd/ioeventfd (the only KVM specific bits) are optional via the
command-line.

A runtime check for KVM is done for the reasons Avi mentioned.

>
> Why is this KVM specific BTW, Posix SHM is available on many
> platforms? What would happen if kvm_set_foobar functions were not
> called when KVM is not being used? Is host eventfd support essential?
>
>>  # Hardware support
>>  obj-i386-y += vga.o
>>  obj-i386-y += mc146818rtc.o i8259.o pc.o
>> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
>> new file mode 100644
>> index 000..9057612
>> --- /dev/null
>> +++ b/hw/ivshmem.c
>> @@ -0,0 +1,852 @@
>> +/*
>> + * Inter-VM Shared Memory PCI device.
>> + *
>> + * Author:
>> + *      Cam Macdonell 
>> + *
>> + * Based On: cirrus_vga.c
>> + *          Copyright (c) 2004 Fabrice Bellard
>> + *          Copyright (c) 2004 Makoto Suzuki (suzu)
>> + *
>> + *      and rtl8139.c
>> + *          Copyright (c) 2006 Igor Kovalenko
>> + *
>> + * This code is licensed under the GNU GPL v2.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "hw.h"
>> +#include "console.h"
>> +#include "pc.h"
>> +#include "pci.h"
>> +#include "sysemu.h"
>> +
>> +#include "msix.h"
>> +#include "qemu-kvm.h"
>> +#include "libkvm.h"
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define IVSHMEM_IRQFD   0
>> +#define IVSHMEM_MSI     1
>> +
>> +//#define DEBUG_IVSHMEM
>> +#ifdef DEBUG_IVSHMEM
>> +#define IVSHMEM_DPRINTF(fmt, args...)        \
>> +    do {printf("IVSHMEM: " fmt, ##args); } while (0)
>
> Please use __VA_ARGS__.
>
>> +#else
>> +#define IVSHMEM_DPRINTF(fmt, args...)
>> +#endif
>> +
>> +typedef struct Peer {
>> +    int nb_eventfds;
>> +    int *eventfds;
>> +} Peer;
>> +
>> +typedef struct EventfdEntry {
>> +    PCIDevice *pdev;
>> +    int vector;
>> +} EventfdEntry;
>> +
>> +typedef struct IVShmemState {
>> +    PCIDevice dev;
>> +    uint32_t intrmask;
>> +    uint32_t intrstatus;
>> +    uint32_t doorbell;
>> +
>> +    CharDriverState ** eventfd_chr;
>
> I'd remove the space between '**' and 'eventfd_chr', it's used inconsistently.
>
>> +    CharDriverState * server_chr;
>> +    int ivshmem_mmio_io_addr;
>> +
>> +    pcibus_t mmio_addr;
>> +    pcibus_t shm_pci_addr;
>> +    uint64_t ivshmem_offset;
>> +    uint64_t ivshmem_size; /* size of shared memory region */
>> +    int shm_fd; /* shared memory file descriptor */
>> +
>> +    Peer *peers;
>> +    int nb_peers; /* how many guests we have space for */
>> +    int max_peer; /* maximum numbered peer */
>> +
>> +    int vm_id;
>> +    uint32_t vectors;
>> +    uint32_t features;
>> +    EventfdEntry *eventfd_table;
>> +
>> +    char * shmobj;
>> +    char * sizearg;
>> +    char * role;
>> +} IVShmemState;
>> +
>> +/* registers for the Inter-VM shared memory device */
>> +enum ivshmem_registers {
>> +    IntrMask = 0,
>> +    IntrStatus = 4,
>> +    IVPosition = 8,
>> +    Doorbell = 12,
>> +};
>
> IIRC these should be uppercase.

I worked from rtl8139 which doesn't have them uppercase.  But doing a
quick search, I can see most devices do, I'll fix that.

>
>> +
>> +static i

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Anthony Liguori]

On 06/07/2010 11:42 AM, Paul Brook wrote:

On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
 

With -netdev, there now seems to be little need to support vlans,
enabling them leads to user confusion and bad performance.
Disable support for vlans by default, add config option to enable.
 

No. If you want to remove vlans, then actually do that.
   

How is this not what this patch does?  You mean kill the code
completely, not just --contigure option?
 

Yes. Configure options are bad. If code isn't worth enabling by default then
you've got to have a very good reason why it exists at all.
   


Configure options are bad except when they are good.

Distributions don't want to support every possible bell and whistle that 
qemu supports.  By having configuration options upstream, we ensure that 
everyone is consistently disabling thing in the same fashion and that 
the interfaces presented to the users are consistent.


I certainly believe that we should not disable features by default.  But 
I think it's important that we support disabling features from a 
downstream supportability perspective.


Regards,

Anthony Liguori


Paul

   

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[David S. Ahern]

On 06/07/10 09:26, Avi Kivity wrote:

> The original motivation for moving the PIC and IOAPIC into the kernel
> was performance, especially for assigned devices.  Both devices are high
> interaction since they deal with interrupts; practically after every
> interrupt there is either a PIC ioport write, or an APIC bus message,
> both signalling an EOI operation.  Moving the PIT into the kernel
> allowed us to catch up with missed timer interrupt injections, and
> speeded up guests which read the PIT counters (e.g. tickless guests).
> 
> However, modern guests running on modern qemu use MSI extensively; both
> virtio and assigned devices now have MSI support; and the planned VFIO
> only supports kernel delivery via MSI anyway; line based interrupts will
> need to be mediated by userspace.

The "modern" guest comment is a bit concerning. 2.4 kernels (e.g.,
RHEL3) use the PIT for timekeeping and will still be around for a while.
RHEL4 and RHEL5 will be around for a long time to come. Not sure how
those fit within the "modern" label, though I see my RHEL4 guest is
using the pit as a timesource.

David

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Paul Brook]

> On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
> > > With -netdev, there now seems to be little need to support vlans,
> > > enabling them leads to user confusion and bad performance.
> > > Disable support for vlans by default, add config option to enable.
> > 
> > No. If you want to remove vlans, then actually do that.
> 
> How is this not what this patch does?  You mean kill the code
> completely, not just --contigure option?

Yes. Configure options are bad. If code isn't worth enabling by default then 
you've got to have a very good reason why it exists at all.

Paul

Re: [Qemu-devel] [PATCH 0/5] Add '-device help' output for device params and help text

[Anthony Liguori]

On 05/31/2010 07:41 AM, Amit Shah wrote:

Hello,

This patch series adds support to specify some descriptive help text
to qdev device parameters. This series adds some help text to the
virtserialport and net family of devices as an example, and the new
output is shown in the respective commits.

This series also adds a new '-device help' option that lists all the
available qdev devices (which is avl. via -device ? now), and adds
each device's parameters to the output listing. This output also shows
the descriptive text.

The idea is to auto-generate documentation from code and to populate
some wiki / qemu-doc.texi using this new target.
   


I really dislike having options print their own help.

Maybe we can introduce a proper -help option that takes an argument that 
can display subsystem specific help?


For instance:

qemu -help device

Would display the help output in this series.

My other concern is that we now have a big mess of properties that don't 
have help text.  What are the chances that anyone is going to go through 
and do this?


I'd rather we bite the bullet and add help everywhere before merging any 
of this because experience has shown that existing code usually never 
gets converted if not converted all at once.


Regards,

Anthony Liguori


Changes from previous send:
- Removed the 'RFC' tag
- Not using macros in net.h (Markus)

It'll be helpful to have people submit some short descriptive text for
the subsystems they care about.

Amit Shah (5):
   qdev: Add a description field for qdev properties for documentation
   virtio-serial: Add description fields for qdev properties
   net.h: Add description fields for qdev properites
   qdev: Re-arrange code to have device properties shown from own
 function
   qdev: Add new '-device help' option, shows all devices and properties

  block_int.h   |   10 +++---
  hw/a9mpcore.c |2 +-
  hw/acpi_piix4.c   |2 +-
  hw/arm11mpcore.c  |4 +-
  hw/arm_sysctl.c   |4 +-
  hw/armv7m.c   |2 +-
  hw/cs4231a.c  |6 ++--
  hw/debugcon.c |6 ++--
  hw/eccmemctl.c|2 +-
  hw/escc.c |   16 +-
  hw/etraxfs_pic.c  |3 +-
  hw/fdc.c  |   10 +++---
  hw/gus.c  |8 ++--
  hw/i2c.c  |2 +-
  hw/ide/cmd646.c   |2 +-
  hw/ide/isa.c  |6 ++--
  hw/ide/qdev.c |4 +-
  hw/integratorcp.c |2 +-
  hw/lance.c|2 +-
  hw/m48t59.c   |   12 
  hw/mc146818rtc.c  |2 +-
  hw/ne2000-isa.c   |4 +-
  hw/parallel.c |8 ++--
  hw/pci.c  |   10 +++---
  hw/qdev-addr.h|4 +-
  hw/qdev.c |   51 +
  hw/qdev.h |   75 ++---
  hw/s390-virtio-bus.c  |2 +-
  hw/sb16.c |   10 +++---
  hw/scsi-bus.c |2 +-
  hw/scsi-disk.c|2 +-
  hw/serial.c   |8 ++--
  hw/slavio_timer.c |2 +-
  hw/smbus_eeprom.c |2 +-
  hw/sparc32_dma.c  |2 +-
  hw/sun4m.c|2 +-
  hw/sun4m_iommu.c  |2 +-
  hw/sun4u.c|2 +-
  hw/syborg_fb.c|4 +-
  hw/syborg_interrupt.c |2 +-
  hw/syborg_keyboard.c  |2 +-
  hw/syborg_pointer.c   |4 +-
  hw/syborg_serial.c|2 +-
  hw/syborg_timer.c |2 +-
  hw/tcx.c  |   10 +++---
  hw/usb-ohci.c |4 +-
  hw/usb-serial.c   |   12 
  hw/vga-pci.c  |4 +-
  hw/virtio-blk.h   |4 +-
  hw/virtio-console.c   |   19 
  hw/virtio-net.h   |   51 +
  hw/virtio-pci.c   |   16 +-
  hw/virtio-serial.h|   13 
  hw/virtio.h   |2 +-
  hw/xilinx_ethlite.c   |6 ++-
  hw/xilinx_intc.c  |3 +-
  hw/xilinx_timer.c |4 +-
  net.h |9 --
  usb-linux.c   |8 ++--
  59 files changed, 268 insertions(+), 208 deletions(-)


   

Re: [Qemu-devel] [PATCH 19/19] Add a -capabilities argument to allow easy query for static QEMU info

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

The QMP monitor provides a number of commands for querying info about
the QEMU binary capabilities. Given that these commands don't take
any options and just return static data, requiring the use of QMP is
unnecessarily onerous. This adds a new '-capabilities' command line
argument as a syntactic sugar for accessing the QMP commands that
just return static QEMU binary capabilities.

Setting the '-capabilities' argument causes QEMU to output the requested
data on stdout, pretty printed in JSON format. The argument expects an
associated value to identify the data to be printed. This can be one of
the strings version|machines|devices|cputypes|target|commands|argv|netdev

To query all possible data at once, the shorthand 'all' is allowed.

The output is a QDict where the key is the type of data requested, and
the value is the JSON data from the associated monitor command. For
example:
   


I think the idea is good but I think we should use a different name as 
QMP capabilities has a different meaning.


Maybe features?

Regards,

Anthony Liguori


   $ qemu -capabilities all
   {
 "machines": [
 {
 "name": "pc-0.13",
 "description": "Standard PC",
 "default": 0
 },
 {
 "name": "pc",
 
 }
 
  }
  "version": {
 "qemu": {
 "micro": 50,
 "minor": 12,
 "major": 0
 },
 "package": ""
  },
  "target": {
 "arch": "i386",
 "wordsize": 32,
  ...
}

Signed-off-by: Daniel P. Berrange
---
  monitor.c   |4 +-
  monitor.h   |2 +
  qemu-options.hx |9 +
  vl.c|  100 +++
  4 files changed, 113 insertions(+), 2 deletions(-)

diff --git a/monitor.c b/monitor.c
index 6203f75..401a27a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -711,7 +711,7 @@ static void do_info_version_print(Monitor *mon, const 
QObject *data)
   *
   * { qemu: { "major": 0, "minor": 11, "micro": 5 }, "package": "" }
   */
-static void do_info_version(Monitor *mon, QObject **ret_data)
+void do_info_version(Monitor *mon, QObject **ret_data)
  {
  const char *version = QEMU_VERSION;
  int major = 0, minor = 0, micro = 0;
@@ -760,7 +760,7 @@ static QObject *get_cmd_dict(const char *name)
  return qobject_from_jsonf("{ 'name': %s }", p);
  }

-static void do_info_commands(Monitor *mon, QObject **ret_data)
+void do_info_commands(Monitor *mon, QObject **ret_data)
  {
  QList *cmd_list;
  const mon_cmd_t *cmd;
diff --git a/monitor.h b/monitor.h
index 733485f..dc376af 100644
--- a/monitor.h
+++ b/monitor.h
@@ -57,5 +57,7 @@ typedef void (MonitorCompletion)(void *opaque, QObject 
*ret_data);
  void monitor_set_error(Monitor *mon, QError *qerror);

  void do_info_argv(Monitor *mon, QObject **data);
+void do_info_version(Monitor *mon, QObject **ret_data);
+void do_info_commands(Monitor *mon, QObject **ret_data);

  #endif /* !MONITOR_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index a6928b7..5f82347 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -27,6 +27,15 @@ STEXI
  Display version information and exit
  ETEXI

+DEF("capabilities", HAS_ARG, QEMU_OPTION_capabilities,
+"-capabilities   
all|version|machines|devices|cputypes|target|commands|argv|netdev\n"
+"display capabilities of the QEMU binary and exit\n", 
QEMU_ARCH_ALL)
+STEXI
+...@item -capabilities  
all|version|machines|devices|cputypes|target|commands|argv|netdev
+...@findex -capabilities
+Display capabilities of the QEMU binary and exit
+ETEXI
+
  DEF("M", HAS_ARG, QEMU_OPTION_M,
  "-M machine  select emulated machine (-M ? for list)\n", 
QEMU_ARCH_ALL)
  STEXI
diff --git a/vl.c b/vl.c
index de010cc..1f165a1 100644
--- a/vl.c
+++ b/vl.c
@@ -1988,6 +1988,97 @@ static void version(void)
  }


+enum {
+QEMU_CAPS_VERSION,
+QEMU_CAPS_MACHINES,
+QEMU_CAPS_DEVICES,
+QEMU_CAPS_CPUTYPES,
+QEMU_CAPS_TARGET,
+QEMU_CAPS_COMMANDS,
+QEMU_CAPS_ARGV,
+QEMU_CAPS_NETDEV,
+QEMU_CAPS_CONFIG,
+
+QEMU_CAPS_LAST
+};
+
+QEMU_ENUM_DECL(qemu_caps_flag);
+QEMU_ENUM_IMPL(qemu_caps_flag, QEMU_CAPS_LAST,
+   "version",
+   "machines",
+   "devices",
+   "cputypes",
+   "target",
+   "commands",
+   "argv",
+   "netdev",
+   "config");
+
+static int qemu_caps_flags_from_string(const char *flagsstr)
+{
+if (strcmp(flagsstr, "all") == 0)
+return ~0;
+else {
+int i = qemu_caps_flag_from_string(flagsstr);
+if (i<  0)
+return 0;
+return (1<<  i);
+}
+
+return 0;
+}
+typedef void (*qemu_caps_handler)(Monitor *mon, QObject **);
+
+/* Binding capabilities to a subset of monitor commands.
+ * The commands must only use static binary state,

Re: [Qemu-devel] [PATCH 11/19] Add a query-devices command to QMP

[Daniel P. Berrange]

On Mon, Jun 07, 2010 at 10:14:00AM -0500, Anthony Liguori wrote:
> On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
> >Adds a command to QMP called 'query-devices' to allow for discovery
> >of all devices known to the QEMU binary. THis is inteded to replace
> >use of the '-device ?' and '-device devtype,?' command line args
> >
> >The data format is designed to allow easy extension to support more
> >data:
> >   
> 
> query-qdm?

Ahh, I missed that because it is not ported to QMP yet. This patch 
should nicely dovetail with that command.

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Michael S. Tsirkin]

On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
> > With -netdev, there now seems to be little need to support vlans,
> > enabling them leads to user confusion and bad performance.
> > Disable support for vlans by default, add config option to enable.
> 
> No. If you want to remove vlans, then actually do that.

How is this not what this patch does? You mean kill the code
completely, not just --contigure option?

> As I've said before if you want a point-point network model then you should 
> implement that (and remove the vlan code, probably replacing with equivalent 
> functionality). We should not have both point-point and broadcast interfaces.
> 
> Paul


This is what netdev does: replaces vlan. What is left is remove vlan.

-- 
MST

Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans

[Paul Brook]

> With -netdev, there now seems to be little need to support vlans,
> enabling them leads to user confusion and bad performance.
> Disable support for vlans by default, add config option to enable.

No. If you want to remove vlans, then actually do that.
As I've said before if you want a point-point network model then you should 
implement that (and remove the vlan code, probably replacing with equivalent 
functionality). We should not have both point-point and broadcast interfaces.

Paul

Re: [Qemu-devel] [PATCH] Fix and simplify gui timer logic.

[Paul Brook]

> Kill nographic timer.  Have a global gui_timer instead.  Have the gui
> timer enabled unconditionally.  We need a timer running anyway for mmio
> flush, so the whole have-gui-timer-only-when-needed logic is pretty
> pointless.  It also simplifies displaylisteners coming and going at
> runtime, we don't need to care about the timer then as it runs anyway.

Linking mmio flushes to the gui is completely bogus.  The fact that we're 
doing arbitrary periodic mmio flushes suggests something else is horribly 
broken.

Paul

[Qemu-devel] Re: [PATCH 13/19] Add a query-target command to QMP

[Paolo Bonzini]

On 06/07/2010 04:42 PM, Daniel P. Berrange wrote:

+#ifdef CONFIG_KVM
+qlist_append_obj(engines, qobject_from_jsonf("{ 'name': 'kvm' }"));
+#endif
+#ifdef CONFIG_XEN
+qlist_append_obj(engines, qobject_from_jsonf("{ 'name': 'xen' }"));
+#endif


I suggest using kvm_available() and xen_available(), so that any 
cut-and-paste typos do not go undetected in the future.


Paolo

[Qemu-devel] Re: [PATCH 19/19] Add a -capabilities argument to allow easy query for static QEMU info

[Daniel P. Berrange]

On Mon, Jun 07, 2010 at 06:04:24PM +0200, Paolo Bonzini wrote:
> On 06/07/2010 04:42 PM, Daniel P. Berrange wrote:
> >The QMP monitor provides a number of commands for querying info about
> >the QEMU binary capabilities. Given that these commands don't take
> >any options and just return static data, requiring the use of QMP is
> >unnecessarily onerous. This adds a new '-capabilities' command line
> >argument as a syntactic sugar for accessing the QMP commands that
> >just return static QEMU binary capabilities.
> >
> >Setting the '-capabilities' argument causes QEMU to output the requested
> >data on stdout, pretty printed in JSON format. The argument expects an
> >associated value to identify the data to be printed. This can be one of
> >the strings version|machines|devices|cputypes|target|commands|argv|netdev
> >
> >To query all possible data at once, the shorthand 'all' is allowed.
> >
> >The output is a QDict where the key is the type of data requested, and
> >the value is the JSON data from the associated monitor command. For
> >example:
> 
> A lot of this patch and the other monitor.c changes you had can likely 
> be moved in a capabilities.c file?

Yeah, I didn't much like adding more to vl.c or monitor.c. I can move this
to a new file, or a different existing one if there are any other better
suggestions

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Qemu-devel] Re: [PATCH 19/19] Add a -capabilities argument to allow easy query for static QEMU info

[Paolo Bonzini]

On 06/07/2010 04:42 PM, Daniel P. Berrange wrote:

The QMP monitor provides a number of commands for querying info about
the QEMU binary capabilities. Given that these commands don't take
any options and just return static data, requiring the use of QMP is
unnecessarily onerous. This adds a new '-capabilities' command line
argument as a syntactic sugar for accessing the QMP commands that
just return static QEMU binary capabilities.

Setting the '-capabilities' argument causes QEMU to output the requested
data on stdout, pretty printed in JSON format. The argument expects an
associated value to identify the data to be printed. This can be one of
the strings version|machines|devices|cputypes|target|commands|argv|netdev

To query all possible data at once, the shorthand 'all' is allowed.

The output is a QDict where the key is the type of data requested, and
the value is the JSON data from the associated monitor command. For
example:


A lot of this patch and the other monitor.c changes you had can likely 
be moved in a capabilities.c file?


Paolo

Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Anthony Liguori]

Hi Daniel,

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

As everyone here agrees, having management apps parse -help output
to determine the QEMU capabilities is not at all nice, because it
is an ill-defined&  fragile data format. Looking more broadly these
same issues apply to all the other command line options that accept
a '?' flag for querying capabilities.

We have a very nice structured data format we could be using for
this: JSON. What's lacking is code to output all this information
in the JSON format. This patch series can thus be summarized as
'JSON for everything'
   


For the most part, this series looks pretty nice.

I think my only real objection is the query-argv bits.  The enums are a 
bit awkward to define but I understand the value of it and I can't think 
of a better way to do it.


Regards,

Anthony Liguori


For reference, here is the full list of information libvirt currently
queries from QEMU:

   * Detection of command line flags (-help parsing)

 -no-kqemu, -no-kvm, -enable-kvm, -no-reboot
 -name, -uuid, -xen-domid, -domid, -drive
 -vga, -std-vga, -pcidevice, -mem-path
 -chardev, -balloon, -device, -rtc, -rtc-td-hack
 -no-hpet, -no-kvm-pit-reinjection, -tdf
 -fsdev -sdl

   * Detection of parameters (-help parsing)

  -drive format=
  -drive boot=
  -drive serial=
  -drive cache=
  -cpu cores=, threads=, sockets=
  -netdev vhost=

   * Detection of parameter values (-help parsing)

  -drive cache=writethrough|writeback|none
vs
  -drive cache=default|on|off

   * Version number  (-help parsing)

 -netdev  + 0.13.0

 0.9.0  for VNC syntax

 0.10.0 for vnet hdr

   * Parse -M ?  output to get list of machine types + aliases

   * Parse -device pci-assign,? to check for 'configfd' parameter

   * Parse -cpu ?  to get list of named CPU types

   * Parse binary name (qemu-system-) to guess arch of target


This isn't an 100% exhaustive list of things that we would like
to be able to get access to though. It can likely cover all of
the following:

  * Version

   QEMU major, minor, micro numbers. KVM version. Package
   version

  * Devices

   List of device names. Parameter names. Parameter value
   data types. Allowed strings for enums

  * Arguments

   List of command line arguments. Parameter names. Parameter
   value data types. Allowed strings for enums

  * Machine types

   List of names + aliases
   List of default devices in machine

  * CPU types

   List of names, associated feature flags, all allowed
   feature flags

  * Target info

   Arch name, wordsize

  * Monitor commands

   List of all monitor commands. Parameter names. Parameter
   value data types. Allowed strings for enums

  * Block device backends

   List of all block device backends. Parameter names.
   Parameter value data types. Allowed strings for enums

  * Netdev device backends

   List of all netdev device backends. Parameter names.
   Parameter value data types. Allowed strings for enums

  * Chardev device backends

   List of all chardev device backends. Parameter names.
   Parameter value data types. Allowed strings for enums


This patch series attempts to satisfy as much of this as is
feasible with the current QEMU codebase structure. The series
comprises four stages

  * Some basic infrastructure. Support for JSON pretty printing.
Introduction of standardized helpers for converting enums
to/from strings. Introduction of an 'enum' data type for
QemuOpt to expose a formal list of valid values&  simplify
config handling / parsing. Compile time assertion checking

  * Convert driver, netdev&  rtc config options to use the new
enum data type for all appropriate args

  * Add new QMP monitor commands exposing data for machine
types, devices, cpu types, arch target, argv, config params,
and netdev backends.

  * Add a new '-capabilities' command line arg as syntactic
sugar for the monitor commands that just report on static
info about the QEMU binary.

The main problem encountered with this patch series is the
split between argv and config parameters. The qemu-config.c
file provides the information is a good data format, allowing
programatic access to the list of parameters for each config
option (eg, the 'cache', 'file', 'aio', etc bits for -drive).
There are some issues with it though

  - It lacks a huge amount of coverage wrt to the full argv
available, even simple things like the '-m' argument
don't exist.

  - It is inconsistent in handling parameters. eg it  hands
off validation of netdev backends to other code, to allow
for handling of different parameters for tap vs user vs
socket backends.  For chardev backends though, it directly
includes a union of all possible parameters.

Ideally the 'query-argv' command would not be required, but
unless those problems with the qemu-c

[Qemu-devel] Re: [PATCH] Fix --enable-user-pie compilation.

[Paolo Bonzini]

On 06/07/2010 05:07 PM, Richard Henderson wrote:

Ping^4


r~

On 05/21/2010 10:04 AM, Richard Henderson wrote:

We forgot to propagate -fpie to the libdis-user directory.

Signed-off-by: Richard Henderson
---
  configure |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 3cd2c5f..ba3aaac 100755
--- a/configure
+++ b/configure
@@ -2355,6 +2355,9 @@ for d in libdis libdis-user; do
  ln -s $source_path/Makefile.dis $d/Makefile
  echo>  $d/config.mak
  done
+if test "$static" = "no" -a "$user_pie" = "yes" ; then
+  echo "QEMU_CFLAGS+=-fpie">  libdis-user/config.mak
+fi

  for target in $target_list; do
  target_dir="$target"


Acked-by: Paolo Bonzini 

Paolo

[Qemu-devel] Re: [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Anthony Liguori]

On 06/07/2010 11:02 AM, Paolo Bonzini wrote:

On 06/07/2010 04:58 PM, Anthony Liguori wrote:


A query-argv is a really bad idea IMHO.


Agreed.  Instead we should work towards improve the configurability of 
QEMU via monitor commands or -readconfig.  libvirt is already using 
-nodefaults on recent QEMU, so this is not _that_ far away.


I've also got a series that's just about ready to go based on Glauber's 
-machine option which converts quite a lot of existing options to config 
based.


Regards,

Anthony Liguori


Paolo

[Qemu-devel] Re: [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Paolo Bonzini]

On 06/07/2010 04:58 PM, Anthony Liguori wrote:


A query-argv is a really bad idea IMHO.


Agreed.  Instead we should work towards improve the configurability of 
QEMU via monitor commands or -readconfig.  libvirt is already using 
-nodefaults on recent QEMU, so this is not _that_ far away.


Paolo

[Qemu-devel] Re: [RFC] QMP: Introduce query-netdevices documentation

[Avi Kivity]

On 06/07/2010 04:48 PM, Anthony Liguori wrote:
Yes.  I'd want separate queries for each, or perhaps a single query 
that returns


{ 'hostdev': some-object-with-host-device-properties-only, 'nic': 
some-object-that-describes-the-guest-nic }



We need a query-netdev and then info qdm already provides the guest 
nic properties.  Just filter out devices that have a netdev property.


Agreed, no reason for a specialized 
'get-all-guest-devices-that-happen-to-be-nics' query.


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

Re: [Qemu-devel] [PATCH] make qemu_thread_create block all signals

[Richard Henderson]

On 06/03/2010 06:20 AM, Paolo Bonzini wrote:
> All signals will thus be routed through the IO thread.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  cpus.c|   38 +++---
>  qemu-thread.c |7 +++
>  2 files changed, 18 insertions(+), 27 deletions(-)

Acked-by: Richard Henderson 


r~

[Qemu-devel] [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[Avi Kivity]

I am currently investigating a problem with the a guest running Linux 
malfunctioning in the NMI watchdog code.  The problem is that we don't 
handle NMI delivery mode for the local APIC LINT0 pin; instead we expect 
ExtInt deliver mode or that the line is disabled completely.  In 
addition the i8254 timer is tied to the BSP, while in this case the 
timer can broadcast to all vcpus.


There is some code that tries to second-guess the guest and provide it 
the inputs it sees, but this is fragile.  The only way to get reliable 
operation is to emulate the hardware fully.


Now I'd much rather do that in userspace, since it's a lot of sensitive 
work.  I'll enumerate below the general motivation, advantages and 
disadvantages, and a plan for moving forward.


Motivation
==

The original motivation for moving the PIC and IOAPIC into the kernel 
was performance, especially for assigned devices.  Both devices are high 
interaction since they deal with interrupts; practically after every 
interrupt there is either a PIC ioport write, or an APIC bus message, 
both signalling an EOI operation.  Moving the PIT into the kernel 
allowed us to catch up with missed timer interrupt injections, and 
speeded up guests which read the PIT counters (e.g. tickless guests).


However, modern guests running on modern qemu use MSI extensively; both 
virtio and assigned devices now have MSI support; and the planned VFIO 
only supports kernel delivery via MSI anyway; line based interrupts will 
need to be mediated by userspace.


The only high frequency non-MSI interrupt sources remaining are the 
various timers; and the default one, HPET, is in userspace (and having 
its own scaling problems as a result).  So in theory we can move PIC, 
IOAPIC, and PIT support to userspace and not lose much performance.


Moving the implementation to userspace allows us more flexibility, and 
more consistency in the implementation of timekeeping for the various 
clock chips; it becomes easier to follow the nuances of real hardware in 
this area.


Interestingly, while the IOAPIC/PIC code was written we proposed making 
it independent of the local APIC; had we done so, the move would have 
been much easier (simply dropping the existing code).



Advantages of a move


1. Reduced kernel footprint

Good for security, and allows fixing bugs without reboots.

2. Centralized timekeeping

Instead of having one solution for PIT timekeeping, and another for RTC 
and HPET timekeeping, we can have all timer chips in userspace.  The 
local APIC timer still needs to be in the kernel - it is much too high 
bandwidth to be in userspace; but on the other hand it is very different 
from the other timer chips.


3. Flexibility

Easier to have wierd board layouts (multiple IOAPICs, etc.).  Not a very 
strong advantage.


Disadvantages
=

1. Still need to keep the old code around for a long while

We can't just rip it out - old userspace depends on it.  So the security 
advantages are only with cooperating userspace, and the other advantages 
only show up.


2. Need to bring the qemu code up to date

The current qemu ioapic code lags some way behind the kernel; also need 
PIT timekeeping


3. May need kernel support for interval-timer-follows-thread

Currently the timekeeping code has an optimization which causes the 
hrtimer that models the PIT to follow the BSP (which is most likely to 
receive the interrupt); this reduces cpu cross-talk.


I don't think the kernel interval timer code has such an optimization; 
we may need to implement it.


4. Much churn

This is a lot of work.

5. Risk

We may find out after all this is implemented that performance is not 
acceptable and all the work will have to be dropped.



Proposed interface
==

1. KVM_SET_LINT_PIN (vcpu ioctl)

Sets the value (0 or 1) that a vcpu's LINT0 or LINT1 senses.

Note: problematic; may be high frequency but ignored due to masking at 
the local APIC LVT level.  Will also be broadcast across all vcpus by 
userspace with typical configurations.  We may need a way to tell 
userspace we'll be ignoring those signals.


May also be extended to emulate thermal interrupts if someone feels the 
need.


An alternative is a couple of new fields in kvm_run which are sampled on 
every entry (unless masked).


2. KVM_EXIT_REASON_INTACK (kvm_run exit reason)

Informs userspace that the vcpu is running an INTACK cycle; userspace 
should provide the interrupt vector on the next KVM_VCPU_RUN.


3. KVM_APIC_MESSAGE (vm ioctl)

Sends an APIC message on the APIC message bus, if the destination is in 
the kernel (typically IOAPIC interrupt messages).


4. KVM_EXIT_REASON_APIC_MESSAGE (kvm_run exit reason)

Sends an APIC message on the APIC message bus, if the destination is not 
in the kernel (typically IOAPIC EOI messages).


The above are all architectural, and correspond to wires on physical 
systems.  This increases the confidence that they are correct.


5. KVM

Re: [Qemu-devel] [PATCH 07/19] Convert netdev client types to use an enumeration

[Daniel P. Berrange]

On Mon, Jun 07, 2010 at 10:09:02AM -0500, Anthony Liguori wrote:
> On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
> >Declare an enumeration for all netdev client types, values
> >matching indexes in the net_client_types array. Use the
> >enum helpers for the string<->  int conversion of client types.
> >
> >Before:
> >
> >   $ qemu -net type=foo,sfs
> >   qemu: -net type=foo,sfs: Parameter 'type' expects a network client type
> >
> >After:
> >
> >   $ qemu -net type=foo,sfs
> >   qemu: -net type=foo,sfs: Parameter 'type' expects none, nic, user, tap, 
> >   socket, dump
> >
> >Signed-off-by: Daniel P. Berrange
> >---
> >  net.c |  124 
> >  ++--
> >  1 files changed, 74 insertions(+), 50 deletions(-)
> >
> >diff --git a/net.c b/net.c
> >index efa8b3d..5349001 100644
> >--- a/net.c
> >+++ b/net.c
> >@@ -42,6 +42,36 @@ static QTAILQ_HEAD(, VLANClientState) non_vlan_clients;
> >
> >  int default_net = 1;
> >
> >+enum {
> >+NET_CLIENT_NONE,
> >+NET_CLIENT_NIC,
> >+#ifdef CONFIG_SLIRP
> >+NET_CLIENT_USER,
> >+#endif
> >+NET_CLIENT_TAP,
> >+NET_CLIENT_SOCKET,
> >+#ifdef CONFIG_VDE
> >+NET_CLIENT_VDE,
> >+#endif
> >+NET_CLIENT_DUMP,
> >+
> >+NET_CLIENT_LAST
> >+};
> >+
> >+QEMU_ENUM_DECL(qemu_net_type);
> >+QEMU_ENUM_IMPL(qemu_net_type, NET_CLIENT_LAST,
> >+   "none",
> >+   "nic",
> >+#ifdef CONFIG_SLIRP
> >+   "user",
> >+#endif
> >+   "tap",
> >+   "socket",
> >+#ifdef CONFIG_VDE
> >+   "vde",
> >+#endif
> >+   "dump");
> >+
> >  /***/
> >  /* network device redirectors */
> >
> >@@ -844,18 +874,15 @@ typedef int (*net_client_init_func)(QemuOpts *opts,
> >  #define NET_MAX_DESC 20
> >
> >  static const struct {
> >-const char *type;
> >  net_client_init_func init;
> >  QemuOptDesc desc[NET_MAX_DESC];
> >  } net_client_types[] = {
> >   
> 
> I think:
> 
>  [NET_CLIENT_NONE] = {
> .desc = {...}
> },
> 
> Would be a bit more robust than relying on explicit ordering.

Ah, I didn't know you could do that for array initializers. That
should result in even stronger compile time validation which is always
nice.

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH 07/19] Convert netdev client types to use an enumeration

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

Declare an enumeration for all netdev client types, values
matching indexes in the net_client_types array. Use the
enum helpers for the string<->  int conversion of client types.

Before:

   $ qemu -net type=foo,sfs
   qemu: -net type=foo,sfs: Parameter 'type' expects a network client type

After:

   $ qemu -net type=foo,sfs
   qemu: -net type=foo,sfs: Parameter 'type' expects none, nic, user, tap, 
socket, dump

Signed-off-by: Daniel P. Berrange
---
  net.c |  124 ++--
  1 files changed, 74 insertions(+), 50 deletions(-)

diff --git a/net.c b/net.c
index efa8b3d..5349001 100644
--- a/net.c
+++ b/net.c
@@ -42,6 +42,36 @@ static QTAILQ_HEAD(, VLANClientState) non_vlan_clients;

  int default_net = 1;

+enum {
+NET_CLIENT_NONE,
+NET_CLIENT_NIC,
+#ifdef CONFIG_SLIRP
+NET_CLIENT_USER,
+#endif
+NET_CLIENT_TAP,
+NET_CLIENT_SOCKET,
+#ifdef CONFIG_VDE
+NET_CLIENT_VDE,
+#endif
+NET_CLIENT_DUMP,
+
+NET_CLIENT_LAST
+};
+
+QEMU_ENUM_DECL(qemu_net_type);
+QEMU_ENUM_IMPL(qemu_net_type, NET_CLIENT_LAST,
+  "none",
+  "nic",
+#ifdef CONFIG_SLIRP
+  "user",
+#endif
+  "tap",
+  "socket",
+#ifdef CONFIG_VDE
+  "vde",
+#endif
+  "dump");
+
  /***/
  /* network device redirectors */

@@ -844,18 +874,15 @@ typedef int (*net_client_init_func)(QemuOpts *opts,
  #define NET_MAX_DESC 20

  static const struct {
-const char *type;
  net_client_init_func init;
  QemuOptDesc desc[NET_MAX_DESC];
  } net_client_types[] = {
   


I think:

 [NET_CLIENT_NONE] = {
.desc = {...}
},

Would be a bit more robust than relying on explicit ordering.

Regards,

Anthony Liguori


-{
-.type = "none",
+{ /* NET_CLIENT_NONE */
  .desc = {
  NET_COMMON_PARAMS_DESC,
  { /* end of list */ }
  },
-}, {
-.type = "nic",
+}, { /* NET_CLIENT_NIC */
  .init = net_init_nic,
  .desc = {
  NET_COMMON_PARAMS_DESC,
@@ -884,8 +911,7 @@ static const struct {
  { /* end of list */ }
  },
  #ifdef CONFIG_SLIRP
-}, {
-.type = "user",
+}, { /* NET_CLIENT_USER */
  .init = net_init_slirp,
  .desc = {
  NET_COMMON_PARAMS_DESC,
@@ -945,8 +971,7 @@ static const struct {
  { /* end of list */ }
  },
  #endif
-}, {
-.type = "tap",
+}, { /* NET_CLIENT_TAP */
  .init = net_init_tap,
  .desc = {
  NET_COMMON_PARAMS_DESC,
@@ -988,8 +1013,7 @@ static const struct {
  #endif /* _WIN32 */
  { /* end of list */ }
  },
-}, {
-.type = "socket",
+}, { /* NET_CLIENT_SOCKET */
  .init = net_init_socket,
  .desc = {
  NET_COMMON_PARAMS_DESC,
@@ -1013,8 +1037,7 @@ static const struct {
  { /* end of list */ }
  },
  #ifdef CONFIG_VDE
-}, {
-.type = "vde",
+}, { /* NET_CLIENT_VDE */
  .init = net_init_vde,
  .desc = {
  NET_COMMON_PARAMS_DESC,
@@ -1038,8 +1061,7 @@ static const struct {
  { /* end of list */ }
  },
  #endif
-}, {
-.type = "dump",
+}, { /* NET_CLIENT_DUMP */
  .init = net_init_dump,
  .desc = {
  NET_COMMON_PARAMS_DESC,
@@ -1055,30 +1077,41 @@ static const struct {
  { /* end of list */ }
  },
  },
-{ /* end of list */ }
  };
+verify(ARRAY_SIZE(net_client_types) == NET_CLIENT_LAST);

  int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
  {
  const char *name;
-const char *type;
-int i;
+const char *typestr;
+VLANState *vlan = NULL;
+int type;

-type = qemu_opt_get(opts, "type");
-if (!type) {
+typestr = qemu_opt_get(opts, "type");
+if (!typestr) {
  qerror_report(QERR_MISSING_PARAMETER, "type");
  return -1;
  }
+type = qemu_net_type_from_string(typestr);
+
+if (type<  0) {
+   char *valid = qemu_net_type_to_string_list();
+   qerror_report(QERR_INVALID_PARAMETER_VALUE, "type",
+ valid);
+   qemu_free(valid);
+   return -1;
+}

  if (is_netdev) {
-if (strcmp(type, "tap") != 0&&
+   if (type<  0 ||
+   (type != NET_CLIENT_TAP&&
  #ifdef CONFIG_SLIRP
-strcmp(type, "user") != 0&&
+type != NET_CLIENT_USER&&
  #endif
  #ifdef CONFIG_VDE
-strcmp(type, "vde") != 0&&
+type != NET_CLIENT_VDE&&
  #endif
-strcmp(type, "socket") != 0) {
+type != NET_CLIENT_SOCKET)) {
  qerror_report(QERR_INVALID_PARAMETER_VALUE, "type",
"a netdev backend type");
  return -1;
@@ -1103,35 +1136,26 

Re: [Qemu-devel] [PATCH] Fix --enable-user-pie compilation.

[Richard Henderson]

Ping^4


r~

On 05/21/2010 10:04 AM, Richard Henderson wrote:
> We forgot to propagate -fpie to the libdis-user directory.
> 
> Signed-off-by: Richard Henderson 
> ---
>  configure |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/configure b/configure
> index 3cd2c5f..ba3aaac 100755
> --- a/configure
> +++ b/configure
> @@ -2355,6 +2355,9 @@ for d in libdis libdis-user; do
>  ln -s $source_path/Makefile.dis $d/Makefile
>  echo > $d/config.mak
>  done
> +if test "$static" = "no" -a "$user_pie" = "yes" ; then
> +  echo "QEMU_CFLAGS+=-fpie" > libdis-user/config.mak
> +fi
>  
>  for target in $target_list; do
>  target_dir="$target"

[Qemu-devel] Re: [PATCH 02/19] Add support for compile time assertions

[Paolo Bonzini]

On 06/07/2010 04:42 PM, Daniel P. Berrange wrote:

The verify.h header, taken from GNULIB, provides macros for
doing compile time assertions.

There are two main variants

For use in global namespace (eg header files, or global decls)

   verify(CONDITION)


There is QEMU_BUILD_BUG_ON already.

Paolo

Re: [Qemu-devel] Re: [RFC] QMP: Introduce query-netdevices documentation

[Markus Armbruster]

Miguel Di Ciurcio Filho  writes:

> On Mon, Jun 7, 2010 at 10:48 AM, Anthony Liguori  
> wrote:

 $ qemu -netdev tap,id=tap0 -device e1000,netdev=tap0

 This makes a 1:1 relation. So clearly tap0 is a host device, e1000.0
 will be a guest device, and they are connected.
>>>
>>> Yes.  I'd want separate queries for each, or perhaps a single query that
>>> returns
>>>
>>> { 'hostdev': some-object-with-host-device-properties-only, 'nic':
>>> some-object-that-describes-the-guest-nic }
>>
>> We need a query-netdev and then info qdm already provides the guest nic
>> properties.  Just filter out devices that have a netdev property.
>>
>
> How about this small draft:
>
> Possible values for "type": tap, user, vde and socket. The 'info'
> object contains all the parameters available via -netdev type,args.
>
> Notice: vlan is still there, unless the support for it is removed, IMHO.

Agreed.  As long as we have VLANs, we better cover them here.

> -> { "execute": "query-netdev" }
> <- {
>   "return": [
>  {
> "device": "tap.0",
> "vlan": 0,
> "type": "tap",
> "info": {
>"script": "/etc/qemu-ifup",
>"downscript": "/etc/qemu-ifdown",
>"ifname": "tap0",
> },

This one's connected to a VLAN, namely #0.  Any guest device on the same
VLAN has a "vlan" property with the value 0.

>  {
> "device": "user.0",
> "type": "user",
> "info": {
>"net": "10.0.2.0",
>"netmask": "255.255.255.0"
> },
>  },

And this one's not connected to a VLAN.  It may or may not be connected
to a single guest device.  If it is, then that device has a "netdev"
property pointing to it.

For what it's worth, "info network" shows that device as "peer=ID".

Re: [Qemu-devel] [PATCH 16/19] Add a query-netdev command to QMP

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

This adds a new QMP command called query-netdev to provide information
about the available netdev backends in the QEMU binary. There is no
existing '-netdev ?' support, but if there was, this would obsolete it

The data format looks like

 [
 {
 "name": "user",
 "props": [
 {
 "name": "type",
 "help": "net client type (nic, tap etc.)",
 "type": "string"
 },
   


I'm not sure it's a good idea to expose the help text.  That bakes it 
into the ABI which seems bad.


Regards,

Anthony Liguori


 {
 "name": "name",
 "help": "identifier for monitor commands",
 "type": "string"
 },
 {
 "name": "hostname",
 "help": "client hostname reported by the builtin DHCP 
server",
 "type": "string"
 },
 ...
 ]
 }
 {
 "name": "tap",
 "props": [
 {
 "name": "type",
 "help": "net client type (nic, tap etc.)",
 "type": "string"
 },
 {
 "name": "ifname",
 "help": "interface name",
 "type": "string"
 },
 ...
 ]
 }
 ...
 ]

Signed-off-by: Daniel P. Berrange
---
  monitor.c |8 
  net.c |   49 +
  net.h |2 ++
  qemu-option.c |4 
  qemu-option.h |4 
  5 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/monitor.c b/monitor.c
index 1c5157d..19f42f3 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2552,6 +2552,14 @@ static const mon_cmd_t info_cmds[] = {
  .mhandler.info_new = do_info_argv,
  },
  {
+.name   = "netdev",
+.args_type  = "",
+.params = "",
+.help   = "list valid netdev backend types",
+.user_print = monitor_user_noop,
+.mhandler.info_new = do_info_netdev,
+},
+{
  .name   = "network",
  .args_type  = "",
  .params = "",
diff --git a/net.c b/net.c
index 5349001..90929d4 100644
--- a/net.c
+++ b/net.c
@@ -36,6 +36,8 @@
  #include "qemu-common.h"
  #include "qemu_socket.h"
  #include "hw/qdev.h"
+#include "qjson.h"
+#include "qlist.h"

  static QTAILQ_HEAD(, VLANState) vlans;
  static QTAILQ_HEAD(, VLANClientState) non_vlan_clients;
@@ -1080,6 +1082,53 @@ static const struct {
  };
  verify(ARRAY_SIZE(net_client_types) == NET_CLIENT_LAST);

+
+void do_info_netdev(Monitor *mon, QObject **data)
+{
+QList *backends = qlist_new();
+int i, j;
+
+for (i = 0; i<  ARRAY_SIZE(net_client_types) ; i++) {
+   QObject *backend;
+   QList *props = qlist_new();
+
+   if (i == NET_CLIENT_NIC ||
+   i == NET_CLIENT_DUMP||
+   i == NET_CLIENT_NONE)
+   continue;
+
+   for (j = 0 ; net_client_types[i].desc[j].name != NULL ; j++) {
+   const QemuOptDesc *desc = net_client_types[i].desc + j;
+   QObject *prop;
+
+   if (strcmp(desc->name, "vlan") == 0)
+   continue;
+
+   if (desc->help) {
+   prop = qobject_from_jsonf("{ 'name': %s, 'type': %s, 'help': %s 
}",
+ desc->name,
+ qemu_opt_type_to_string(desc->type),
+ desc->help);
+   } else {
+   prop = qobject_from_jsonf("{ 'name': %s, 'type': %s }",
+ desc->name,
+ qemu_opt_type_to_string(desc->type));
+   }
+
+   qlist_append_obj(props, prop);
+   }
+
+   backend = qobject_from_jsonf("{ 'name': %s, 'props': %p }",
+qemu_net_type_to_string(i),
+props);
+
+   qlist_append_obj(backends, backend);
+}
+
+*data = qobject_from_jsonf("{ 'backends': %p }", backends);
+}
+
+
  int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
  {
  const char *name;
diff --git a/net.h b/net.h
index b83f615..9c0e385 100644
--- a/net.h
+++ b/net.h
@@ -167,6 +167,8 @@ void net_host_device_remove(Monitor *mon, const QDict 
*qdict);
  int do_netdev_add(Monitor *mon, const QDict *qdict, QObject **ret_data);
  int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data);

+void do_info_netdev(Monitor *mon, QObject **data);
+
  #define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
  #define DEFAULT_NETWORK_DOWN_SCRIPT "/etc/qemu-ifdown"
  #ifdef __sun__
diff --git a/qemu-option.c b/qemu-option.c
index bb9cc43.

[Qemu-devel] [PATCH 19/19] Add a -capabilities argument to allow easy query for static QEMU info

[Daniel P. Berrange]

The QMP monitor provides a number of commands for querying info about
the QEMU binary capabilities. Given that these commands don't take
any options and just return static data, requiring the use of QMP is
unnecessarily onerous. This adds a new '-capabilities' command line
argument as a syntactic sugar for accessing the QMP commands that
just return static QEMU binary capabilities.

Setting the '-capabilities' argument causes QEMU to output the requested
data on stdout, pretty printed in JSON format. The argument expects an
associated value to identify the data to be printed. This can be one of
the strings version|machines|devices|cputypes|target|commands|argv|netdev

To query all possible data at once, the shorthand 'all' is allowed.

The output is a QDict where the key is the type of data requested, and
the value is the JSON data from the associated monitor command. For
example:

  $ qemu -capabilities all
  {
"machines": [
{
"name": "pc-0.13",
"description": "Standard PC",
"default": 0
},
{
"name": "pc",

}

 }
 "version": {
"qemu": {
"micro": 50,
"minor": 12,
"major": 0
},
"package": ""
 },
 "target": {
"arch": "i386",
"wordsize": 32,
 ...
   }

Signed-off-by: Daniel P. Berrange 
---
 monitor.c   |4 +-
 monitor.h   |2 +
 qemu-options.hx |9 +
 vl.c|  100 +++
 4 files changed, 113 insertions(+), 2 deletions(-)

diff --git a/monitor.c b/monitor.c
index 6203f75..401a27a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -711,7 +711,7 @@ static void do_info_version_print(Monitor *mon, const 
QObject *data)
  *
  * { qemu: { "major": 0, "minor": 11, "micro": 5 }, "package": "" }
  */
-static void do_info_version(Monitor *mon, QObject **ret_data)
+void do_info_version(Monitor *mon, QObject **ret_data)
 {
 const char *version = QEMU_VERSION;
 int major = 0, minor = 0, micro = 0;
@@ -760,7 +760,7 @@ static QObject *get_cmd_dict(const char *name)
 return qobject_from_jsonf("{ 'name': %s }", p);
 }
 
-static void do_info_commands(Monitor *mon, QObject **ret_data)
+void do_info_commands(Monitor *mon, QObject **ret_data)
 {
 QList *cmd_list;
 const mon_cmd_t *cmd;
diff --git a/monitor.h b/monitor.h
index 733485f..dc376af 100644
--- a/monitor.h
+++ b/monitor.h
@@ -57,5 +57,7 @@ typedef void (MonitorCompletion)(void *opaque, QObject 
*ret_data);
 void monitor_set_error(Monitor *mon, QError *qerror);
 
 void do_info_argv(Monitor *mon, QObject **data);
+void do_info_version(Monitor *mon, QObject **ret_data);
+void do_info_commands(Monitor *mon, QObject **ret_data);
 
 #endif /* !MONITOR_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index a6928b7..5f82347 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -27,6 +27,15 @@ STEXI
 Display version information and exit
 ETEXI
 
+DEF("capabilities", HAS_ARG, QEMU_OPTION_capabilities,
+"-capabilities   
all|version|machines|devices|cputypes|target|commands|argv|netdev\n"
+"display capabilities of the QEMU binary and exit\n", 
QEMU_ARCH_ALL)
+STEXI
+...@item -capabilities  
all|version|machines|devices|cputypes|target|commands|argv|netdev
+...@findex -capabilities
+Display capabilities of the QEMU binary and exit
+ETEXI
+
 DEF("M", HAS_ARG, QEMU_OPTION_M,
 "-M machine  select emulated machine (-M ? for list)\n", QEMU_ARCH_ALL)
 STEXI
diff --git a/vl.c b/vl.c
index de010cc..1f165a1 100644
--- a/vl.c
+++ b/vl.c
@@ -1988,6 +1988,97 @@ static void version(void)
 }
 
 
+enum {
+QEMU_CAPS_VERSION,
+QEMU_CAPS_MACHINES,
+QEMU_CAPS_DEVICES,
+QEMU_CAPS_CPUTYPES,
+QEMU_CAPS_TARGET,
+QEMU_CAPS_COMMANDS,
+QEMU_CAPS_ARGV,
+QEMU_CAPS_NETDEV,
+QEMU_CAPS_CONFIG,
+
+QEMU_CAPS_LAST
+};
+
+QEMU_ENUM_DECL(qemu_caps_flag);
+QEMU_ENUM_IMPL(qemu_caps_flag, QEMU_CAPS_LAST,
+   "version",
+   "machines",
+   "devices",
+   "cputypes",
+   "target",
+   "commands",
+   "argv",
+   "netdev",
+   "config");
+
+static int qemu_caps_flags_from_string(const char *flagsstr)
+{
+if (strcmp(flagsstr, "all") == 0)
+return ~0;
+else {
+int i = qemu_caps_flag_from_string(flagsstr);
+if (i < 0)
+return 0;
+return (1 << i);
+}
+
+return 0;
+}
+typedef void (*qemu_caps_handler)(Monitor *mon, QObject **);
+
+/* Binding capabilities to a subset of monitor commands.
+ * The commands must only use static binary state, no
+ * VM runtime state and must accept mon=NULL
+ */
+static const qemu_caps_handler qemu_caps_handlers[] = {
+do_info_version,
+do_info_machines,
+do_info_devices,
+do_info_cpu_types,
+do_info_target,
+do_info_commands,
+do_info_argv

Re: [Qemu-devel] [PATCH 14/19] Add a query-argv command to QMP

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

Add a new QMP command called 'query-argv' to information about the command
line arguments supported by the QEMU binary. This is intended to remove the
need for apps to parse '-help' output.
   


This is just as bad as parsing -help output IMHO.

The problem with something like this is that it discourages people from 
using proper APIs to get at capabilities information.


Regards,

Anthony Liguori


 [
 {
 "name": "help",
 },
 {
 "name": "M",
 "parameters": [
 {
 }
 ]
 },
 ]

NB, command line args which accept parameters have a non-zero length
parameters list. The element of the list is currently empty though
since the parameter names are not easily available in QEMU source in
a format suitable for exposing as a stable ABI.

Signed-off-by: Daniel P. Berrange
---
  monitor.c |8 ++
  monitor.h |2 +
  vl.c  |   74 +
  3 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/monitor.c b/monitor.c
index d55b27b..1c5157d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2544,6 +2544,14 @@ static const mon_cmd_t info_cmds[] = {
  .mhandler.info_new = do_info_commands,
  },
  {
+.name   = "argv",
+.args_type  = "",
+.params = "",
+.help   = "list QEMU command line argv",
+.user_print = monitor_user_noop,
+.mhandler.info_new = do_info_argv,
+},
+{
  .name   = "network",
  .args_type  = "",
  .params = "",
diff --git a/monitor.h b/monitor.h
index ea15469..46b7a0e 100644
--- a/monitor.h
+++ b/monitor.h
@@ -55,4 +55,6 @@ typedef void (MonitorCompletion)(void *opaque, QObject 
*ret_data);

  void monitor_set_error(Monitor *mon, QError *qerror);

+void do_info_argv(Monitor *mon, QObject **data);
+
  #endif /* !MONITOR_H */
diff --git a/vl.c b/vl.c
index 8043fac..a76c673 100644
--- a/vl.c
+++ b/vl.c
@@ -1987,6 +1987,80 @@ static void version(void)
  printf("QEMU emulator version " QEMU_VERSION QEMU_PKGVERSION ", Copyright (c) 
2003-2008 Fabrice Bellard\n");
  }

+
+/**
+ * do_info_argv():
+ *
+ * Provide info about the command line arguments
+ * supported by the QEMU binary. The returned
+ * data is a QList with one QDict entry for  each named
+ * argument. Each entry's QDict contains the following
+ * keys
+ *
+ *  'name': the command argument name (eg 'drive' for -drive arg)
+ *  'parameters': list of parameter values (if any)
+ *
+ * NB, the 'parameters' key is omitted completely if
+ * the argument has no associated value.
+ *
+ *  details of the parameters are not yet filled in
+ * since this info is not easily available
+ *
+ * [
+ * {
+ * "name": "help",
+ * "parameters": [
+ * ]
+ * },
+ * {
+ * "name": "M",
+ * "parameters": [
+ * {
+ * }
+ * ]
+ * },
+ * ]
+ */
+void do_info_argv(Monitor *mon, QObject **data)
+{
+QList *args = qlist_new();
+struct {
+   const char *name;
+   int has_arg;
+   const char *help;
+} options_help[] = {
+#define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
+{ option, opt_arg },
+#define DEFHEADING(text)
+#define HAS_ARG 1
+#include "qemu-options.h"
+#undef DEF
+#undef DEFHEADING
+#undef HAS_ARG
+   { NULL, 0 },
+};
+int i;
+
+for (i = 0 ; options_help[i].name != NULL ; i++) {
+   QObject *opt;
+
+   if (options_help[i].has_arg) {
+   /* XXX actually fill in the parameter details */
+   opt = qobject_from_jsonf("{ 'name': %s, 'parameters': [] }",
+options_help[i].name);
+   } else {
+   opt = qobject_from_jsonf("{ 'name': %s }",
+options_help[i].name);
+   }
+
+
+   qlist_append_obj(args, opt);
+}
+
+*data = QOBJECT(args);
+}
+
+
  static void help(int exitcode)
  {
  const char *options_help =
   

Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Anthony Liguori]

On 06/07/2010 10:10 AM, Daniel P. Berrange wrote:

On Mon, Jun 07, 2010 at 09:58:11AM -0500, Anthony Liguori wrote:
   

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:
 

As everyone here agrees, having management apps parse -help output
to determine the QEMU capabilities is not at all nice, because it
is an ill-defined&   fragile data format. Looking more broadly these
same issues apply to all the other command line options that accept
a '?' flag for querying capabilities.

We have a very nice structured data format we could be using for
this: JSON. What's lacking is code to output all this information
in the JSON format. This patch series can thus be summarized as
'JSON for everything'

   

I'm slightly skeptical that JSON is the right format for this TBH.

 

For reference, here is the full list of information libvirt currently
queries from QEMU:

   * Detection of command line flags (-help parsing)

 -no-kqemu, -no-kvm, -enable-kvm, -no-reboot
 -name, -uuid, -xen-domid, -domid, -drive
 -vga, -std-vga, -pcidevice, -mem-path
 -chardev, -balloon, -device, -rtc, -rtc-td-hack
 -no-hpet, -no-kvm-pit-reinjection, -tdf
 -fsdev -sdl

   

Most of these things can be associated with a config option and/or a
version.
 

If the 'qemu-config.c' file had parity with the config options
that were available as argv then I would not suggest including
the argv data at all.


I meant config-*.h. I can certainly imagine an query-config command to 
return a builtin copy of the build configuration.


If you know the qemu configuration along with the version, you basically 
know everything you need to know about the supported options (beyond 
what is configurable by the user).


Regards,

Anthony Liguori



  This patchset is an attempt to provide
all the information we need based on current state of the QEMU
codebase, since qemu-config is seriously incomplete at this time.
If we instead want to make a concerted effort to finish porting
all existing config options over to the new style qemu-config.c
format, that would definitely be much nicer than reporting about
argv.

Regards,
Daniel
   

[Qemu-devel] [PATCH 18/19] Add option to turn on JSON pretty printing in monitor

[Daniel P. Berrange]

Expaned '-mon' arg to allow a 'pretty=on' flag. This makes the
monitor pretty print its replies to easy human debugging / reading

Signed-off-by: Daniel P. Berrange 
---
 monitor.c |5 -
 monitor.h |1 +
 qemu-config.c |3 +++
 vl.c  |3 +++
 4 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/monitor.c b/monitor.c
index 39f8150..6203f75 100644
--- a/monitor.c
+++ b/monitor.c
@@ -341,7 +341,10 @@ static void monitor_json_emitter(Monitor *mon, const 
QObject *data)
 {
 QString *json;
 
-json = qobject_to_json(data);
+if (mon->flags & MONITOR_USE_PRETTY)
+   json = qobject_to_json_pretty(data);
+else
+   json = qobject_to_json(data);
 assert(json != NULL);
 
 qstring_append_chr(json, '\n');
diff --git a/monitor.h b/monitor.h
index 46b7a0e..733485f 100644
--- a/monitor.h
+++ b/monitor.h
@@ -14,6 +14,7 @@ extern Monitor *default_mon;
 #define MONITOR_IS_DEFAULT0x01
 #define MONITOR_USE_READLINE  0x02
 #define MONITOR_USE_CONTROL   0x04
+#define MONITOR_USE_PRETTY0x08
 
 /* QMP events */
 typedef enum MonitorEvent {
diff --git a/qemu-config.c b/qemu-config.c
index 925bd04..20ed8c2 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -362,6 +362,9 @@ QemuOptsList qemu_mon_opts = {
 },{
 .name = "default",
 .type = QEMU_OPT_BOOL,
+},{
+.name = "pretty",
+.type = QEMU_OPT_BOOL,
 },
 { /* end if list */ }
 },
diff --git a/vl.c b/vl.c
index 35d2b51..de010cc 100644
--- a/vl.c
+++ b/vl.c
@@ -2391,6 +2391,9 @@ static int mon_init_func(QemuOpts *opts, void *opaque)
 exit(1);
 }
 
+if (qemu_opt_get_bool(opts, "pretty", 0))
+flags |= MONITOR_USE_PRETTY;
+
 if (qemu_opt_get_bool(opts, "default", 0))
 flags |= MONITOR_IS_DEFAULT;
 
-- 
1.6.6.1

Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

As everyone here agrees, having management apps parse -help output
to determine the QEMU capabilities is not at all nice, because it
is an ill-defined&  fragile data format. Looking more broadly these
same issues apply to all the other command line options that accept
a '?' flag for querying capabilities.

We have a very nice structured data format we could be using for
this: JSON. What's lacking is code to output all this information
in the JSON format. This patch series can thus be summarized as
'JSON for everything'
   


I'm slightly skeptical that JSON is the right format for this TBH.


For reference, here is the full list of information libvirt currently
queries from QEMU:

   * Detection of command line flags (-help parsing)

 -no-kqemu, -no-kvm, -enable-kvm, -no-reboot
 -name, -uuid, -xen-domid, -domid, -drive
 -vga, -std-vga, -pcidevice, -mem-path
 -chardev, -balloon, -device, -rtc, -rtc-td-hack
 -no-hpet, -no-kvm-pit-reinjection, -tdf
 -fsdev -sdl
   


Most of these things can be associated with a config option and/or a 
version.



   * Detection of parameters (-help parsing)

  -drive format=
  -drive boot=
  -drive serial=
  -drive cache=
  -cpu cores=, threads=, sockets=
  -netdev vhost=
   


Likewise.


   * Detection of parameter values (-help parsing)

  -drive cache=writethrough|writeback|none
vs
  -drive cache=default|on|off
   


Same here.


   * Version number  (-help parsing)

 -netdev  + 0.13.0

 0.9.0  for VNC syntax

 0.10.0 for vnet hdr

   * Parse -M ?  output to get list of machine types + aliases
   


Yeah, it would be a good to have a qmp command to list supported machines.


   * Parse -device pci-assign,? to check for 'configfd' parameter

   * Parse -cpu ?  to get list of named CPU types
   


Would be good to have qmp for this too.


   * Parse binary name (qemu-system-) to guess arch of target
   


Same here.


This isn't an 100% exhaustive list of things that we would like
to be able to get access to though. It can likely cover all of
the following:

  * Version

   QEMU major, minor, micro numbers. KVM version. Package
   version

  * Devices

   List of device names. Parameter names. Parameter value
   data types. Allowed strings for enums

  * Arguments

   List of command line arguments. Parameter names. Parameter
   value data types. Allowed strings for enums
   


I'm a bit sceptical that this is the right thing to offer.

Generally speaking, libvirt is not going to be capable of handling every 
possible combination of qemu features.  Instead, for 0.12 it will use 
this set of functionality, for 0.13 it might use a different set.



  * Machine types

   List of names + aliases
   List of default devices in machine

  * CPU types

   List of names, associated feature flags, all allowed
   feature flags

  * Target info

   Arch name, wordsize

  * Monitor commands

   List of all monitor commands. Parameter names. Parameter
   value data types. Allowed strings for enums

  * Block device backends

   List of all block device backends. Parameter names.
   Parameter value data types. Allowed strings for enums

  * Netdev device backends

   List of all netdev device backends. Parameter names.
   Parameter value data types. Allowed strings for enums

  * Chardev device backends

   List of all chardev device backends. Parameter names.
   Parameter value data types. Allowed strings for enums


This patch series attempts to satisfy as much of this as is
feasible with the current QEMU codebase structure. The series
comprises four stages

  * Some basic infrastructure. Support for JSON pretty printing.
Introduction of standardized helpers for converting enums
to/from strings. Introduction of an 'enum' data type for
QemuOpt to expose a formal list of valid values&  simplify
config handling / parsing. Compile time assertion checking

  * Convert driver, netdev&  rtc config options to use the new
enum data type for all appropriate args

  * Add new QMP monitor commands exposing data for machine
types, devices, cpu types, arch target, argv, config params,
and netdev backends.

  * Add a new '-capabilities' command line arg as syntactic
sugar for the monitor commands that just report on static
info about the QEMU binary.

The main problem encountered with this patch series is the
split between argv and config parameters. The qemu-config.c
file provides the information is a good data format, allowing
programatic access to the list of parameters for each config
option (eg, the 'cache', 'file', 'aio', etc bits for -drive).
There are some issues with it though

  - It lacks a huge amount of coverage wrt to the full argv
available, even simple things like the '-m' argument
don't exist.

  - It is inconsistent in handling paramet

Re: [Qemu-devel] [PATCH 10/19] Add a query-machines command to QMP

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

Add a new QMP monitor command 'query-machines' to discover what
machines are defined in the QEMU binary. This is an easily
parsable replacement for 'qemu -M ?'

 [
 {
 "name": "pc-0.13",
 "description": "Standard PC",
 "default": 0
 },
 {
 "name": "pc",
 "description": "Standard PC",
 "canonical": "pc-0.13",
 "default": 1
 },
 {
 "name": "pc-0.12",
 "description": "Standard PC",
 "default": 0
 },
 
 ]

No legacy readline monitor output is provided.

In the future it would be desirable for each machine's QDict to
also include details of any qdev devices that are included by
default in the machine type.

Signed-off-by: Daniel P. Berrange
---
  hw/boards.h |1 +
  monitor.c   |9 +++
  vl.c|   70 +++
  3 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/hw/boards.h b/hw/boards.h
index 6f0f0d7..2f6003d 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -32,6 +32,7 @@ typedef struct QEMUMachine {
  } QEMUMachine;

  int qemu_register_machine(QEMUMachine *m);
+void do_info_machines(Monitor *mon, QObject **data);

  extern QEMUMachine *current_machine;

diff --git a/monitor.c b/monitor.c
index f0406e8..b6aa2b4 100644
--- a/monitor.c
+++ b/monitor.c
@@ -55,6 +55,7 @@
  #include "json-streamer.h"
  #include "json-parser.h"
  #include "osdep.h"
+#include "hw/boards.h"

  //#define DEBUG
  //#define DEBUG_COMPLETION
@@ -2449,6 +2450,14 @@ static const mon_cmd_t info_cmds[] = {
  .mhandler.info_new = do_info_version,
  },
  {
+.name   = "machines",
+.args_type  = "",
+.params = "",
+.help   = "show the machine boards",
+.user_print = monitor_user_noop,
+.mhandler.info_new = do_info_machines,
+},
+{
  .name   = "commands",
  .args_type  = "",
  .params = "",
diff --git a/vl.c b/vl.c
index 0b38d62..8043fac 100644
--- a/vl.c
+++ b/vl.c
@@ -1537,6 +1537,76 @@ static QEMUMachine *find_default_machine(void)
  return NULL;
  }

+
+/**
+ * do_info_machines(): Show machine boards
+ *
+ * Returns a QList object listing all machine boards
+ * available with this QEMU target. Each element in
+ * the list is a QDict object containing the following
+ * keys
+ *
+ *  - "name": short name for the machine board
+ *  - "description": long description of the board
+ *  - "alias": name of an alias
+ *
+ * Example:
+ *
+ *  [
+ * {
+ *   "name": "pc-0.13",
+ *"description": "Standard PC",
+ *"default": 0
+ * },
+ * {
+ *   "name": "pc",
+ *   "description": "Standard PC",
+ *   "canonical": "pc-0.13",
+ *   "default": 1
+ * },
+ * {
+ *   "name": "pc-0.12",
+ *   "description": "Standard PC",
+ *   "default": 0
+ * },
+ * 
+ *  ]
+ *
+ */
   


My only suggestion would be to:

{ 'default-machine': 'pc',
   'machines': [{
 'name': 'pc',
 'description': 'Standard PC',
   },...]
}

I'd drop 'canonical' too.  Aliasing is an implementation detail and 
should not be exposed via the ABI.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 11/19] Add a query-devices command to QMP

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

Adds a command to QMP called 'query-devices' to allow for discovery
of all devices known to the QEMU binary. THis is inteded to replace
use of the '-device ?' and '-device devtype,?' command line args

The data format is designed to allow easy extension to support more
data:
   


query-qdm?

Regards,

Anthony Liguori


 [
 {
 "name": "virtio-9p-pci",
 "creatable": true,
 "bus": "PCI",
 "props": [
 {
 "name": "indirect_desc",
 "type": "bit",
 "info": "on/off"
 },
 {
 "name": "mount_tag",
 "type": "string",
 "info": "string"
 },
 {
 "name": "fsdev",
 "type": "string",
 "info": "string"
 }
 ]
 },
 {
 "name": "virtio-balloon-pci",
 "creatable": true,
 "bus": "PCI",
 "props": [
 {
 "name": "indirect_desc",
 "type": "bit",
 "info": "on/off"
 }
 ]
 },
 ...
 ]

No legacy readline monitor output is provided.

Signed-off-by: Daniel P. Berrange
---
  hw/qdev.c |  146 +
  hw/qdev.h |2 +
  monitor.c |8 +++
  3 files changed, 156 insertions(+), 0 deletions(-)

diff --git a/hw/qdev.c b/hw/qdev.c
index 1186dfa..0a10c3c 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -29,6 +29,7 @@
  #include "qdev.h"
  #include "sysemu.h"
  #include "monitor.h"
+#include "qjson.h"

  static int qdev_hotplug = 0;

@@ -810,3 +811,148 @@ int do_device_del(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
  }
  return qdev_unplug(dev);
  }
+
+static const char *qdev_property_type_to_string(int type) {
+switch (type) {
+case PROP_TYPE_UNSPEC:
+   return "unknown";
+case PROP_TYPE_UINT8:
+   return "uint8";
+case PROP_TYPE_UINT16:
+   return "uint16";
+case PROP_TYPE_UINT32:
+   return "uint32";
+case PROP_TYPE_INT32:
+   return "int32";
+case PROP_TYPE_UINT64:
+   return "uint64";
+case PROP_TYPE_TADDR:
+   return "taddr";
+case PROP_TYPE_MACADDR:
+   return "macaddr";
+case PROP_TYPE_DRIVE:
+   return "drive";
+case PROP_TYPE_CHR:
+   return "chr";
+case PROP_TYPE_STRING:
+   return "string";
+case PROP_TYPE_NETDEV:
+   return "netdev";
+case PROP_TYPE_VLAN:
+   return "vlan";
+case PROP_TYPE_PTR:
+   return "pointer";
+case PROP_TYPE_BIT:
+   return "bit";
+}
+return NULL;
+}
+
+
+/*
+ * Describe capabilities of all devices registered with qdev
+ *
+ * The returned output is a QList, each element is a QDict
+ * describing a single device type. The valid keys for the
+ * device dictionary are
+ *
+ *  - "name": the short name of the device
+ *  - "bus": the name of the bus type for the device
+ *  - "alias": an alias by which the device is also known (optional)
+ *  - "description": a long description the device (optional)
+ *  - "props": a list of device properties
+ *  - "creatable": whether this device can be created on command line
+ *
+ * The 'props' list is a QList, with each element being a
+ * QDict describing a single property of the device. The
+ * valid property keys are
+ *
+ *  - "name": the short name of the property
+ *  - "info": short description of the property
+ *  - "type": the data type of the property value
+ *
+ * An example:
+ *
+ *   [
+ *   {
+ *   "name": "virtio-9p-pci",
+ *   "creatable": true,
+ *   "bus": "PCI",
+ *   "props": [
+ *   {
+ *   "name": "indirect_desc",
+ *   "type": "bit",
+ *   "info": "on/off"
+ *   },
+ *   {
+ *   "name": "mount_tag",
+ *   "type": "string",
+ *   "info": "string"
+ *   },
+ *   {
+ *   "name": "fsdev",
+ *   "type": "string",
+ *   "info": "string"
+ *   }
+ *   ]
+ *   },
+ *   {
+ *   "name": "virtio-balloon-pci",
+ *   "creatable": true,
+ *   "bus": "PCI",
+ *   "props": [
+ *   {
+ *   "name": "indirect_desc",
+ *   "type": "bit",
+ *   "info": "on/off"
+ *   }
+ *   ]
+ *   },
+ *   
+ *   ]
+ */
+void do_info_devices(Monitor *mon, QObject **data)
+{
+DeviceInfo *info;
+QList *devs = qlist_new();
+
+for (info = device_info_list; info != NULL; info = info->next) {
+   QObject *dev;
+   

[Qemu-devel] [PATCH 15/19] Expand query-argv to include help string

[Daniel P. Berrange]

This expands the query-argv data format to include the help
string for each argument. This is not really very desirable
since the help strings are not in a predictable format for apps
to use. Ideally the full structured details about each argument
parameter would be included instead. This makes the data format
look like

[
{
"name": "help",
"help": "-h or -help display this help and exit\n",
},
{
"name": "M",
"help": "-M machine  select emulated machine (-M ? for list)\n",
"parameters": [
]
},
]

Signed-off-by: Daniel P. Berrange 
---
 vl.c |   15 ---
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/vl.c b/vl.c
index a76c673..35d2b51 100644
--- a/vl.c
+++ b/vl.c
@@ -2030,14 +2030,14 @@ void do_info_argv(Monitor *mon, QObject **data)
const char *help;
 } options_help[] = {
 #define DEF(option, opt_arg, opt_enum, opt_help, arch_mask) \
-{ option, opt_arg },
+{ option, opt_arg, opt_help },
 #define DEFHEADING(text)
 #define HAS_ARG 1
 #include "qemu-options.h"
 #undef DEF
 #undef DEFHEADING
 #undef HAS_ARG
-   { NULL, 0 },
+   { NULL, 0, NULL },
 };
 int i;
 
@@ -2046,14 +2046,15 @@ void do_info_argv(Monitor *mon, QObject **data)
 
if (options_help[i].has_arg) {
/* XXX actually fill in the parameter details */
-   opt = qobject_from_jsonf("{ 'name': %s, 'parameters': [] }",
-options_help[i].name);
+   opt = qobject_from_jsonf("{ 'name': %s, 'help': %s, 'parameters': 
[] }",
+options_help[i].name,
+options_help[i].help);
} else {
-   opt = qobject_from_jsonf("{ 'name': %s }",
-options_help[i].name);
+   opt = qobject_from_jsonf("{ 'name': %s, 'help': %s }",
+options_help[i].name,
+options_help[i].help);
}
 
-
qlist_append_obj(args, opt);
 }
 
-- 
1.6.6.1

Re: [Qemu-devel] [PATCH 09/19] Change 'query-version' to output broken down version string

[Anthony Liguori]

On 06/07/2010 09:42 AM, Daniel P. Berrange wrote:

A previous discussion brought up the fact that clients should
not have to parse version string from QMP, it should be given
to them pre-split.

Change query-version output format from:

   { "qemu": "0.11.50", "package": "" }

to:

   { qemu: { "major": 0, "minor": 11, "micro": 5 }, "package": "" }
   


We need to drop package entirely.

Instead vendors should use the vendor specific namespace to extend the 
version.


I'd suggest changing the version output to:

{ 'major': 0, 'minor': 11, 'micro': 5 }

For something like kvm, it can introduce a '__org.linux-kvm.release', 2 
to that main dictionary.


Regards,

Anthony Liguori


The major, minor&  micro keys are all integer values. package is
an arbitrary string whose format is defined by the OS package
maintainer.

There is no need to preserve the existing string format of the 'qemu'
key, since QMP is not yet declared stable.

Signed-off-by: Daniel P. Berrange
---
  monitor.c |   47 +++
  1 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/monitor.c b/monitor.c
index 15b53b9..f0406e8 100644
--- a/monitor.c
+++ b/monitor.c
@@ -670,17 +670,56 @@ help:
  static void do_info_version_print(Monitor *mon, const QObject *data)
  {
  QDict *qdict;
+QDict *qemu;

  qdict = qobject_to_qdict(data);
+qemu = qdict_get_qdict(qdict, "qemu");

-monitor_printf(mon, "%s%s\n", qdict_get_str(qdict, "qemu"),
-  qdict_get_str(qdict, "package"));
+monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+  qdict_get_int(qemu, "major"),
+  qdict_get_int(qemu, "minor"),
+  qdict_get_int(qemu, "micro"),
+  qdict_get_str(qdict, "package"));
  }

+
+/**
+ * do_info_version(): Show QEMU version
+ *
+ * Return a QDict with the following information:
+ *
+ * - "qemu": QEMU upstream version
+ * - "package": QEMU packager's version
+ *
+ * The 'qemu' key value is a QDict containing three
+ * integer values
+ *
+ * - "major": QEMU's major version
+ * - "minor": QEMU's minor version
+ * - "micro": QEMU's micro version
+ *
+ * The 'package' key value is a string in an format
+ * defined by the OS distributor to reflect their
+ * packaging of QEMU.
+ *
+ * Example:
+ *
+ * { qemu: { "major": 0, "minor": 11, "micro": 5 }, "package": "" }
+ */
  static void do_info_version(Monitor *mon, QObject **ret_data)
  {
-*ret_data = qobject_from_jsonf("{ 'qemu': %s, 'package': %s }",
-   QEMU_VERSION, QEMU_PKGVERSION);
+const char *version = QEMU_VERSION;
+int major = 0, minor = 0, micro = 0;
+char *tmp;
+
+major = strtol(version,&tmp, 10);
+tmp++;
+minor = strtol(tmp,&tmp, 10);
+tmp++;
+micro = strtol(tmp,&tmp, 10);
+
+*ret_data = qobject_from_jsonf("{ 'qemu': { 'major': %d, 'minor': %d, 'micro': 
%d }, 'package': %s }",
+   major, minor, micro, QEMU_PKGVERSION);
  }

  static void do_info_name_print(Monitor *mon, const QObject *data)
   

[Qemu-devel] [PATCH 06/19] Convert drive options to use enumeration data type

[Daniel P. Berrange]

This converts the drive options if, trans, media, cache, aio,
rerror and werror to use the QEMU_OPT_ENUM datatype. This
standardizes the string parsing and error reporting

  $ qemu  -drive file=foo,werror=stop3
  qemu: -drive file=foo,if=mtd,werror=stop3: Parameter 'werror' expects report, 
ignore, enospc, stop

  $ qemu  -readconfig bar.cfg
  qemu:bar.cfg:6: Parameter 'werror' expects report, ignore, enospc, stop
  read config bar.cfg: Invalid argument

* block.c: Implementations for all enumerations
* block.h, sysemu.h: Declare enumerations
* qemu-config.c: Convert if, trans, media, cache, aio,
  rerror and werror to use the QEMU_OPT_ENUM
* vl.c: Remove handcrafted string -> int conversions in drive_init

Signed-off-by: Daniel P. Berrange 
---
 block.c   |   32 +++-
 block.h   |   55 +---
 hw/qdev.c |2 +-
 qemu-config.c |   73 +++---
 sysemu.h  |   23 +++--
 vl.c  |  162 -
 6 files changed, 197 insertions(+), 150 deletions(-)

diff --git a/block.c b/block.c
index 39724c1..7ca55e2 100644
--- a/block.c
+++ b/block.c
@@ -27,6 +27,7 @@
 #include "block_int.h"
 #include "module.h"
 #include "qemu-objects.h"
+#include "sysemu.h"
 
 #ifdef CONFIG_BSD
 #include 
@@ -42,6 +43,22 @@
 #include 
 #endif
 
+QEMU_ENUM_IMPL(bdrv_type, BDRV_TYPE_LAST,
+   "hd", "cdrom", "floppy");
+QEMU_ENUM_IMPL(bdrv_bios_ata_translation, BIOS_ATA_TRANSLATION_LAST,
+   "auto", "none", "lba", "large", "rechs");
+QEMU_ENUM_IMPL(bdrv_cache, BDRV_CACHE_LAST,
+   "none", "off", "writeback", "writethrough", "unsafe");
+QEMU_ENUM_IMPL(bdrv_if_type, IF_LAST,
+   "none", "ide", "scsi", "floppy", "pflash",
+   "mtd", "sd", "virtio", "xen");
+QEMU_ENUM_IMPL(bdrv_if_error_action, BLOCK_ERR_LAST,
+   "report", "ignore", "enospc", "stop");
+QEMU_ENUM_IMPL(bdrv_media, BDRV_MEDIA_LAST,
+   "disk", "cdrom");
+QEMU_ENUM_IMPL(bdrv_aio, BDRV_AIO_LAST,
+   "native", "threads");
+
 static BlockDriverAIOCB *bdrv_aio_readv_em(BlockDriverState *bs,
 int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
 BlockDriverCompletionFunc *cb, void *opaque);
@@ -1454,19 +1471,8 @@ void bdrv_info(Monitor *mon, QObject **ret_data)
 
 QTAILQ_FOREACH(bs, &bdrv_states, list) {
 QObject *bs_obj;
-const char *type = "unknown";
-
-switch(bs->type) {
-case BDRV_TYPE_HD:
-type = "hd";
-break;
-case BDRV_TYPE_CDROM:
-type = "cdrom";
-break;
-case BDRV_TYPE_FLOPPY:
-type = "floppy";
-break;
-}
+const char *type = bdrv_type_to_string(bs->type);
+assert(type != NULL);
 
 bs_obj = qobject_from_jsonf("{ 'device': %s, 'type': %s, "
 "'removable': %i, 'locked': %i }",
diff --git a/block.h b/block.h
index 756670d..11a029b 100644
--- a/block.h
+++ b/block.h
@@ -4,6 +4,7 @@
 #include "qemu-aio.h"
 #include "qemu-common.h"
 #include "qemu-option.h"
+#include "qemu-enum.h"
 #include "qobject.h"
 
 /* block.c */
@@ -128,14 +129,52 @@ int bdrv_has_zero_init(BlockDriverState *bs);
 int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors,
int *pnum);
 
-#define BDRV_TYPE_HD 0
-#define BDRV_TYPE_CDROM  1
-#define BDRV_TYPE_FLOPPY 2
-#define BIOS_ATA_TRANSLATION_AUTO   0
-#define BIOS_ATA_TRANSLATION_NONE   1
-#define BIOS_ATA_TRANSLATION_LBA2
-#define BIOS_ATA_TRANSLATION_LARGE  3
-#define BIOS_ATA_TRANSLATION_RECHS  4
+enum {
+BDRV_TYPE_HD,
+BDRV_TYPE_CDROM,
+BDRV_TYPE_FLOPPY,
+
+BDRV_TYPE_LAST
+};
+QEMU_ENUM_DECL(bdrv_type);
+
+enum {
+BIOS_ATA_TRANSLATION_AUTO,
+BIOS_ATA_TRANSLATION_NONE,
+BIOS_ATA_TRANSLATION_LBA,
+BIOS_ATA_TRANSLATION_LARGE,
+BIOS_ATA_TRANSLATION_RECHS,
+
+BIOS_ATA_TRANSLATION_LAST
+};
+QEMU_ENUM_DECL(bdrv_bios_ata_translation);
+
+enum {
+BDRV_CACHE_NONE,
+BDRV_CACHE_OFF,
+BDRV_CACHE_WRITEBACK,
+BDRV_CACHE_WRITETHROUGH,
+BDRV_CACHE_UNSAFE,
+
+BDRV_CACHE_LAST
+};
+QEMU_ENUM_DECL(bdrv_cache);
+
+enum {
+BDRV_MEDIA_DISK,
+BDRV_MEDIA_CDROM,
+
+BDRV_MEDIA_LAST
+};
+QEMU_ENUM_DECL(bdrv_media);
+
+enum {
+BDRV_AIO_NATIVE,
+BDRV_AIO_THREADS,
+
+BDRV_AIO_LAST
+};
+QEMU_ENUM_DECL(bdrv_aio);
 
 void bdrv_set_geometry_hint(BlockDriverState *bs,
 int cyls, int heads, int secs);
diff --git a/hw/qdev.c b/hw/qdev.c
index aa2ce01..1186dfa 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -414,7 +414,7 @@ void qdev_set_nic_properties(DeviceState *dev, NICInfo *nd)
 }
 }
 
-static int next_block_unit[IF_COUNT];
+static int next_block_unit[IF_LAST];
 
 /* Get a block device.  This should only be used for single-drive devices
(e.g. SD/Floppy/MTD).  Multi-disk devices (scsi/ide) should use the
diff --git a/qemu-co