linux-kernel - Re: [PATCH] vfio pci: kernel support of error recovery only for non fatal error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 Mar 2017 16:34:22 +0200
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Cao jin <caoj.fnst@...fujitsu.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, qemu-devel@...gnu.org,
        izumi.taku@...fujitsu.com
Subject: Re: [PATCH] vfio pci: kernel support of error recovery only for non
 fatal error

On Mon, Mar 20, 2017 at 08:30:56AM -0600, Alex Williamson wrote:
> > > What about the case where the user has not registered for receiving
> > > non-fatal errors, now we send an error signal on both error_detected
> > > and slot_reset.  Is that useful/desirable?
> > >   
> > 
> > Not desirable, but seems not harmful, guest user will stop anyway. How
> > to avoid this case gracefully seems not easy.
> 
> "Not harmful" is presuming the behavior of the user.  QEMU might not be
> the only consumer of these events.  Is it possible to receive a
> slot_reset without first receiving an error_detected?  If not then we
> can easily track our action for one to decide on the behavior for the
> other.  Thanks,
> 
> Alex

I would just pass maximum info to userspace and let it decide.

-- 
MST