Commit Graph

23112 Commits

Author SHA1 Message Date
Greg Kurz
5cf0d326a0 spapr_pci: Fix extended config space accesses
The PAPR PHB acts as a legacy PCI bus but it allows PCIe extended
config space accesses anyway (for pseries-2.9 and newer machine
types).

Introduce a specific PCI bus subtype to inform the common PCI code
about that.

Fixes: c2077e2ca0
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155414130834.574858.16502276132110219890.stgit@bahia.lan>
[dwg: Apply fix so we don't rename the default pci bus, breaking everything]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-04-09 15:03:10 +10:00
Greg Kurz
1c685a9026 pci: Allow PCI bus subtypes to support extended config space accesses
Some PHB implementations, eg. PAPR used on pseries machine, act like
a regular PCI bus rather than a PCIe bus, but allow access to the
PCIe extended config space anyway.

Introduce a new PCI bus class method to modelize this behaviour and
use it when adjusting the config space size limit during accesses.

No behaviour change for existing PCI bus types.

Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155414130271.574858.4253514266378127489.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-04-09 09:14:47 +10:00
Peter Maydell
f55a585d10 pci, pc, virtio: fixes
intel-iommu fixes
 virtio typo fixes
 linker: a couple of asserts for consistency/security
 
 Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
 -----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJco4T3AAoJECgfDbjSjVRpjQEIAJCV8n+KFTXhFYxLkVmmp9K6
 d4QMXvd8MSP/zJwjBFhCHX+pi0N+HrKzTf5c1fqY0FtWGg0cT4rZam+7gX4QlCxH
 fJ4de3cs2qit3FbkSjwHbao+uha/Nzso79XXkQsTkMdhmq+W1xLM4QbVa+RyGb+f
 UjpYSX0kD6go8B7kAUB5PyGMAsNBL2drj/Er8v7vMu7ai1ti7DnmBPITY9bHgAld
 PdMEN79BI5Sz+WHiaG5AVagFxh1iAdHVcjlx5xNncuZrZPKW2I847lzK5GLzchav
 mBRts8xOjOwEdCt02K8aAv9PXidc7SiNvZqf1CpGt6mH2REhl+FWkbfJZSTswV4=
 =gH9R
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

pci, pc, virtio: fixes

intel-iommu fixes
virtio typo fixes
linker: a couple of asserts for consistency/security

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Tue 02 Apr 2019 16:51:19 BST
# gpg:                using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream:
  intel_iommu: Drop extended root field
  intel_iommu: Fix root_scalable migration breakage
  virtio-net: Fix typo in comment
  intel_iommu: Correct caching-mode error message
  acpi: verify file entries in bios_linker_loader_add_pointer()

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-07 14:54:55 +01:00
Peter Maydell
10546e09e1 RISC-V Patches for 4.0-rc3, v2
This patch set contains a pair of tightly coupled PLIC bug fixes:
 
 * We were calculating the PLIC addresses incorrectly.
 * We were installing the wrong number of PLIC interrupts.
 
 The two bugs togther resulted in a mostly-working system, but they're
 impossible to seperate because fixing one bug would result in
 significant breakage.  As a result they're in the same patch.
 
 There is also a cleanup to use qemu_log_mask(LOG_GUEST_ERROR,...) for
 error reporting.
 
 As far as I know these are the last outstanding RISC-V patches for 4.0.
 
 v2 no longer fails "make check" for me... sorry!
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAlymonUTHHBhbG1lckBk
 YWJiZWx0LmNvbQAKCRDvTKFQLMurQX+kD/wIOSTb7ZBAu5Jbs9JckaGhom9Kfu1+
 D9Pxs+QHnXxvxzksTYIWtOVJ8otYvoz/zt8OntbBO9J5eHeHe5aQQ1B+L8+2+Z8Z
 yVcKwu7UPHTY0u6gsE7tAGIhw/pPK+bSM0BA7jOTV6VB4wjLB4KnHbNZytiBTgg7
 OzFDqxCgjva8lNjjUJO1vfdGBHfacHEEfVOGxWkotaXw6mXaSzd+lbPGtnwLsca+
 NJOObR5Z25BIzS7R8Ud9epT84sK/iwffbZbfEUZ/cIu3Ghd57xl0diieZGCBJ5Xf
 6Ngq8Pae6hP0mK4DhpKdN+OMpEqX95Vd+azBxxOLY2ITNaKC+v68t6k58a/kTL77
 reBAGU8VKgcHTFx1atG7Sbfq/aOm53McVHOleWZL4W+peqhH2z5TUcGrSfvhIs/4
 4rp7d2zo4J7R42TI2RO8HeLF9+fX857Qwz4GICaFrSZ5m7eoiZirt27YzjUutf6b
 D1wTb0ZEJh3b2WZrne+mrV0p/nT1lgCk5byOjk20RTXeWVC5zEX8JiMt47qx1VVx
 1KvnNy35aGUc872Fsa7zNvtErBXQ7UosuWZlLQh1dLBPXQ85/YY6W9fkgYLc8/LD
 Lc5W6kf3vfWYajeVYLpFB/kF9QuU3f0OzZrnG+K/Vr68IhBuPlJTox7vQERlmp2S
 bRzEh/91Indv0w==
 =APjM
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.0-rc3-v2' into staging

RISC-V Patches for 4.0-rc3, v2

This patch set contains a pair of tightly coupled PLIC bug fixes:

* We were calculating the PLIC addresses incorrectly.
* We were installing the wrong number of PLIC interrupts.

The two bugs togther resulted in a mostly-working system, but they're
impossible to seperate because fixing one bug would result in
significant breakage.  As a result they're in the same patch.

There is also a cleanup to use qemu_log_mask(LOG_GUEST_ERROR,...) for
error reporting.

As far as I know these are the last outstanding RISC-V patches for 4.0.

v2 no longer fails "make check" for me... sorry!

# gpg: Signature made Fri 05 Apr 2019 01:33:57 BST
# gpg:                using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
# gpg:                issuer "palmer@dabbelt.com"
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown]
# gpg:                 aka "Palmer Dabbelt <palmer@sifive.com>" [unknown]
# 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: 00CE 76D1 8349 60DF CE88  6DF8 EF4C A150 2CCB AB41

* remotes/palmer/tags/riscv-for-master-4.0-rc3-v2:
  riscv: plic: Log guest errors
  riscv: plic: Fix incorrect irq calculation

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-05 04:50:30 +01:00
Alistair Francis
79bcac250f
riscv: plic: Log guest errors
Instead of using error_report() to print guest errors let's use
qemu_log_mask(LOG_GUEST_ERROR,...) to log the error.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-04 16:36:21 -07:00
Alistair Francis
0feb4a7129
riscv: plic: Fix incorrect irq calculation
This patch fixes four different things, to maintain bisectability they
have been merged into a single patch. The following fixes are below:

sifive_plic: Fix incorrect irq calculation
The irq is incorrectly calculated to be off by one. It has worked in the
past as the priority_base offset has also been set incorrectly. We are
about to fix the priority_base offset so first first the irq
calculation.

sifive_u: Fix PLIC priority base offset and numbering
According to the FU540 manual the PLIC source priority address starts at
an offset of 0x04 and not 0x00. The same manual also specifies that the
PLIC only has 53 source priorities. Fix these two incorrect header
files.

We also need to over extend the plic_gpios[] array as the PLIC sources
count from 1 and not 0.

riscv: sifive_e: Fix PLIC priority base offset
According to the FE31 manual the PLIC source priority address starts at
an offset of 0x04 and not 0x00.

riscv: virt: Fix PLIC priority base offset
Update the virt offsets based on the newly updated SiFive U and SiFive E
offsets.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-04 16:36:19 -07:00
Paul Durrant
2bcd05cf24 xen-block: scale sector based quantities correctly
The Xen blkif protocol requires that sector based quantities should be
interpreted strictly as multiples of 512 bytes. Specifically:

"first_sect and last_sect in blkif_request_segment, as well as
sector_number in blkif_request, are always expressed in 512-byte units."

Commit fcab2b464e "xen: add header and build dataplane/xen-block.c"
incorrectly modified behaviour to use the block device logical_block_size
property as the scale, instead of correctly shifting values by the
hardcoded BDRV_SECTOR_BITS (and hence scaling them to 512 byte units).
This patch undoes that change and restores compliance with the spec.

Furthermore, this patch also restores the original xen_disk behaviour
of advertizing a hardcoded 'sector-size' value of 512 in xenstore and
scaling 'sectors' accordingly. The realize() method is also modified to
fail if logical_block_size is set to anything other than 512.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190401121719.27208-1-paul.durrant@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-04-04 18:00:07 +01:00
Paul Durrant
15f084505a xen-block: only advertize discard to the frontend when it is enabled...
...and properly enable it when synthesizing a drive.

The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
to enable discard on a specified image. The code in
xen_block_drive_create() correctly parses this and uses it to set
'discard' to 'unmap' for the file_layer, but fails to do the same for the
driver_layer (which effectively disables it). Meanwhile the code in
xen_block_realize() advertizes discard support to the frontend in the
default case (because conf->discard_granularity defaults to -1), even when
the underlying image may not handle it.

This patch adds the missing option to the driver_layer in
xen_block_driver_create() and checks whether BDRV_O_UNMAP is actually
set on the block device before advertizing discard to the frontend.
In the case that discard is supported it also makes sure that the
granularity is set to the physical block size.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190320142825.24565-1-paul.durrant@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-04-04 12:41:23 +01:00
Daniel P. Berrangé
7357b22159 hw/s390x/3270-ccw: avoid taking address of fields in packed struct
Compiling with GCC 9 complains

hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’:
hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
   81 |         SCSW *s = &sch->curr_status.scsw;
      |                   ^~~~~~~~~~~~~~~~~~~~~~

This local variable is only present to save a little bit of
typing when setting the field later. Get rid of this to avoid
the warning about unaligned accesses.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190329111104.17223-15-berrange@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03 11:19:57 +02:00
Daniel P. Berrangé
5d45a33292 hw/s390x/ipl: avoid taking address of fields in packed struct
Compiling with GCC 9 complains

hw/s390x/ipl.c: In function ‘s390_ipl_set_boot_menu’:
hw/s390x/ipl.c:256:25: warning: taking address of packed member of ‘struct QemuIplParameters’ may result in an unaligned pointer value [-Waddress-of-packed-member]
  256 |     uint32_t *timeout = &ipl->qipl.boot_menu_timeout;
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

This local variable is only present to save a little bit of
typing when setting the field later. Get rid of this to avoid
the warning about unaligned accesses.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190329111104.17223-14-berrange@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03 11:19:57 +02:00
Daniel P. Berrangé
bea0279b72 hw/s390/css: avoid taking address members in packed structs
The GCC 9 compiler complains about many places in s390 code
that take the address of members of the 'struct SCHIB' which
is marked packed:

hw/s390x/css.c: In function ‘sch_handle_clear_func’:
hw/s390x/css.c:698:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer val\
ue [-Waddress-of-packed-member]
  698 |     PMCW *p = &sch->curr_status.pmcw;
      |               ^~~~~~~~~~~~~~~~~~~~~~
hw/s390x/css.c:699:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer val\
ue [-Waddress-of-packed-member]
  699 |     SCSW *s = &sch->curr_status.scsw;
      |               ^~~~~~~~~~~~~~~~~~~~~~

...snip many more...

Almost all of these are just done for convenience to avoid
typing out long variable/field names when referencing struct
members. We can get most of this convenience by taking the
address of the 'struct SCHIB' instead, avoiding triggering
the compiler warnings.

In a couple of places we copy via a local variable which is
a technique already applied elsewhere in s390 code for this
problem.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190329111104.17223-13-berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03 11:19:57 +02:00
Daniel P. Berrangé
e1d0b37261 hw/vfio/ccw: avoid taking address members in packed structs
The GCC 9 compiler complains about many places in s390 code
that take the address of members of the 'struct SCHIB' which
is marked packed:

hw/vfio/ccw.c: In function ‘vfio_ccw_io_notifier_handler’:
hw/vfio/ccw.c:133:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value \
[-Waddress-of-packed-member]
  133 |     SCSW *s = &sch->curr_status.scsw;
      |               ^~~~~~~~~~~~~~~~~~~~~~
hw/vfio/ccw.c:134:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value \
[-Waddress-of-packed-member]
  134 |     PMCW *p = &sch->curr_status.pmcw;
      |               ^~~~~~~~~~~~~~~~~~~~~~

...snip many more...

Almost all of these are just done for convenience to avoid
typing out long variable/field names when referencing struct
members. We can get most of this convenience by taking the
address of the 'struct SCHIB' instead, avoiding triggering
the compiler warnings.

In a couple of places we copy via a local variable which is
a technique already applied elsewhere in s390 code for this
problem.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190329111104.17223-12-berrange@redhat.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03 11:19:57 +02:00
Peter Xu
81fb1e646e intel_iommu: Drop extended root field
VTD_RTADDR_RTT is dropped even by the VT-d spec, so QEMU should
probably do the same thing (after all we never really implemented it).
Since we've had a field for that in the migration stream, to keep
compatibility we need to fill the hole up.

Please refer to VT-d spec 10.4.6.

Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20190329061422.7926-3-peterx@redhat.com>
Reviewed-by: Liu, Yi L <yi.l.liu@intel.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02 11:49:14 -04:00
Peter Xu
2811af3b49 intel_iommu: Fix root_scalable migration breakage
When introducing the initial support for scalable mode we added a
new field into vmstate however we blindly migrate that field without
notice.  That'll break migration no matter forward or backward.

The normal way should be that we use something like
VMSTATE_UINT32_TEST() or subsections for the new vmstate field however
for this case of vt-d we can even make it simpler because we've
already migrated all the registers and it'll be fairly simple that we
re-generate root_scalable field from the register values during post
load of the device.

Fixes: fb43cf739e ("intel_iommu: scalable mode emulation")
Reviewed-by: Yi Sun <yi.y.sun@linux.intel.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20190329061422.7926-2-peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02 11:49:14 -04:00
Yuval Shaia
20f86a75a7 virtio-net: Fix typo in comment
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Message-Id: <20190321161832.10533-1-yuval.shaia@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02 11:49:14 -04:00
Alex Williamson
75c5626c88 intel_iommu: Correct caching-mode error message
If we try to use the intel-iommu device with vfio-pci devices without
caching mode enabled, we're told:

  qemu-system-x86_64: We need to set caching-mode=1 for intel-iommu to enable
  device assignment with IOMMU protection.

But to enable caching mode, the option is actually "caching-mode=on".

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <155364147432.16467.15898335025013220939.stgit@gimli.home>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Alex Williamson &lt;<a href="mailto:alex.williamson@redhat.com" target="_blank" rel="noreferrer">alex.williamson@redhat.com</a>&gt;<br>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02 11:49:14 -04:00
Liam Merwick
22132828d1 acpi: verify file entries in bios_linker_loader_add_pointer()
The callers to bios_linker_find_file() assert that the file entry returned
is not NULL, except for those in bios_linker_loader_add_pointer().  Add two
asserts in that case for completeness and to facilitate static code analysis.

Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-Id: <1553199229-25318-1-git-send-email-liam.merwick@oracle.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02 11:49:14 -04:00
Daniel P. Berrangé
b4682a63f8 filemon: fix watch IDs to avoid potential wraparound issues
Watch IDs are allocated from incrementing a int counter against
the QFileMonitor object. In very long life QEMU processes with
a huge amount of USB MTP activity creating & deleting directories
it is just about conceivable that the int counter can wrap
around. This would result in incorrect behaviour of the file
monitor watch APIs due to clashing watch IDs.

Instead of trying to detect this situation, this patch changes
the way watch IDs are allocated. It is turned into an int64_t
variable where the high 32 bits are set from the underlying
inotify "int" ID. This gives an ID that is guaranteed unique
for the directory as a whole, and we can rely on the kernel
to enforce this. QFileMonitor then sets the low 32 bits from
a per-directory counter.

The USB MTP device only sets watches on the directory as a
whole, not files within, so there is no risk of guest
triggered wrap around on the low 32 bits.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-02 13:52:02 +01:00
Bandan Das
b396733df3 usb-mtp: remove usb_mtp_object_free_one
This function is used in the delete path only and can
be replaced by a call to usb_mtp_object_free.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bandan Das <bsd@redhat.com>
Message-Id: <20190401211712.19012-3-bsd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-04-02 07:22:49 +02:00
Bandan Das
4bc1591681 usb-mtp: fix return status of delete
Spotted by Coverity: CID 1399414

mtp delete allows the return status of delete succeeded,
partial_delete or readonly - when none of the objects could be
deleted. Give more meaningful names to return values of the
delete function.

Some initiators recurse over the objects themselves. In that case,
only READ_ONLY can be returned.

Signed-off-by: Bandan Das <bsd@redhat.com>
Message-Id: <20190401211712.19012-2-bsd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-04-02 07:22:40 +02:00
Peter Maydell
5189e30b14 hw/usb/bus.c: Handle "no speed matched" case in usb_mask_to_str()
In usb_mask_to_str() we convert a mask of USB speeds into
a human-readable string (like "full+high") for use in
tracing and error messages. However the conversion code
doesn't do anything to the string buffer if the passed in
speedmask doesn't match any of the recognized speeds,
which means that the tracing and error messages will
end up with random garbage in them. This can happen if
we're doing USB device passthrough.

Handle the "unrecognized speed" case by using the
string "unknown".

Fixes: https://bugs.launchpad.net/qemu/+bug/1603785
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20190328133503.6490-1-peter.maydell@linaro.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-04-01 08:53:44 +02:00
Gerd Hoffmann
28605a22f5 Revert "audio: fix pc speaker init"
This reverts commit bd56d37884.

Turned out it isn't that simple as the device needs the pit object link.
So "-device isa-pcspk" isn't going wo work anyway.  We are in freeze, so
just reverting the thing is the best way to handle this for now, trying
to come up with something better can be done in the 4.1 devel cycle.

Also add a comment noting the object link.

Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20190328071121.21147-1-kraxel@redhat.com
2019-04-01 08:53:40 +02:00
Peter Maydell
c503849bb5 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
 
 iQEcBAABAgAGBQJcncmSAAoJEO8Ells5jWIRh8YH/2EXWKEBlN1TSWZQrL3ifq+4
 OS1335yGK34uQrZEvhgpGlHDuvwUn+1ma8YHgkpGGohQaOb91FqDZLQi6aZ1/XBX
 2aLt46XSgvp3y9EO2dVeFepW2dTyAPZMCkWEvJINXpRQQ6X2iu0iDjZoqB3aA8dU
 UP8I3FsoFOg4A2haiMxBgGhldf9VCAJtoKrMoxOOgDhCypwZPqSlmRn3QeqO0MmG
 aVDt5MBqKIXMmG2cUDy+KvsylGXtZ9VisvIU4UAIJaUGEopuYygEYQQhETN9uAXK
 ts6yWdfAU438NcNoFnChrNeHwQS8TuZlV1pcV7xQ2gaKB1cS3I+MGWOzTTWD/zs=
 =4PKd
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging

# gpg: Signature made Fri 29 Mar 2019 07:30:26 GMT
# gpg:                using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal]
# 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: 215D 46F4 8246 689E C77F  3562 EF04 965B 398D 6211

* remotes/jasowang/tags/net-pull-request:
  net: tap: use qemu_set_nonblock
  MAINTAINERS: Update the latest email address
  e1000: Delay flush queue when receive RCTL
  net/socket: learn to talk with a unix dgram socket

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-29 11:51:54 +00:00
yuchenlin
157628d067 e1000: Delay flush queue when receive RCTL
Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32 guest.
In our environment, we have 10 win10x32 and stress power cycle.
The problem will happen about 20 rounds.

Below shows some log with comment:

The normal case:

22831@1551928392.984687:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928392.985655:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928392.985801:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.056710:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.077548:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 2, ICR 0, IMR 0
e1000: set_ics 2, ICR 2, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.102974:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928393.103267:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle
RX now
e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt
e1000: RCTL: 255, mac_reg[RCTL] = 0x48002
e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work!
...

The bad case:

27744@1551930483.117766:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
27744@1551930483.118398:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.198063:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.218675:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 2, ICR 0, IMR 0
e1000: set_ics 2, ICR 2, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.241768:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
27744@1551930483.241979:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle
RX now
e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting RCTL)
e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 0x82&0x9d
!= 0 generate interrupt, hang on here...

To workaround this problem, simply delay flush queue. Also stop receiving
when timer is going to run.

Tested on CentOS, Win7SP1x64 and Win10x32.

Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Dmitry Fleytman <dmitry.fleytman@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2019-03-29 15:22:18 +08:00
Cédric Le Goater
273fef83f6 spapr/irq: Add XIVE sanity checks on non-P9 machines
On non-P9 machines, the XIVE interrupt mode is not advertised, see
spapr_dt_ov5_platform_support(). Add a couple of checks on the machine
configuration to filter bogus setups and prevent OS failures :

                     Interrupt modes

  CPU/Compat      XICS    XIVE                dual

   P8/P8          OK      QEMU failure (1)    OK (3)
   P9/P8          OK      QEMU failure (2)    OK (3)
   P9/P9          OK      OK                  OK

  (1) CPU exception model is incompatible with XIVE and the presenters
      will fail to realize.

  (2) CPU exception model is compatible with XIVE, but the XIVE CAS
      advertisement is dropped when in POWER8 mode. So we could ended up
      booting with the XIVE DT properties but without the HCALLs. Avoid
      confusing Linux with such settings and fail under QEMU.

  (3) force XICS in machine init

Remove the check on XIVE-only machines in spapr_machine_init(), which
has now become redundant.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190328100044.11408-1-clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-29 10:38:20 +11:00
David Gibson
0a794529bd spapr: Simplify handling of host-serial and host-model values
27461d69a0 "ppc: add host-serial and host-model machine attributes
(CVE-2019-8934)" introduced 'host-serial' and 'host-model' machine
properties for spapr to explicitly control the values advertised to the
guest in device tree properties with the same names.

The previous behaviour on KVM was to unconditionally populate the device
tree with the real host serial number and model, which leaks possibly
sensitive information about the host to the guest.

To maintain compatibility for old machine types, we allowed those props
to be set to "passthrough" to take the value from the host as before.  Or
they could be set to "none" to explicitly omit the device tree items.

Special casing specific values on what's otherwise a user supplied string
is very ugly.  So, this patch simplifies things by implementing the
backwards compatibility in a different way: we have a machine class flag
set for the older machines, and we only load the host values into the
device tree if A) they're not set by the user and B) we have that flag set.

This does mean that the "passthrough" functionality is no longer available
with the current machine type.  That's ok though: if a user or management
layer really wants the information passed through they can read it
themselves (OpenStack Nova already does something similar for x86).

It also means the user can't explicitly ask for the values to be omitted
on the old machine types.  I think that's an acceptable trade-off: if you
care enough about not leaking the host information you can either move to
the new machine type, or use a dummy value for the properties.

For the new machine type, this also removes an odd inconsistency
between running on a POWER and non-POWER (or non-Linux) hosts: if the
host information couldn't be read from where we expect (in the host's
device tree as exposed by Linux), we'd fallback to omitting the guest
device tree items.

While we're there, improve some poorly worded comments, and the help text
for the properties.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Greg Kurz <groug@kaod.org>
2019-03-29 10:25:50 +11:00
Greg Kurz
d0db7caddb target/ppc: Consolidate 64-bit server processor detection in a helper
We use PPC_SEGMENT_64B in various places to guard code that is specific
to 64-bit server processors compliant with arch 2.x. Consolidate the
logic in a helper macro with an explicit name.

Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155327783157.1283071.3747129891004927299.stgit@bahia.lan>
Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-29 10:22:22 +11:00
Peter Maydell
84bdc58c06 * Kconfig improvements (msi_nonbroken, imply for default PCI devices)
* intel-iommu: sharing passthrough FlatViews (Peter)
 * Fix for SEV with VFIO (Brijesh)
 * Allow compilation without CONFIG_PARALLEL (Thomas)
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAlyTvvAUHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroNNwwf/RrtjBoqu8Ulu6k+HJczdpkhO44c5
 R7sidGaOBHVjT+EsaYZxanXQlsbpDPiXCRoMRMln+O3Kgso/UlVTLBfctIjuf5kp
 P8Amp8rw843yl3TQ+Xaqat1qtfVVN2xjRDoyRwWrTU5w52MVVsan2j1/XzGX/7Bb
 Y3gXRxsN7MyjDCXxhxVwQCxKU2ue3ytvnfdCnu1SNZxZEaFAyGprTNCCTXYugehl
 bVauAs/0qOZWEyvElinNEz+zbqMTm07ULAWBRXgCDcOudsidZFtu0Xl62dXlp1Ou
 0zkaoGiOdMM6OXZkLd6vOK8mY9XDuqaUZE3zAeFMJsK1wSnZdGUVCJO1Hw==
 =Pkcj
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

* Kconfig improvements (msi_nonbroken, imply for default PCI devices)
* intel-iommu: sharing passthrough FlatViews (Peter)
* Fix for SEV with VFIO (Brijesh)
* Allow compilation without CONFIG_PARALLEL (Thomas)

# gpg: Signature made Thu 21 Mar 2019 16:42:24 GMT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini/tags/for-upstream: (23 commits)
  virtio-vga: only enable for specific boards
  config-all-devices.mak: rebuild on reconfigure
  minikconf: fix parser typo
  intel-iommu: optimize nodmar memory regions
  test-announce-self: convert to qgraph
  hw/alpha/Kconfig: DP264 hardware requires e1000 network card
  hw/hppa/Kconfig: Dino board requires e1000 network card
  hw/sh4/Kconfig: r2d machine requires the rtl8139 network card
  hw/ppc/Kconfig: e500 based machines require virtio-net-pci device
  hw/ppc/Kconfig: Bamboo machine requires e1000 network card
  hw/mips/Kconfig: Fulong 2e board requires ati-vga/rtl8139 PCI devices
  hw/mips/Kconfig: Malta machine requires the pcnet network card
  hw/i386/Kconfig: enable devices that can be created by default
  hw/isa/Kconfig: PIIX4 southbridge requires USB UHCI
  hw/isa/Kconfig: i82378 SuperIO requires PC speaker device
  prep: do not select I82374
  hw/i386/Kconfig: PC uses I8257, not I82374
  hw/char/parallel: Make it possible to compile also without CONFIG_PARALLEL
  target/i386: sev: Do not pin the ram device memory region
  memory: Fix the memory region type assignment order
  ...

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

# Conflicts:
#	hw/rdma/Makefile.objs
#	hw/riscv/sifive_plic.c
2019-03-28 09:18:53 +00:00
Peter Maydell
905870b53c fixes for 4.0: ohci and ati-vga
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABAgAGBQJcmjG0AAoJEEy22O7T6HE4SQ0P/1gAKVtOJxlmDGkxjtDB8mse
 1euAPsPiYzz5kdEJvbt392iUBPT9K0YdV4kknYV5d9r4i51WlBLsQ6EJI7YCFn33
 fqkuvoUW2E0Nnbqtft0RG34sncitZ0Gf8SSXwd7R9tjdAec7Xujpm1Xxgh90exBf
 O7VmXGorhNgtrDaMroHtdGEA4QbYDSG/qqzdOe+WO4weVHnVOUjpnaI3zHcMDkKz
 cpuY6egtzsUuK8+4UmUZAbt62Nww9LvIfzT15JDvh4lFoEz7RumeAskW1R/PDeU1
 tMS9c2SBSY8Ow7bVyHZRGuG7+e9CGZW6/EuBfJfS6KgOcd13k73oDxDgXb+tkGMQ
 321V0bYKwGSdIudVvHMVt4Q8mo5eN9YREZ2A2MnnSqzRQrS37stWaXDFhImIl+5m
 s44wFbVLvNE3banH/U8g/pnwxbT6ly1XMp6sg45GxBgJgdHhbnY6ukjNIQV8B9E/
 ABY0oi2DA6LVKGJyDPgLwTpOTpN/68x2kg48g2CXhyPN8Os7NhMh0q9NcTczGdMv
 +a/wxFVF9TKy3ppdjQcWbVqYPEXZ6WH/wd/HaPrrcS5lP6JUkCBiwP2qfOlQFPbx
 uMo/2bht6Jm0yxsbS9rC+Jdi5YZB2SxWwMnxrwQDKIEH7k2eBQdVwoQwPtRHXTWC
 q/acSeoRs4sT8WofM6cZ
 =kkCx
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/kraxel/tags/fixes-20190326-pull-request' into staging

fixes for 4.0: ohci and ati-vga

# gpg: Signature made Tue 26 Mar 2019 14:05:40 GMT
# gpg:                using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full]
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>" [full]
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/fixes-20190326-pull-request:
  ati-vga: Fix indexed access to video memory
  ohci: don't die on ED_LINK_LIMIT overflow

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26 14:11:00 +00:00
BALATON Zoltan
339534d402 ati-vga: Fix indexed access to video memory
Coverity (CID 1399700) found that this was wrong so instead of trying
to do it by hand use existing access functions that should work better.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-id: 20190318223842.427CB7456B2@zero.eik.bme.hu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-03-26 12:06:49 +01:00
Laurent Vivier
ab8789987f ohci: don't die on ED_LINK_LIMIT overflow
Stop processing the descriptor list instead. The next frame timer tick will
resume the work

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-id: 20190321085212.10796-1-lvivier@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-03-26 12:01:45 +01:00
Peter Maydell
527266f324 Pflash and firmware configuration patches for 2019-03-26
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJcmdLpAAoJEDhwtADrkYZTYZEP/iTvwRlatm2D6aN4tdkerXsu
 acKXlL+JPHMqNy4g/bSiJ9lw6JMK1fiQRL+7v/RARiUCtDVmmrV6zzdH/0u4JqmI
 cixSVVRnFEcy6Q4ex4J97APOKcTH1G5+s1Tq8bHz3NitKMGyeDd9CwmdP2k0lrU6
 981eUfjsfqXxxrJdxT3iZ3VqU/vxxUL1nUL/sn1pivmMiWD0D1opw6cmgzylsEYx
 FxcWzieXrYxJfnvxWX6MtoNxsZqSqWHWlecDwAVFJ1OUVLxyd47h+9f54asYZefF
 bFoVNN2Yz6TPFnuF1S4WgMfyUE2UYPo7pN/OasPcnKjL5VLHOy+wayQx+YeC5PYz
 cnBfXV3Z9TOi+AINhKCDYxUX+WT0cpjqFdSWfqIBWz+4hKOsUoiCNvc+GjOO4nWg
 OA4A6zT8XQ9JipvhZvwWmb+cWFZNUBbJqewlWOBxh9j/az3CSNKRG9QWSJMar9jy
 lAHARZF0fEKNwgDCldppelMRZYrFeFVcpFdBha3H1EvixkrK4u/7GiyP+PqVPFVP
 6b27n7sh11/xk5Tal9K6cvYaRY1mmenTWXXx42D2IFShchSOe6U/181B8KBvB0LH
 nCAYV02XI3I+EkuzagifjwvNrU3hkTRbpfBCpsSQ992STdEUI4yNGm9biXo4OxDI
 l0DORlj2xnxoNh1tD/7X
 =aGX9
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/armbru/tags/pull-pflash-2019-03-26' into staging

Pflash and firmware configuration patches for 2019-03-26

# gpg: Signature made Tue 26 Mar 2019 07:21:13 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-pflash-2019-03-26:
  pflash: Bury disabled code to limit device sizes
  pflash: Require backend size to match device, improve errors

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-26 09:57:07 +00:00
Alex Bennée
3f905a5bba pflash: Bury disabled code to limit device sizes
We disabled code to limit device sizes to 8, 16, 32 or 64MiB more than
a decade ago in commit 95d1f3edd5 and c8b153d794, v0.9.1.  Bury.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[Extracted from a larger patch, extended to pflash_cfi02.c]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190319163551.32499-3-armbru@redhat.com>
2019-03-26 08:16:24 +01:00
Markus Armbruster
06f1521795 pflash: Require backend size to match device, improve errors
We reject undersized backends with a rather enigmatic "failed to read
the initial flash content" error.  For instance:

    $ qemu-system-ppc64 -S -display none -M sam460ex -drive if=pflash,format=raw,file=eins.img
    qemu-system-ppc64: Initialization of device cfi.pflash02 failed: failed to read the initial flash content

We happily accept oversized images, ignoring their tail.  Throwing
away parts of firmware that way is pretty much certain to end in an
even more enigmatic failure to boot.

Require the backend's size to match the device's size exactly.  Report
mismatch like this:

    qemu-system-ppc64: Initialization of device cfi.pflash01 failed: device requires 1048576 bytes, block backend provides 512 bytes

Improve the error for actual read failures to "can't read block
backend".

To avoid duplicating even more code between the two pflash device
models, do all that in new helper blk_check_size_and_read_all().

The error reporting can still be confusing.  For instance:

    qemu-system-ppc64 -S -display none -M taihu -drive if=pflash,format=raw,file=eins.img  -drive if=pflash,unit=1,format=raw,file=zwei.img
    qemu-system-ppc64: Initialization of device cfi.pflash02 failed: device requires 2097152 bytes, block backend provides 512 bytes

Leaves the user guessing which of the two -drive is wrong.  Mention
the issue in a TODO comment.

Suggested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190319163551.32499-2-armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-03-26 08:16:24 +01:00
Markus Armbruster
ad85b0b4c7 xen-block: Replace qdict_put_obj() by qdict_put() where appropriate
Patch created mechanically by rerunning:

    $ spatch --sp-file scripts/coccinelle/qobject.cocci \
             --macro-file scripts/cocci-macro-file.h \
             --dir hw/block --in-place

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190313174433.12966-1-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2019-03-26 08:10:11 +01:00
Peter Maydell
d132baa05e Pull request
Compilation fixes and cleanups for QEMU 4.0.0.
 -----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJcmPqkAAoJEJykq7OBq3PIlW8H/187SWabj/3VAXGxCHWdt4wM
 mHffnN2WzAkjCfZoraYXZH2MLVJaHDUfS7XN22uqucfK3K7BYtuJ4VeeU+l5iPK3
 yuZQi2p11XvKEZQhcx11OE9QLJoTGPuAiNNt+690Mk25mcmw2sunewH4YOoEYD9A
 Gsv43L0tPfplAkEKnk3WuheZTZMHXgtKTxaPSlDO3S2LXEJKnDSn3t9iqxMU7MZf
 2Y7PIkt//cXffOF5IrvNR9FOALpaz9UxuZmO7Dj607nYwanuK6qz/482FPioCOuY
 yojpZ65pfntHKhO3fsoZjsIR6TWgkTsAp4fMldoqM299YL5OWxJtR2TbnbIcoHM=
 =Ixbi
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging

Pull request

Compilation fixes and cleanups for QEMU 4.0.0.

# gpg: Signature made Mon 25 Mar 2019 15:58:28 GMT
# gpg:                using RSA key 9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full]
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>" [full]
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8

* remotes/stefanha/tags/tracing-pull-request:
  trace-events: Fix attribution of trace points to source
  trace-events: Delete unused trace points
  scripts/cleanup-trace-events: Update for current practice
  trace-events: Shorten file names in comments
  trace-events: Consistently point to docs/devel/tracing.txt
  trace: avoid SystemTap dtrace(1) warnings on empty files
  trace: handle tracefs path truncation

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-25 17:01:10 +00:00
Paolo Bonzini
4261b2f915 nrf51_gpio: reflect pull-up/pull-down to IRQs
Some drivers do I2C bitbanging by keeping the output to 0 and flipping
the GPIO direction between input and output (see for example in Linux
gpio_set_open_drain_value_commit, in drivers/gpio/gpiolib.c).
When the GPIO is set to input, the pull-up resistor brings the output
to 1, while when the GPIO is set to output, the output driver brings
the output to 0.

Implement this for the nRF51 GPIO device model.  First, if both input and
output are floating, and there is a pull-up or pull-down resistor
configured, do not just set s->in, but also make any devices listening
on the output qemu_irq receive that value.  Second, if the pin is
driven both internally (output pin) and externally you don't get a
short circuit if both sides drive the pin to the same value.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20190317141001.3346-1-pbonzini@redhat.com
[PMM: wrapped long line]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-25 14:16:46 +00:00
Markus Armbruster
dec9776049 trace-events: Fix attribution of trace points to source
Some trace points are attributed to the wrong source file.  Happens
when we neglect to update trace-events for code motion, or add events
in the wrong place, or misspell the file name.

Clean up with help of cleanup-trace-events.pl.  Same funnies as in the
previous commit, of course.  Manually shorten its change to
linux-user/trace-events to */signal.c.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20190314180929.27722-6-armbru@redhat.com
Message-Id: <20190314180929.27722-6-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22 16:18:07 +00:00
Markus Armbruster
a9779a3ab0 trace-events: Delete unused trace points
Tracked down with cleanup-trace-events.pl.  Funnies requiring manual
post-processing:

* block.c and blockdev.c trace points are in block/trace-events.

* hw/block/nvme.c uses the preprocessor to hide its trace point use
  from cleanup-trace-events.pl.

* include/hw/xen/xen_common.h trace points are in hw/xen/trace-events.

* net/colo-compare and net/filter-rewriter.c use pseudo trace points
  colo_compare_udp_miscompare and colo_filter_rewriter_debug to guard
  debug code.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20190314180929.27722-5-armbru@redhat.com
Message-Id: <20190314180929.27722-5-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22 16:18:07 +00:00
Markus Armbruster
500016e5db trace-events: Shorten file names in comments
We spell out sub/dir/ in sub/dir/trace-events' comments pointing to
source files.  That's because when trace-events got split up, the
comments were moved verbatim.

Delete the sub/dir/ part from these comments.  Gets rid of several
misspellings.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190314180929.27722-3-armbru@redhat.com
Message-Id: <20190314180929.27722-3-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22 16:18:07 +00:00
Markus Armbruster
e68b3baa25 trace-events: Consistently point to docs/devel/tracing.txt
Almost all trace-events point to docs/devel/tracing.txt in a comment
right at the beginning.  Touch up the ones that don't.

[Updated with Markus' new commit description wording.
--Stefan]

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190314180929.27722-2-armbru@redhat.com
Message-Id: <20190314180929.27722-2-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22 16:17:37 +00:00
Paolo Bonzini
938912a866 virtio-vga: only enable for specific boards
When virtio-vga was added, the intention was to only support it for
those machines where the firmware does not know about virtio-gpu,
and supported VGA legacy hardware before virtio-{gpu,vga} were
introduced.

The Kconfig switch however enabled virtio-vga for all machines with
a PCI bus, and libvirt then prefers it even on hardware where
virtio-gpu would be preferrable.  At least for now, only enable
virtio-vga for PC, hppa and pSeries machines, as was the case
before Kconfig dependencies were introduced.

Reported-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-21 17:42:18 +01:00
Peter Xu
4b519ef1de intel-iommu: optimize nodmar memory regions
Previously we have per-device system memory aliases when DMAR is
disabled by the system.  It will slow the system down if there are
lots of devices especially when DMAR is disabled, because each of the
aliased system address space will contain O(N) slots, and rendering
such N address spaces will be O(N^2) complexity.

This patch introduces a shared nodmar memory region and for each
device we only create an alias to the shared memory region.  With the
aliasing, QEMU memory core API will be able to detect when devices are
sharing the same address space (which is the nodmar address space)
when rendering the FlatViews and the total number of FlatViews can be
dramatically reduced when there are a lot of devices.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20190313094323.18263-1-peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
9ad4994661 hw/alpha/Kconfig: DP264 hardware requires e1000 network card
This fixes when configuring with CONFIG_PCI_DEVICES=n:
  $ qemu-system-alpha
  qemu-system-alpha: Unsupported NIC model: e1000

Fixes: d1a95ef4ac
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190316200818.8265-15-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
b6dbcdb7b3 hw/hppa/Kconfig: Dino board requires e1000 network card
This fixes when configuring with CONFIG_PCI_DEVICES=n:

  $ qemu-system-hppa
  qemu-system-hppa: Unsupported NIC model: e1000

Fixes: 9483cf27dd
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190316200818.8265-14-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
364efd1a15 hw/sh4/Kconfig: r2d machine requires the rtl8139 network card
This fixes when configuring with CONFIG_PCI_DEVICES=n:

  $ qemu-system-sh4 -M r2d
  qemu-system-sh4: Unsupported NIC model: rtl8139

Fixes: 7ab58d4c84
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190316200818.8265-13-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
bcb7ef9d1b hw/ppc/Kconfig: e500 based machines require virtio-net-pci device
This fixes when configuring with CONFIG_PCI_DEVICES=n:

  $ qemu-system-ppc64 -bios /dev/null -M ppce500
  qemu-system-ppc64: Unsupported NIC model: virtio-net-pci

And:

  $ qemu-system-ppc64 -bios /dev/null -M mpc8544ds
  qemu-system-ppc64: Unsupported NIC model: virtio-net-pci

Fixes: 98bd1db99f
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20190316200818.8265-10-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
f7b5cdcbf2 hw/ppc/Kconfig: Bamboo machine requires e1000 network card
This fixes when configuring with CONFIG_PCI_DEVICES=n:

  $ qemu-system-ppc64 -bios /dev/null -M bamboo
  qemu-system-ppc64: Unsupported NIC model: e1000

Fixes: 7c28b925b7
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20190316200818.8265-9-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
09cba51e4f hw/i386/Kconfig: enable devices that can be created by default
This fixes when configuring with CONFIG_PCI_DEVICES=n:

  $ qemu-system-x86_64 -M q35
  qemu-system-x86_64: Unsupported NIC model: e1000e
  $ qemu-system-x86_64 -M pc
  qemu-system-x86_64: Unsupported NIC model: e1000

Fixes: 7c28b925b7
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190316200818.8265-4-philmd@redhat.com>
2019-03-20 11:44:13 +01:00
Philippe Mathieu-Daudé
fa80da7b69 hw/isa/Kconfig: PIIX4 southbridge requires USB UHCI
This fixes when configuring with --without-default-devices:

  $ qemu-system-mips64 -bios /dev/null -M malta
  qemu-system-mips64: Unknown device 'piix4-usb-uhci' for bus 'PCI'

Fixes: 7c28b925b7
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190316200818.8265-2-philmd@redhat.com>
2019-03-20 11:44:13 +01:00