Re: [libvirt] [Qemu-devel] [PATCH for 2.1] vfio: use correct runstate

----- Messaggio originale ----- > Da: "Alex Williamson" <alex.williamson(a)redhat.com&gt; > A: "Paolo Bonzini" <pbonzini(a)redhat.com&gt; > Cc: qemu-devel(a)nongnu.org, qemu-trivial(a)nongnu.org > Inviato: Venerdì, 27 giugno 2014 18:34:59 > Oggetto: Re: [PATCH for 2.1] vfio: use correct runstate > > On Fri, 2014-06-27 at 16:32 +0200, Paolo Bonzini wrote: >> io-error is for block device errors; it should always be preceded >> by a BLOCK_IO_ERROR event. > > Where does this requirement come from? I only see a loose association > of IO_ERROR to disk in libvirt and none in QEMU. See the RunState enum in qapi-schema.json: ## # @RunState # # An enumeration of VM run states. # # ... # # @internal-error: An internal error that prevents further guest execution # has occurred # # @io-error: the last IOP has failed and the device is configured to pause # on I/O errors # # @paused: guest has been paused via the 'stop' command The point of io-error is that management can look at block devices, see if any have an error reported, and then resume execution (see documentation of rerror=stop and werror=stop/enospc). This is counter to the intentions you have in vfio. >> I think vfio wants to use >> RUN_STATE_INTERNAL_ERROR instead. > > But that seems to put us into an "unknown" paused state in libvirt. I think paused is incorrect, because (unlike RUN_STATE_IO_ERROR), you cannot resume from RUN_STATE_INTERNAL_ERROR except with a reset. QEMU enforces that, and this matches the error you are reporting: error_report("%s(%04x:%02x:%02x.%x) Unrecoverable error detected. " "Please collect any data possible and then kill the guest", __func__, vdev->host.domain, vdev->host.bus, vdev->host.slot, vdev->host.function); libvirt has a crashed state, I think that's what libvirt should call the internal-error runstate. IIRC on Xen you get to crashed when the processor raises an error on vmentry, for example. Libvirt only knows about crashed/unknown, but one could add crashed/internal-error too.