On Wed, Jan 05, 2022 at 03:12:26PM -0700, Alex Williamson wrote:
> On Wed, 5 Jan 2022 16:05:45 -0500
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Jan 05, 2022 at 12:56:42PM -0700, Alex Williamson wrote:
> > > The VFIO_DEVICE_RESET ioctl might be backed by several different reset
> > > methods, inc
On Wed, 5 Jan 2022 16:05:45 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Jan 05, 2022 at 12:56:42PM -0700, Alex Williamson wrote:
> > The VFIO_DEVICE_RESET ioctl might be backed by several different reset
> > methods, including a device specific reset (ie. custom reset code in
> > kernel), an ACPI
On Wed, Jan 05, 2022 at 12:56:42PM -0700, Alex Williamson wrote:
> The VFIO_DEVICE_RESET ioctl might be backed by several different reset
> methods, including a device specific reset (ie. custom reset code in
> kernel), an ACPI reset (ie. custom reset code in firmware), FLR, PM,
> and bus resets.
Sorry for the dupe and fat-fingering MST's email, please reply to the
other thread at 164141259622.4193261.8252690438434562107.stgit@omen.
Thanks,
Alex
The VFIO_DEVICE_RESET ioctl might be backed by several different reset
methods, including a device specific reset (ie. custom reset code in
kernel), an ACPI reset (ie. custom reset code in firmware), FLR, PM,
and bus resets. This listing is also the default priority order used
by the kernel for tr
The VFIO_DEVICE_RESET ioctl might be backed by several different reset
methods, including a device specific reset (ie. custom reset code in
kernel), an ACPI reset (ie. custom reset code in firmware), FLR, PM,
and bus resets. This listing is also the default priority order used
by the kernel for tr
