Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Since ich9_lpc_pm_init only requests one irq, so let it just call
qemu_allocate_irq.
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Since pc_allocate_cpu_irq only requests one irq, so let it just call
qemu_allocate_irq.
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

valgrind complains about:
==7055== 58 bytes in 1 blocks are definitely lost in loss record 1,471 of 2,192
==7055==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7055==    by 0x24410F: malloc_and_trace (vl.c:2556)
==7055==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x64DEFD7: g_strndup (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x650181A: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x64DF0CC: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x64DF188: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.3600.3)
==7055==    by 0x242F81: qemu_find_file (vl.c:2121)
==7055==    by 0x217A32: clipper_init (dp264.c:105)
==7055==    by 0x2484DA: main (vl.c:4249)
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

valgrind complains about:
==9276== 13 bytes in 1 blocks are definitely lost in loss record 1,046 of 3,673
==9276==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9276==    by 0x2EAFBB: malloc_and_trace (vl.c:2556)
==9276==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==9276==    by 0x4A28BD: addr_to_string (vnc.c:123)
==9276==    by 0x4A29AD: vnc_socket_local_addr (vnc.c:139)
==9276==    by 0x4A9AFE: vnc_display_local_addr (vnc.c:3240)
==9276==    by 0x2EF4FE: main (vl.c:4321)
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

There is no reason for device tree API to be built per-target.
common-obj it. There is an extraneous inclusion of config.h that
needs to be removed.

Cc: Alexander Graf <agraf@suse.de>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

valgrind complains about:
==16447== 48 bytes in 2 blocks are definitely lost in loss record 2,033 of 3,310
==16447==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==    by 0x2E4FD7: malloc_and_trace (vl.c:2546)
==16447==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16447==    by 0x53EC3F: qint_from_int (qint.c:33)
==16447==    by 0x53B426: qmp_output_type_int (qmp-output-visitor.c:162)
==16447==    by 0x539257: visit_type_uint32 (qapi-visit-core.c:147)
==16447==    by 0x471D07: property_get_uint32_ptr (object.c:1651)
==16447==    by 0x47000C: object_property_get (object.c:822)
==16447==    by 0x472428: object_property_get_qobject (qom-qobject.c:37)
==16447==    by 0x25701A: build_append_pci_bus_devices (acpi-build.c:520)
==16447==    by 0x25902E: build_ssdt (acpi-build.c:1004)
==16447==    by 0x25A0A8: acpi_build (acpi-build.c:1420)
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

valgrind complains about:
==16447== 16 bytes in 2 blocks are definitely lost in loss record 1,304 of 3,310
==16447==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==    by 0x2E4FD7: malloc_and_trace (vl.c:2546)
==16447==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16447==    by 0x36FB47: qemu_extend_irqs (irq.c:55)
==16447==    by 0x36FBD3: qemu_allocate_irqs (irq.c:64)
==16447==    by 0x3B4B44: bmdma_init (pci.c:464)
==16447==    by 0x3B547B: pci_piix_init_ports (piix.c:144)
==16447==    by 0x3B55D2: pci_piix_ide_realize (piix.c:164)
==16447==    by 0x3EAEC6: pci_qdev_realize (pci.c:1790)
==16447==    by 0x36C685: device_set_realized (qdev.c:1058)
==16447==    by 0x47179E: property_set_bool (object.c:1514)
==16447==    by 0x470098: object_property_set (object.c:837)
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

valgrind complains about:
==16447== 8 bytes in 1 blocks are definitely lost in loss record 552 of 3,310
==16447==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==    by 0x2E4FD7: malloc_and_trace (vl.c:2546)
==16447==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16447==    by 0x36FB47: qemu_extend_irqs (irq.c:55)
==16447==    by 0x36FBD3: qemu_allocate_irqs (irq.c:64)
==16447==    by 0x24E622: pc_init1 (pc_piix.c:287)
==16447==    by 0x24E76A: pc_init_pci (pc_piix.c:310)
==16447==    by 0x2E9360: main (vl.c:4226)

==16447== 128 bytes in 1 blocks are definitely lost in loss record 2,569 of 3,310
==16447==    at 0x4C2845D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==    by 0x2E4FD7: malloc_and_trace (vl.c:2546)
==16447==    by 0x64C770E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
==16447==    by 0x36FB47: qemu_extend_irqs (irq.c:55)
==16447==    by 0x36FBD3: qemu_allocate_irqs (irq.c:64)
==16447==    by 0x25BEB2: kvm_i8259_init (i8259.c:133)
==16447==    by 0x24E1F1: pc_init1 (pc_piix.c:219)
==16447==    by 0x24E76A: pc_init_pci (pc_piix.c:310)
==16447==    by 0x2E9360: main (vl.c:4226)
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

s/interation/iteration
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

The 'socket_optslist' structure does not contain the 'localaddr' and
'localport' options that are parsed in case you are creating a
'connect' type UDP character device.

I've noticed it happening after commit f43e47db
made qemu abort() after seeing the invalid option.

A minimal reproducer for the case is:
$ qemu-system-x86_64 -chardev udp,id=charrng0,host=127.0.0.1,port=1234,localaddr=,localport=1234
qemu-system-x86_64: -chardev udp,id=charrng0,host=127.0.0.1,port=1234,localaddr=,localport=1234: Invalid parameter 'localaddr'
Aborted (core dumped)

Prior to the commit mentioned above the error would be printed but the
value for localaddr and localport was simply ignored. I did not go
through the code to find out when it was broken.

Add the two fields so that the options can again be parsed correctly and
qemu doesn't abort().

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1220252Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Just fallback on the default of 12 like other architectures. This
allows changing the system-mode-affecting definition of
TARGET_PAGE_BITS without affecting microblaze linux-user.
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

raw_bsd already has QEMU_BUILD_BUG_ON(BDRV_SECTOR_SIZE != 512), so iscsi
should relax.
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

XSA 128 129 130 131

# gpg: Signature made Tue Jun  2 16:46:38 2015 BST using RSA key ID 70E1AE90
# gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"

* remotes/sstabellini/tags/xen-15-06-02-tag:
  xen/pt: unknown PCI config space fields should be read-only
  xen/pt: add a few PCI config space field descriptions
  xen/pt: mark reserved bits in PCI config space fields
  xen/pt: mark all PCIe capability bits read-only
  xen/pt: split out calculation of throughable mask in PCI config space handling
  xen/pt: correctly handle PM status bit
  xen/pt: consolidate PM capability emu_mask
  xen/MSI: don't open-code pass-through of enable bit modifications
  xen/MSI-X: limit error messages
  xen: don't allow guest to control MSI mask register
  xen: properly gate host writes of modified PCI CFG contents
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

... by default. Add a per-device "permissive" mode similar to pciback's
to allow restoring previous behavior (and hence break security again,
i.e. should be used only for trusted guests).

This is part of XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>)

Since the next patch will turn all not explicitly described fields
read-only by default, those fields that have guest writable bits need
to be given explicit descriptors.

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>

The adjustments are solely to make the subsequent patches work right
(and hence make the patch set consistent), namely if permissive mode
(introduced by the last patch) gets used (as both reserved registers
and reserved fields must be similarly protected from guest access in
default mode, but the guest should be allowed access to them in
permissive mode).

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>

xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
only to avoid unintended write-back (just a precaution, the field ought
to be read-only in hardware).

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

This is just to avoid having to adjust that calculation later in
multiple places.

Note that including ->ro_mask in get_throughable_mask()'s calculation
is only an apparent (i.e. benign) behavioral change: For r/o fields it
doesn't matter > whether they get passed through - either the same flag
is also set in emu_mask (then there's no change at all) or the field is
r/o in hardware (and hence a write won't change it anyway).

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com>

xen_pt_pmcsr_reg_write() needs an adjustment to deal with the RW1C
nature of the not passed through bit 15 (PCI_PM_CTRL_PME_STATUS).

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
emu_mask variable - we can have the same effect by setting the field
descriptor's emu_mask member suitably right away. Note that
xen_pt_pmcsr_reg_write() is being retained in order to allow later
patches to be less intrusive.

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NIan Campbell <ian.campbell@citrix.com>

Without this the actual XSA-131 fix would cause the enable bit to not
get set anymore (due to the write back getting suppressed there based
on the OR of emu_mask, ro_mask, and res_mask).

Note that the fiddling with the enable bit shouldn't really be done by
qemu, but making this work right (via libxc and the hypervisor) will
require more extensive changes, which can be postponed until after the
security issue got addressed.

This is a preparatory patch for XSA-131.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

Limit error messages resulting from bad guest behavior to avoid allowing
the guest to cause the control domain's disk to fill.

The first message in pci_msix_write() can simply be deleted, as this
is indeed bad guest behavior, but such out of bounds writes don't
really need to be logged.

The second one is more problematic, as there guest behavior may only
appear to be wrong: For one, the old logic didn't take the mask-all bit
into account. And then this shouldn't depend on host device state (i.e.
the host may have masked the entry without the guest having done so).
Plus these writes shouldn't be dropped even when an entry is unmasked.
Instead, if they can't be made take effect right away, they should take
effect on the next unmasking or enabling operation - the specification
explicitly describes such caching behavior. Until we can validly drop
the message (implementing such caching/latching behavior), issue the
message just once per MSI-X table entry.

Note that the log message in pci_msix_read() similar to the one being
removed here is not an issue: "addr" being of unsigned type, and the
maximum size of the MSI-X table being 32k, entry_nr simply can't be
negative and hence the conditonal guarding issuing of the message will
never be true.

This is XSA-130.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

It's being used by the hypervisor. For now simply mimic a device not
capable of masking, and fully emulate any accesses a guest may issue
nevertheless as simple reads/writes without side effects.

This is XSA-129.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

The old logic didn't work as intended when an access spanned multiple
fields (for example a 32-bit access to the location of the MSI Message
Data field with the high 16 bits not being covered by any known field).
Remove it and derive which fields not to write to from the accessed
fields' emulation masks: When they're all ones, there's no point in
doing any host write.

This fixes a secondary issue at once: We obviously shouldn't make any
host write attempt when already the host read failed.

This is XSA-128.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

This fixes a compile warning from clang 3.5 (the assertion
could never fire).
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com>
Message-id: 1432881807-18164-2-git-send-email-edgar.iglesias@gmail.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
[PMM: added note in commit message that this is fixing a build warning]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

virtio-input: two small fixups

# gpg: Signature made Tue Jun  2 09:32:51 2015 BST using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"

* remotes/kraxel/tags/pull-input-20150602-1:
  virtio-input: make virtio devices follow usual naming convention
  virtio-input: const_le16 and const_le32 not build time constant
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

pc build fix

My last pull breaks build on systems with iasl.
Fix this up.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Mon Jun  1 20:41:08 2015 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:
  acpi: add missing ssdt
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

As the implementation of const_le16 and const_le32 is not build time constant
on big endian systems this need to be fixed.

  CC    hw/input/virtio-input-hid.o
hw/input/virtio-input-hid.c:340:13: error: initializer element is not constant
hw/input/virtio-input-hid.c:340:13: error: (near initialization for ‘virtio_keyboard_config[1].u.ids.bustype’)
...
Signed-off-by: NMichael Mueller <mimu@linux.vnet.ibm.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

commit 5cb18b3d
    TPM2 ACPI table support

was missing a file, so build with iasl fails
(build without iasl works since it uses the generated
 hex files).
Reported-by: N"Daniel P. Berrange" <berrange@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

pc, pci, tpm, virtio, vhost enhancements and fixes

A bunch of cleanups and fixes all over the place,
enhancements in TPM, virtio and vhost.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Mon Jun  1 13:19:48 2015 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: (60 commits)
  vhost-user: add multi queue support
  virtio: make features 64bit wide
  qdev: add 64bit properties
  virtio-mmio: ioeventfd support
  hw/acpi/aml-build: Fix memory leak
  acpi: add aml_while() term
  acpi: add aml_increment() term
  acpi: add aml_shiftright() term
  acpi: add aml_shiftleft() term
  acpi: add aml_index() term
  acpi: add aml_lless() term
  acpi: add aml_add() term
  TPM2 ACPI table support
  tpm: Probe for connected TPM 1.2 or TPM 2
  Extend TPM TIS interface to support TPM 2
  Add stream ID to MSI write
  acpi: Simplify printing to dynamic string
  i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wanted
  i386/pc_q35: don't insist on board FDC if there's no default floppy
  i386/pc: '-drive if=floppy' should imply a board-default FDC
  ...
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Based on patch by Nikolay Nikolaev:
Vhost-user will implement the multi queue support in a similar way
to what vhost already has - a separate thread for each queue.
To enable the multi queue functionality - a new command line parameter
"queues" is introduced for the vhost-user netdev.
Signed-off-by: NNikolay Nikolaev <n.nikolaev@virtualopensystems.com>
Signed-off-by: NChangchun Ouyang <changchun.ouyang@intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Make features 64bit wide everywhere.

On migration a full 64bit guest_features field is sent if one of the
high bits is set, in addition to the lower 32bit guest_features field
which must stay for compatibility reasons.  That way we send the lower
32 feature bits twice, but the code is simpler because we don't have
to split and compose the 64bit features into two 32bit fields.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Needed for virtio features which go from 32bit to 64bit with virtio 1.0
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

set_host_notifier and set_guest_notifiers supported by virtio-mmio now.
Most code copied from virtio-pci.

This makes it possible to use vhost-net with virtio-mmio,
improving performance by about 30%.

The kvm-arm does not yet support irqfd, need to fix the hard-coded part after
kvm-arm gets irqfd support.
Signed-off-by: NYing-Shiuan Pan <yingshiuan.pan@gmail.com>
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>