qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 843cae: target/s390x: define TCG_GUEST_DEFAUL


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 843cae: target/s390x: define TCG_GUEST_DEFAULT_MO for MTTCG
Date: Tue, 05 Feb 2019 10:20:12 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 843caef2ef1fd524de66a035b88a9153350ad392
      
https://github.com/qemu/qemu/commit/843caef2ef1fd524de66a035b88a9153350ad392
  Author: Alex Bennée <address@hidden>
  Date:   2019-02-04 (Mon, 04 Feb 2019)

  Changed paths:
    M target/s390x/cpu.h

  Log Message:
  -----------
  target/s390x: define TCG_GUEST_DEFAULT_MO for MTTCG

MTTCG should be enabled by default whenever the memory model allows
it. s390x was missing its definition of TCG_GUEST_DEFAULT_MO meaning
the user had to manually specify  --accel tcg,thread=multi.

Signed-off-by: Alex Bennée <address@hidden>
Cc: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: f6b51efa198d69a9b624a4ccaf8574e892aab78f
      
https://github.com/qemu/qemu/commit/f6b51efa198d69a9b624a4ccaf8574e892aab78f
  Author: Igor Mammedov <address@hidden>
  Date:   2019-02-04 (Mon, 04 Feb 2019)

  Changed paths:
    M target/s390x/kvm.c

  Log Message:
  -----------
  s390x: remove direct reference to mem_path global from s390x code

I plan to deprecate -mem-path option and replace it with memory-backend,
for that it's necessary to get rid of mem_path global variable.
Do it for s390x case, replacing it with alternative way to enable
1Mb hugepages capability.

Todo that replace qemu_mempath_getpagesize() with qemu_getrampagesize()
which also checks for -mem-path provided RAM.

Signed-off-by: Igor Mammedov <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: e0998fe8910435f0e818e5c9ac58d4d2d9144a98
      
https://github.com/qemu/qemu/commit/e0998fe8910435f0e818e5c9ac58d4d2d9144a98
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-04 (Mon, 04 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c
    M hw/s390x/s390-pci-bus.h

  Log Message:
  -----------
  s390x/pci: Introduce unplug requests and split unplug handler

PCI on s390x is really weird and how it was modeled in QEMU might not have
been the right choice. Anyhow, right now it is the case that:
- Hotplugging a PCI device will silently create a zPCI device
  (if none is provided)
- Hotunplugging a zPCI device will unplug the PCI device (if any)
- Hotunplugging a PCI device will unplug also the zPCI device
As far as I can see, we can no longer change this behavior. But we
should fix it.

Both device types are handled via a single hotplug handler call. This
is problematic for various reasons:
1. Unplugging via the zPCI device allows to unplug devices that are not
   hot removable. (check performed in qdev_unplug()) - bad.
2. Hotplug handler chains are not possible for the unplug case. In the
   future, the machine might want to override hotplug handlers, to
   process device specific stuff and to then branch off to the actual
   hotplug handler. We need separate hotplug handler calls for both the
   PCI and zPCI device to make this work reliably. All other PCI
   implementations are already prepared to handle this correctly, only
   s390x is missing.

Therefore, introduce the unplug_request handler and properly perform
unplug checks by redirecting to the separate unplug_request handlers.
When finally unplugging, perform two separate hotplug_handler_unplug()
calls, first for the PCI device, followed by the zPCI device. This now
nicely splits unplugging paths for both devices.

The redirect part is a little hairy, as the user is allowed to trigger
unplug either via the PCI or the zPCI device. So redirect always to the
PCI unplug request handler first and remember if that check has been
performed in the zPCI device. Redirect then to the zPCI device unplug
request handler to perform the magic. Remembering that we already
checked the PCI device breaks the redirect loop.

Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 9f2a46b11139cd21c41f4d97c0416af6f9e76f7b
      
https://github.com/qemu/qemu/commit/9f2a46b11139cd21c41f4d97c0416af6f9e76f7b
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-04 (Mon, 04 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c
    M hw/s390x/s390-pci-bus.h

  Log Message:
  -----------
  s390x/pci: Drop release timer and replace it with a flag

Let's handle it similar to x86 ACPI PCI code and don't use a timer.
Instead, remember if an unplug request is pending and keep it pending
for eternity. (a follow up patch will process the request on
reboot).

We expect that a guest that is up and running, will process the unplug
request and trigger the unplug. This is normal operation, no timer needed.

If the guest does not react, this usually means something in the guest
is going wrong. Simply removing the device after 30 seconds does not
really sound like a good idea. It might sometimes be wanted, but I
consider this rather an "opt-in" decision as it might harm a guest not
prepared for it.

If we ever actually want a "forced/surprise removal", we will have to
implement something on top of the existing "device_del" framework. E.g.
also x86 might want to do a forced/surprise removal of PCI devices under
some conditions. "device_del X, forced=true" could be an option and will
require changes to the hotplug handler infrastructure.

This will then move the responsibility on when to do a forced removal
to a higher level. Doing a forced removal right now over-complicates
things and doesn't really seem to be required.

Let's allow to send multiple requests.

Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: aede5d5dfc5f3e4ea7467b28c51fda2f8945d117
      
https://github.com/qemu/qemu/commit/aede5d5dfc5f3e4ea7467b28c51fda2f8945d117
  Author: Cornelia Huck <address@hidden>
  Date:   2019-02-04 (Mon, 04 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: mark zpci devices as unmigratable

We currently don't migrate any state for zpci devices, which are
coupled with standard pci devices. This means funny things happen
when we e.g. try to migrate with a virtio-pci device but the s390x-
specific zpci state is not migrated (vfio-pci is not affected, as
it is not migratable anyway.)

Until this is fixed, mark zpci devices as unmigratable.

Reported-by: David Hildenbrand <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 80a7b759493e05579c26e8a913a3d6349641853e
      
https://github.com/qemu/qemu/commit/80a7b759493e05579c26e8a913a3d6349641853e
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-04 (Mon, 04 Feb 2019)

  Changed paths:
    M target/s390x/insn-data.def
    M target/s390x/translate.c

  Log Message:
  -----------
  s390x/tcg: Don't model FP registers as globals

As floating point registers overlay some vector registers and we want
to make use of the general tcg_gvec infrastructure that assumes vectors
are not stored in globals but in memory, don't model floating point
registers as globals anymore. This is then similar to how arm handles
it.

Reading/writing a floating point register means reading/writing memory now.

Break up ugly in2_x2() handling that modifies both, in1 and in2 into
in2_x2l and in2_x2h. This makes things more readable. Also, in1_x1() is
ugly as it touches out/out2, get rid of that and use prep_x1() instead.

As we are no longer able to use the original global variables for
out/out2, we have to use new temporary variables and write from them to
the target registers using wout_ helpers.

E.g. an instruction that reads and writes x1 will use
- prep_x1 to get the values into out/out2
- wout_x1 to write the values from out/out2
This special handling is needed for x1 as it is often used along with
other inputs, so in1/in2 is already used.

Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: d30a7507edf1ca23d33dbf00b25f5e49a7808492
      
https://github.com/qemu/qemu/commit/d30a7507edf1ca23d33dbf00b25f5e49a7808492
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-05 (Tue, 05 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: Fix primary bus number for PCI bridges

The primary bus number corresponds always to the bus number of the
bus the bridge is attached to.

Right now, if we have two bridges attached to the same bus (e.g. root
bus) this is however not the case. The first bridge will have primary
bus 0, the second bridge primary bus 1, which is wrong. Fix the assignment.

While at it, drop setting the PCI_SUBORDINATE_BUS temporarily to 0xff.
Setting it temporarily to that value (as discussed e.g. in [1]), is
only relevant for a running system that probes the buses. The value is
effectively unused for us just doing a DFS.

Also add a comment why we have to reassign during every reset (which I
found to be surprising.

Please note that hotplugging of bridges is in general still broken, will
be fixed next.

[1] http://www.science.unitn.it/~fiorella/guidelinux/tlk/node76.html

Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 150f462538a6f3b78efe785c911669375032b0d2
      
https://github.com/qemu/qemu/commit/150f462538a6f3b78efe785c911669375032b0d2
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-05 (Tue, 05 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: Fix hotplugging of PCI bridges

When hotplugging a PCI bridge right now to the root port, we resolve
pci_get_bus(pdev)->parent_dev, which results in a SEGFAULT. Hotplugging
really only works right now when hotplugging to another bridge.

Instead, we have to properly check if we are already at the root.

Let's cleanup the code while at it a bit and factor out updating the
subordinate bus number into a separate function. The check for
"old_nr < nr" is right now not strictly necessary, but makes it more
obvious what is actually going on.

Most probably fixing up the topology is not our responsibility when
hotplugging. The guest has to sort this out. But let's keep it for now
and only fix current code to not crash.

Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 703fef6fcf3edcbf169c90b6196fcf88f9e9765a
      
https://github.com/qemu/qemu/commit/703fef6fcf3edcbf169c90b6196fcf88f9e9765a
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-05 (Tue, 05 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: Warn when adding PCI devices without the 'zpci' feature

We decided to always create the PCI host bridge, even if 'zpci' is not
enabled (due to migration compatibility). This however right now allows
to add zPCI/PCI devices to a VM although the guest will never actually see
them, confusing people that are using a simple CPU model that has no
'zpci' enabled - "Why isn't this working" (David Hildenbrand)

Let's check for 'zpci' and at least print a warning that this will not
work as expected. We could also bail out, however that might break
existing QEMU commandlines.

Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 2313a88fe68cb970532ba1641ffc35c848daae86
      
https://github.com/qemu/qemu/commit/2313a88fe68cb970532ba1641ffc35c848daae86
  Author: David Hildenbrand <address@hidden>
  Date:   2019-02-05 (Tue, 05 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c

  Log Message:
  -----------
  s390x/pci: Unplug remaining requested devices on pcihost reset

When resetting the guest we should unplug and remove all devices that
are still pending.

With this patch, the requested device will be unplugged on reboot
(S390_RESET_EXTERNAL and S390_RESET_REIPL, which reset the pcihost bridge
via qemu_devices_reset()).

This approach is similar to what's done for acpi PCI hotplug in
acpi_pcihp_reset() -> acpi_pcihp_update() ->
acpi_pcihp_update_hotplug_bus() -> acpi_pcihp_eject_slot().

s390_pci_generate_plug_event()'s will still be generated, I guess this
is not an issue. The same thing would happen right now when unplugging
a device just before starting the guest.

Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Collin Walling <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 9669c9756205290a7a357ff1515a4ca30d852b05
      
https://github.com/qemu/qemu/commit/9669c9756205290a7a357ff1515a4ca30d852b05
  Author: Peter Maydell <address@hidden>
  Date:   2019-02-05 (Tue, 05 Feb 2019)

  Changed paths:
    M hw/s390x/s390-pci-bus.c
    M hw/s390x/s390-pci-bus.h
    M target/s390x/cpu.h
    M target/s390x/insn-data.def
    M target/s390x/kvm.c
    M target/s390x/translate.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190205' into staging

Fixes and improvements in tcg and the zPCI code.

# gpg: Signature made Tue 05 Feb 2019 16:36:09 GMT
# gpg:                using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Cornelia Huck <address@hidden>" [unknown]
# gpg:                 aka "Cornelia Huck <address@hidden>" [full]
# gpg:                 aka "Cornelia Huck <address@hidden>" [full]
# gpg:                 aka "Cornelia Huck <address@hidden>" [unknown]
# gpg:                 aka "Cornelia Huck <address@hidden>" [unknown]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20190205:
  s390x/pci: Unplug remaining requested devices on pcihost reset
  s390x/pci: Warn when adding PCI devices without the 'zpci' feature
  s390x/pci: Fix hotplugging of PCI bridges
  s390x/pci: Fix primary bus number for PCI bridges
  s390x/tcg: Don't model FP registers as globals
  s390x/pci: mark zpci devices as unmigratable
  s390x/pci: Drop release timer and replace it with a flag
  s390x/pci: Introduce unplug requests and split unplug handler
  s390x: remove direct reference to mem_path global from s390x code
  target/s390x: define TCG_GUEST_DEFAULT_MO for MTTCG

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/68df0c30edf0...9669c9756205



reply via email to

[Prev in Thread] Current Thread [Next in Thread]