Simply use consoles[] instead.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

I'm trying to improve this code's error reporting, and the debug code
is getting in my way: it clutters the code, it clobbers errno in
inconvenient places, and it uses the same fprintf() both for error
reporting and debug output in a few places.

Get rid of it.  Once decent error reporting is in place, adding back
whatever debug code we need shouldn't be hard.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Stash away the option argument with add_device_config(), so we still
have its location when we get around to parsing it.

This doesn't improve any messages I can see just yet, but that'll
change shortly.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

These are -bt, -serial, -virtcon, -parallel, -debugcon, -usbdevice.
Improves messages emitted via proper error reporting interfaces.  For
instance:

    $ qemu-system-x86_64 -nodefaults -S -usb -usbdevice net:vlan=xxx
    qemu-system-x86_64: Parameter 'vlan' expects a number

becomes:

    qemu-system-x86_64: -usbdevice net:vlan=xxx: Parameter 'vlan' expects a number

Many more remain unimproved, because they're fprintf()ed.  The next
few commits will take care of that.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Cleaned up silently in commit aad04cd0, but that just got reverted.
Re-apply this part.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Fixed silently in commit aad04cd0, but that just got reverted.
Re-apply the fixes, plus one missed instance: parport on Linux.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The commit's purpose is laudable:

    The only way for chardev drivers to communicate an error was to
    return a NULL pointer, which resulted in an error message that
    said _that_ something went wrong, but not _why_.

It attempts to achieve it by changing the interface to return 0/-errno
and update qemu_chr_open_opts() to use strerror() to display a more
helpful error message.  Unfortunately, it has serious flaws:

1. Backends "socket" and "udp" return bogus error codes, because
qemu_chr_open_socket() and qemu_chr_open_udp() assume that
unix_listen_opts(), unix_connect_opts(), inet_listen_opts(),
inet_connect_opts() and inet_dgram_opts() fail with errno set
appropriately.  That assumption is wrong, and the commit turns
unspecific error messages into misleading error messages.  For
instance:

    $ qemu-system-x86_64 -nodefaults -vnc :0 -chardev socket,id=bar,host=xxx
    inet_connect: host and/or port not specified
    chardev: opening backend "socket" failed: No such file or directory

ENOENT is what happens to be in my errno when the backend returns
-errno.  Let's put ERANGE there just for giggles:

    $ qemu-system-x86_64 -nodefaults -vnc :0 -chardev socket,id=bar,host=xxx -drive if=none,iops=99999999999999999999
    inet_connect: host and/or port not specified
    chardev: opening backend "socket" failed: Numerical result out of range

Worse: when errno happens to be zero, return -errno erroneously
signals success, and qemu_chr_new_from_opts() dies dereferencing
uninitialized chr.  I observe this with "-serial unix:".

2. All qemu_chr_open_opts() knows about the error is an errno error
code.  That's simply not enough for a decent message.  For instance,
when inet_dgram() can't resolve the parameter host, which errno code
should it use?  What if it can't resolve parameter localaddr?

Clue: many backends already report errors in their open methods.
Let's revert the flawed commit along with its dependencies, and fix up
the silent error paths instead.

This reverts commit 6e1db57b.

Conflicts:

	console.c
	hw/baum.c
	qemu-char.c

This reverts commit aad04cd0.

The parts of commit db418a0a "Add stdio char device on windows" that
depend on the reverted change fixed up.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In the old implementation, if the new value of the property links
to the same object, as the old value, that object is first unref-ed,
and then ref-ed. This leads to unintended deinitialization of that object.

In the new implementation, this is fixed.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlexander Barabash <alexander_barabash@mentor.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This should have no visible effect, but it should just clean up the
config file a bit.

This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.

Changes v1 -> v2:
 - Rebase against latest Qemu git tree
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Version 1 of this patch was:

Message-Id: <1307041990-26194-11-git-send-email-ehabkost@redhat.com
http://marc.info/?l=qemu-devel&m=130704415919346

This version doesn't have the duplicate feature bits on extfeature_edx, though,
as they are being removed from the Intel models (as they are reserved bits on
Intel CPUs).

Version 1 patch description:

    This patch adds Westmere as a qemu cpu model.  The only
    additional guest visible feature of a Westmere relative
    to Nehalem is the inclusion of AES instructions.  However
    as other non-ABI visible modifications exist along with
    fabrication changes, the CPUID data of the corresponding
    deployed silicon was altered slightly to reflect this.

    We've seen isolated cases where apparently unrelated yet
    slightly incoherent CPUID data has caused problems, most
    notably during guest boot.  Providing Westmere as a
    model separate fro Nehalem allows us to more easily address
    such quirks.

    [ehabkost: edited commit message to have a better Subject line]
Signed-off-by: Njohn cooper <john.cooper@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Changes version 1 -> version 2:
 - Remove the duplicate feature bits on extfeature_edx, that are
   reserved on Intel CPUs
 - Reorder feature flags
 - Remove x2apic from the definition because x2apic requires some fixes
   that have to be resubmitted
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This patch removes the replicated feature flags from cpuid 8000_0001:edx
(extfeature_edx) from Intel models, as the duplicated feature flags are present
only on AMD CPUs. On Intel models, only the i64, syscall, and xd flags are kept
on extfeature_edx.

This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.

Original John's patch description was:

    cpu model bug fixes and definition corrections

    This patch was intended to address the replicated feature
    flags in cpuid 8000_0001:edx from cpuid 0000_0001:edx.
    This is due to AMD's definition where these flags are
    mostly cloned in the 8000_0001:edx cpuid function.
    qemu64 attempted to glue together the respective Intel
    and AMD nearly disjoint features and this propagated to
    the new Intel models as doing so was believed conservative
    at the time.  However after further soak and test lugging
    around this cruft doesn't provide any value, could
    conceivably confuse a guest, and has confused users trying
    to maintain/add cpu definitions.  This also caused issues
    for libvirt attempting to track this mis-encoding.

    So we've here tossed out the AMD replicated definitions
    from the Intel models, added a few replications into AMD
    definitions which were missing according to AMD's latest
    CPUID document, and reordered the config file flags to
    follow intuitive sequential bit ordering.  Also two flag
    name aliases were added for clarity to Intel models.  The
    end result being the models definitions now conform to
    their respective cpuid specifications sans x2apic which is
    emulated by kvm.

    This was tested with the following combinations:

        [Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
        [Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host

    Yielding successful boots in all cases.
Signed-off-by: Njohn cooper <john.cooper@redhat.com>

Changes v1 -> v2:
 - Rebase against latest Qemu git tree
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This patch adds some missing flags to extfeature_edx, that were missing
according to AMD's latest CPUID document.

This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.

Original John's patch description was:

    cpu model bug fixes and definition corrections

    This patch was intended to address the replicated feature
    flags in cpuid 8000_0001:edx from cpuid 0000_0001:edx.
    This is due to AMD's definition where these flags are
    mostly cloned in the 8000_0001:edx cpuid function.
    qemu64 attempted to glue together the respective Intel
    and AMD nearly disjoint features and this propagated to
    the new Intel models as doing so was believed conservative
    at the time.  However after further soak and test lugging
    around this cruft doesn't provide any value, could
    conceivably confuse a guest, and has confused users trying
    to maintain/add cpu definitions.  This also caused issues
    for libvirt attempting to track this mis-encoding.

    So we've here tossed out the AMD replicated definitions
    from the Intel models, added a few replications into AMD
    definitions which were missing according to AMD's latest
    CPUID document, and reordered the config file flags to
    follow intuitive sequential bit ordering.  Also two flag
    name aliases were added for clarity to Intel models.  The
    end result being the models definitions now conform to
    their respective cpuid specifications sans x2apic which is
    emulated by kvm.

    This was tested with the following combinations:

        [Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
        [Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host

    Yielding successful boots in all cases.
Signed-off-by: Njohn cooper <john.cooper@redhat.com>

Changes v1 -> v2:
 - Rebase against latest Qemu git tree
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Use 'i64' instead of 'lm' and 'xd' instead of 'nx' on Intel models.

The flags have different names on Intel docs, so use those names for clarity.

This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.

Changes v1 -> v2:
 - Rebase patch against latest Qemu git tree
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

pclmulqdq: /proc/cpuinfo on Linux and all documentation I have seen uses
pclmulqdq as the flag name. As the only document using pclmuldq seems to
be the Intel CPUID documentation (Application Note 485), it looks like a
typo and not the correct name for the flag.

ffxsr: AMD docs refer to fxsr_opt as ffxsr, so allow this named to be
used too.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This will make it easier to review and change the flag list in the future.

No behaviour change should be introduced by this, as it is just changing
the flag order on the config file.

To make sure the flag sets are really not changed by this patch, I have
used the following stupid script to compare the flag values in the
config files:
https://gist.github.com/1004885Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This has been the de facto situation for a while now.
Add a tree, too.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Tested-by: NAndreas F=E4rber <afaerber@suse.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Make qemu-bridge-helper explicitly depend on $(GENERATED_HEADERS)
so that it doesn't fail to build when we configured for linux-user
targets only. (Build breakage introduced in commit 7b93fadf.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Make kernel, initrd, append be machine opts (ie -machine kernel=foo)
with the old plain command line arguments as legacy/convenience
equivalents.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NHervé Poussineau <hpoussin@reactos.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Some simplifications in I/O functions are possible because
Jazz LED only registers one byte of I/O.
Signed-off-by: NHervé Poussineau <hpoussin@reactos.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NHervé Poussineau <hpoussin@reactos.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Assert the object is at least sizeof(Object), not sizeof(ObjectClass).
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

As we make upper bits in IO and prefetcheable memory
registers writeable, we should declare support
for 64 bit prefetcheable memory and 32 bit io
in the bridge.

This changes the default for apb, dec, but I'm guessing
they got the defaults wrong by accident.
Alternatively, we could let bridges declare lack of
64 bit support and make the upper bits read-only zero.

With this applied, we can drop these bits
from express code.
Reported-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Could someone familiar with apb,dec ack this please?
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

pci_regs.h specifies many registers by mask +
shifted register values.
There's always some duplication when using such:
for example to override device type, we would need:

pci_word_test_and_clear_mask(cap + PCI_EXP_FLAGS,
     PCI_EXP_FLAGS_TYPE);
pci_word_test_and_set_mask(cap + PCI_EXP_FLAGS,
    PCI_EXP_TYPE_ENDPOINT << (ffs(PCI_EXP_FLAGS_TYPE) - 1));

Getting such registers also uses some duplication:

word = pci_get_word(cap + PCI_EXP_FLAGS) & PCI_EXP_FLAGS_TYPE;
if ((word >> ffs((PCI_EXP_FLAGS_TYPE) - 1)) == PCI_EXP_TYPE_ENDPOINT)

Add API to access such registers in one line:
pci_set_word_by_mask(cap + PCI_EXP_FLAGS, PCI_EXP_FLAGS_TYPE,
		     PCI_EXP_TYPE_ENDPOINT)

and
word = pci_get_word_by_mask(cap + PCI_EXP_FLAGS, PCI_EXP_FLAGS_TYPE)
if (word == PCI_EXP_TYPE_ENDPOINT)
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

object_property_add_child() creates a property whose values as a string is
the child object's canonical path.
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlexander Barabash <alexander_barabash@mentor.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Now, the pc-sysfw:rom_only property will default
to false which enables flash by default.

All pc types below pc-1.1 set rom_only to true.
This prevents flash from being enabled on these
pc machine types.

For pc-1.1 rom_only will use the default (false),
which will allow flash to be used for pc-1.1.
Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Flash can be enabled by calling pc_system_firmware_init
with the system_flash_enabled parameter being non-zero.
If system_flash_enabled is zero, then the older qemu
rom creation method will be used.

If flash is enabled and a pflash image is found, then
it is used for the system firmware image.

If flash is enabled and a pflash image is not initially
found, then a read-only pflash device is created using
the -bios filename.

KVM cannot execute from a pflash region currently.
Therefore, when KVM is enabled, the old rom based
initialization method is used.
Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Setup a pc-sysfw device type.  It contains a single
property of 'rom_only' which is defaulted to enabled.
Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

* bonzini/qdev-props-for-anthony:
  qdev: drop unnecessary parse/print methods
  qdev: use built-in QOM string parser
  qdev: accept hex properties only if prefixed by 0x
  qdev: accept both strings and integers for PCI addresses
  qom: add generic string parsing/printing
  qapi: add tests for string-based visitors
  qapi: add string-based visitors
  qapi: drop qmp_input_end_optional
  qapi: allow sharing enum implementation across visitors

More qdev printers could have been removed in the previous series, and
object_property_parse also made several parsers unnecessary.  In fact,
the new code is even more robust with respect to overflows, so clean
them up!
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>