Now that smbios has its own directory, list its
maintainers. Same people as ACPI so just reuse that
entry.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

To share smbios among different architectures, this patch moves SMBIOS
code (smbios.c and smbios.h) from x86 specific folders into new
hw/smbios directories. As a result, CONFIG_SMBIOS=y is defined in
x86 default config files.
Acked-by: NGabriel Somlo <somlo@cmu.edu>
Tested-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NWei Huang <wei@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Current smbios builds type 19 table from e820, which is x86 specific.
This patch removes smbios' dependency on e820 by passing an array
of memory area to smbios_get_tables().
Acked-by: NGabriel Somlo <somlo@cmu.edu>
Tested-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NWei Huang <wei@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This patch extracts out the procedure of buidling x86 SMBIOS tables
into a dedicated function.
Acked-by: NGabriel Somlo <somlo@cmu.edu>
Tested-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NWei Huang <wei@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When building QEMU with Mingw64 toolchain I see a warning

 CC    x86_64-softmmu/hw/i386/acpi-build.o
  hw/i386/acpi-build.c: In function 'acpi_build':
  hw/i386/acpi-build.c:1138:9: warning: 'pm.cpu_hp_io_base' may be used uninitialized in this function [-Wmaybe-uninitialized]
           aml_append(crs,
           ^
  hw/i386/acpi-build.c:1666:16: note: 'pm.cpu_hp_io_base' was declared here
       AcpiPmInfo pm;
                  ^

In acpi_get_pm_info() some of the fields are pre-initialized
to 0, but this one was missed.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

After commit 40bad8f3("virtio-net: fix
used len for tx"), async_tx.len was no longer used afterwards. So
remove useless codes with it.
Signed-off-by: NJason Wang <jasowang@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Some kernels program a 0 address for io regions. PCI 3.0 spec
section 6.2.5.1 doesn't seem to disallow this.

based on patch by Michael Roth <mdroth@linux.vnet.ibm.com>

Add pci_allow_0_addr in MachineClass to conditionally
allow addr 0 for pseries, as this can break other architectures.

This patch allows to hotplug PCI card in pseries machine, as the first
added card BAR0 is always set to 0 address.

This as a temporary hack, waiting to fix PCI memory priorities for more
machine types...
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Remove arguments that can be found in PCMachineState.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Remove arguments that can be found in PCMachineState.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Remove arguments that can be found in PCMachineState.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This will make the info readily available for the other initialization
functions, and will allow us to simplify their argument list.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

pc_memory_init() already expects a PCMachineState object, there's no
point in upcasting it to MachineState before calling the function.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

pc_cmos_init() already expects a PCMachineState object, there's no point
in upcasting it to MachineState before calling the function.

While doing it, reorder the arguments so PCMachineState is the first
function argument.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The only PC machines that didn't call pc_default_machine_options() were
isaps and xenfv. Both were already overwriting max_cpus, and only isapc
was not overwriting hot_add_cpu.

After making isapc set hot_add_cpu to NULL, we can move the
pc_default_machine_options() code the PC common class_init.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

All TYPE_PC_MACHINE subclasses call pc_common_machine_options().
TYPE_PC_MACHINE can simply initialize the common options on class_init
directly.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

They will be used inside hw/xen/xen.h, which doesn't include
hw/i386/pc.h.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Make the code use the same variable name everywhere. "pcms" is already
being used in existing code and it's shorter.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

No errors should happen when registering the properties, but we
shouldn't silently ignore them if they happen.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The function is not used by PC code anymore and can be removed.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Now we can use compat_props to keep CPUID feature compatibility, using
the boolean QOM properties for CPUID feature flags.

This simplifies the compatibility code, and reduces duplication between
pc_piix.c and pc_q35.c.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The existing i440fx initialization code sets a PCI config register that
isn't documented anywhere in the Intel 440FX datasheet. Register 0x57 is
DRAMC (DRAM Control) and has nothing to do with the RAM size.

This was implemented in commit ec5f92ce
because old coreboot code tried to read registers 0x5a-0x5f,0x56,0x57 to
get the RAM size from QEMU, but I couldn't find out why coreboot did
that. I assume it was a mistake, and the original code was supposed to
be reading the DRB[0-7] registers (offsets 0x60-0x67).

Document that coreboot-specific register offset in a macro and a
comment, for future reference.

Cc: Ed Swierk <eswierk@skyportsystems.com>
Cc: Richard Smith <smithbone@gmail.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The old rules.mak loads dependency .d files using include directive
with file glob pattern "*.d". This breaks the build when build tree has
left-over *.d files from another build.

This patch fixes this by
  - loading precise list of .d files made from *.o and *.mo.
  - specifying explicit list of required dependency info files for
     *.hex autogenerated sources.

Note that Makefile still includes some .d in root directory by including
"*.d".
Signed-off-by: NVictor Kaplansky <victork@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

In rules like "bar/%.o: %.c" there is a difference between $(*D) and
$(@D). $(*D) expands to '.', while $(@D) expands to 'bar'.  It is
cleaner to generate *.d in the same directory where appropriate *.o
resides. This allows precise including of dependency info from .d files.

As a hack, we also touch two sources for generated *.hex files.  Without
this hack, anyone doing "git pull; make" will not get *.hex rebuilt
correctly since the dependency file would be missing.
Signed-off-by: NVictor Kaplansky <victork@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

virtio fix for 2.4

Fixes migration in virtio 1 mode.
We still have a known bug with memory hotplug, it doesn't
look like we can fix that in time for 2.4.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Wed 05 Aug 2015 15:57:39 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"

* remotes/mst/tags/for_upstream:
  virtio: fix 1.0 virtqueue migration
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Commit 488981a4 [block: convert quorum blockdrv to use crypto APIs]
broke qemu-iotest 041 on hosts with GnuTLS < 2.10.0. It converted a
compile-time check to a run-time check at device open time. The result
is that we now advertise a feature (the quorum block driver) that will
never work (on those hosts). There's no way (short of parsing
human-readable error messages) for qemu-iotests or any other API
consumer to recognise that the quorum block driver isn't _actually_
available and shouldn't be used or tested.

Move the run-time check to bdrv_quorum_init() to avoid registering the
quorum block driver if we know it cannot work. This way API consumers
can recognise it's unavailable.

Fixes: 488981a4Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Message-id: 1438699705-21761-1-git-send-email-silbe@linux.vnet.ibm.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

1.0 does not requires physically-contiguous pages layout for a
virtqueue. So we could not infer avail and used from desc. This means
we need to migrate vring.avail and vring.used when host support virtio
1.0. This fixes malfunction of virtio 1.0 device after migration.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

X86 queue, 2015-08-04

# gpg: Signature made Tue 04 Aug 2015 16:49:42 BST using RSA key ID 984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/x86-pull-request:
  target-i386: fix IvyBridge xlevel in PC_COMPAT_2_3
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Previous patch changed xlevel and missed the compatibility code.

Fixes: 3046bb5d ("target-i386: emulate CPUID level of real hardware")
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

MIPS patches 2015-08-04

Changes:
* fix semihosting for microMIPS R6
* fix an abort when booting mips64 kernel with --enable-tcg-debug

# gpg: Signature made Tue 04 Aug 2015 12:32:17 BST using RSA key ID 0B29DA6B
# gpg: Good signature from "Leon Alrae <leon.alrae@imgtec.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8DD3 2F98 5495 9D66 35D4  4FC0 5211 8E3C 0B29 DA6B

* remotes/lalrae/tags/mips-20150804:
  target-mips: Copy restrictions from ext/ins to dext/dins
  target-mips: fix semihosting for microMIPS R6
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The checks in dins is required to avoid triggering an assertion
in tcg_gen_deposit_tl.  The check in dext is just for completeness.
Fold the other D cases in via fallthru.

In this case the errant dins appears to be data, not code, as
translation failed to stop after a break insn.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>
Reviewed-by: NLeon Alrae <leon.alrae@imgtec.com>
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>

In semihosting mode the SDBBP 1 instructions should trigger UHI syscall,
but in QEMU this does not happen for recently added microMIPS R6.
Consequently bare metal microMIPS R6 programs supporting UHI will not run.
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>

cve-2015-5166

# gpg: Signature made Mon 03 Aug 2015 15:27:44 BST using RSA key ID 70E1AE90
# gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"

* remotes/sstabellini/tags/cve-2015-5166-tag:
  Fix release_drive on unplugged devices (pci_piix3_xen_ide_unplug)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

xen-migration-2.4

# gpg: Signature made Mon 03 Aug 2015 17:18:36 BST using RSA key ID 70E1AE90
# gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"

* remotes/sstabellini/tags/xen-migration-2.4-tag:
  migration: Fix regression for xenfv and pc,accel=xen machine.
  migration: Fix global state with Xen.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This fix migration from the same QEMU version and from previous QEMU
version.

>From the global state section, we don't need runstate with Xen. Right now,
the way the Xen toolstack knows when QEMU is ready is when QEMU reach
"running" runstate.

The configuration section and the section footers are not going to be
present in previous version of QEMU with xenfv machine, so we skip them.

The Xen toolstack libxenlight does not specify a particular version of the
'pc' machine, so migration from older version of QEMU used by Xen to newer
one would break due to missing "configuration" section and section footers.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the receiver side.

During migration, the Xen toolstack paused QEMU before save the devices
state. Also, the toolstack expect QEMU to autostart when the migration is
finished.
So this patch store "running" as it's current runstate.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

Commit 8e9b0d24 (ui: convert VNC websockets to use crypto APIs) dropped
the --enable-vnc-ws option but forgot to update the help text. Fix this.

Cc: Daniel P. Berrange <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1437749257-3313-1-git-send-email-afaerber@suse.de
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

pci_piix3_xen_ide_unplug should completely unhook the unplugged
IDEDevice from the corresponding BlockBackend, otherwise the next call
to release_drive will try to detach the drive again.
Suggested-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>