qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] df6180: xen-bus: check whether the frontend i


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] df6180: xen-bus: check whether the frontend is active duri...
Date: Wed, 25 Sep 2019 05:30:52 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: df6180bb56cd03949c2c64083da58755fed81a61
      
https://github.com/qemu/qemu/commit/df6180bb56cd03949c2c64083da58755fed81a61
  Author: Paul Durrant <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M hw/xen/xen-bus.c

  Log Message:
  -----------
  xen-bus: check whether the frontend is active during device reset...

...not the backend

Commit cb323146 "xen-bus: Fix backend state transition on device reset"
contained a subtle mistake. The hunk

@@ -539,11 +556,11 @@ static void xen_device_backend_changed(void *opaque)

     /*
      * If the toolstack (or unplug request callback) has set the backend
-     * state to Closing, but there is no active frontend (i.e. the
-     * state is not Connected) then set the backend state to Closed.
+     * state to Closing, but there is no active frontend then set the
+     * backend state to Closed.
      */
     if (xendev->backend_state == XenbusStateClosing &&
-        xendev->frontend_state != XenbusStateConnected) {
+        !xen_device_state_is_active(state)) {
         xen_device_backend_set_state(xendev, XenbusStateClosed);
     }

mistakenly replaced the check of 'xendev->frontend_state' with a check
(now in a helper function) of 'state', which actually equates to
'xendev->backend_state'.

This patch fixes the mistake.

Fixes: cb3231460747552d70af9d546dc53d8195bcb796
Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony PERARD <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: 374752a26b0ea487dd49c638ee35b97a58ce8e3b
      
https://github.com/qemu/qemu/commit/374752a26b0ea487dd49c638ee35b97a58ce8e3b
  Author: Paul Durrant <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M hw/xen/trace-events
    M hw/xen/xen-bus.c
    M include/hw/xen/xen-bus.h
    M include/qemu/notify.h
    M util/notify.c

  Log Message:
  -----------
  xen / notify: introduce a new XenWatchList abstraction

Xenstore watch call-backs are already abstracted away from XenBus using
the XenWatch data structure but the associated NotifierList manipulation
and file handle registration is still open coded in various xen_bus_...()
functions.
This patch creates a new XenWatchList data structure to allow these
interactions to be abstracted away from XenBus as well. This is in
preparation for a subsequent patch which will introduce separate watch lists
for XenBus and XenDevice objects.

NOTE: This patch also introduces a new notifier_list_empty() helper function
      for the purposes of adding an assertion that a XenWatchList is not
      freed whilst its associated NotifierList is still occupied.

Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony Perard <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: d198b711f9ff9032d7270d78d5b5b17abf740e75
      
https://github.com/qemu/qemu/commit/d198b711f9ff9032d7270d78d5b5b17abf740e75
  Author: Paul Durrant <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M hw/xen/trace-events
    M hw/xen/xen-bus.c
    M include/hw/xen/xen-bus.h

  Log Message:
  -----------
  xen: introduce separate XenWatchList for XenDevice objects

This patch uses the XenWatchList abstraction to add a separate watch list
for each device. This is more scalable than walking a single notifier
list for all watches and is also necessary to implement a bug-fix in a
subsequent patch.

Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony Perard <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: 3809f7583ba463b9877755e6ca5f5f036430fdda
      
https://github.com/qemu/qemu/commit/3809f7583ba463b9877755e6ca5f5f036430fdda
  Author: Paul Durrant <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M hw/xen/trace-events
    M hw/xen/xen-bus.c
    M include/hw/xen/xen-bus.h

  Log Message:
  -----------
  xen: perform XenDevice clean-up in XenBus watch handler

Cleaning up offline XenDevice objects directly in
xen_device_backend_changed() is dangerous as xen_device_unrealize() will
modify the watch list that is being walked. Even the QLIST_FOREACH_SAFE()
used in notifier_list_notify() is insufficient as *two* notifiers (for
the frontend and backend watches) are removed, thus potentially rendering
the 'next' pointer unsafe.

The solution is to use the XenBus backend_watch handler to do the clean-up
instead, as it is invoked whilst walking a separate watch list.

This patch therefore adds a new 'inactive_devices' list to XenBus, to which
offline devices are added by xen_device_backend_changed(). The XenBus
backend_watch registration is also changed to not only invoke
xen_bus_enumerate() but also a new xen_bus_cleanup() function, which will
walk 'inactive_devices' and perform the necessary actions.
For safety an extra 'online' check is also added to xen_bus_type_enumerate()
to make sure that no attempt is made to create a new XenDevice object for a
backend that is offline.

NOTE: This patch also includes some cosmetic changes:
      - substitute the local variable name 'backend_state'
        in xen_bus_type_enumerate() with 'state', since there
        is no ambiguity with any other state in that context.
      - change xen_device_state_is_active() to
        xen_device_frontend_is_active() (and pass a XenDevice directly)
        since the state tests contained therein only apply to a frontend.
      - use 'state' rather then 'xendev->backend_state' in
        xen_device_backend_changed() to shorten the code.

Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony PERARD <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: 784e9727af98f789498afb4c7a526e8de19d8b6d
      
https://github.com/qemu/qemu/commit/784e9727af98f789498afb4c7a526e8de19d8b6d
  Author: Paul Durrant <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: update my email address

My Citrix email address will expire shortly.

Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony PERARD <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: ef916ab3ec570eac799be540e499d0123fe61899
      
https://github.com/qemu/qemu/commit/ef916ab3ec570eac799be540e499d0123fe61899
  Author: Paul Durrant <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M hw/block/xen-block.c

  Log Message:
  -----------
  xen-block: treat XenbusStateUnknown the same as XenbusStateClosed

When a frontend gracefully disconnects from an offline backend, it will
set its own state to XenbusStateClosed. The code in xen-block.c correctly
deals with this and sets the backend into XenbusStateClosed. Unfortunately
it is possible for toolstack to actually delete the frontend area
before the state key has been read, leading to an apparent frontend state
of XenbusStateUnknown. This prevents the backend state from transitioning
to XenbusStateClosed and hence leaves it limbo.

This patch simply treats a frontend state of XenbusStateUnknown the same
as XenbusStateClosed, which will unblock the backend in these circumstances.

Reported-by: Mark Syms <address@hidden>
Signed-off-by: Paul Durrant <address@hidden>
Acked-by: Anthony PERARD <address@hidden>
Reviewed-by: John Snow <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: 6bd6b955c0b2666263700d39db153ab43c5e0c9e
      
https://github.com/qemu/qemu/commit/6bd6b955c0b2666263700d39db153ab43c5e0c9e
  Author: Mark Syms <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M hw/xen/xen-bus.c

  Log Message:
  -----------
  xen-bus: only set the xen device frontend state if it is missing

Some toolstack implementations will set the frontend xenstore
keys to Initialising which will then trigger the in guest PV
drivers to begin initialising and some implementations will
then set their state to Closing. If this has occurred then
device realize must not overwrite the frontend keys as then
the handshake will stall.

Signed-off-by: Mark Syms <address@hidden>

Also avoid creating the frontend area if it already exists.

Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony PERARD <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>


  Commit: 240ab11fb72049d6373cbbec8d788f8e411a00bc
      
https://github.com/qemu/qemu/commit/240ab11fb72049d6373cbbec8d788f8e411a00bc
  Author: Peter Maydell <address@hidden>
  Date:   2019-09-24 (Tue, 24 Sep 2019)

  Changed paths:
    M MAINTAINERS
    M hw/block/xen-block.c
    M hw/xen/trace-events
    M hw/xen/xen-bus.c
    M include/hw/xen/xen-bus.h
    M include/qemu/notify.h
    M util/notify.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190924' into 
staging

Xen queue

* Update of maintainer email address
* Fixes for xen-bus and xen-block

# gpg: Signature made Tue 24 Sep 2019 12:27:56 BST
# gpg:                using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Anthony PERARD <address@hidden>" [marginal]
# gpg:                 aka "Anthony PERARD <address@hidden>" [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: 5379 2F71 024C 600F 778A  7161 D8D5 7199 DF83 42C8
#      Subkey fingerprint: F80C 0063 08E2 2CFD 8A92  E798 0CF5 572F D7FB 55AF

* remotes/aperard/tags/pull-xen-20190924:
  xen-bus: only set the xen device frontend state if it is missing
  xen-block: treat XenbusStateUnknown the same as XenbusStateClosed
  MAINTAINERS: update my email address
  xen: perform XenDevice clean-up in XenBus watch handler
  xen: introduce separate XenWatchList for XenDevice objects
  xen / notify: introduce a new XenWatchList abstraction
  xen-bus: check whether the frontend is active during device reset...

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


Compare: https://github.com/qemu/qemu/compare/860d9048c78c...240ab11fb720



reply via email to

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