All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhou Jie <zhoujie2011@cn.fujitsu.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Chen Fan <fan.chen@easystack.cn>,
	mst@redhat.com, qemu-devel@nongnu.org, caoj.fnst@cn.fujitsu.com,
	izumi.taku@jp.fujitsu.com
Subject: Re: [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification handler for aer resume
Date: Sat, 25 Jun 2016 09:24:19 +0800	[thread overview]
Message-ID: <7746532f-2fad-1304-0df7-7cd25ba761af@cn.fujitsu.com> (raw)
In-Reply-To: <20160622094236.515549fa@t450s.home>

Hi Alex,

> We should never depend on the guest driver to behave in a certain way,
> but we need to prioritize what that actually means.  vfio in the kernel
> has a responsibility first and foremost to the host kernel.  User owned
> devices cannot be allowed to exploit or interfere with the host
> regardless of user behavior.  The next priority is correct operation
> for the user.  When the host kernel is handling the AER event between
> the error and resume notifies, it doesn't have device specific drivers,
> it's manipulating the device as a generic PCI device.  That makes me
> think that vfio should not allow the user to interact (interfere) with
> the device during that process and that such interference can be
> limited to standard PCI level interactions.  That means config space,
> and things that operate on config space (like interrupt ioctls and
> resets).  On the QEMU side, we've sent a notification that an error
> occurred, how the user and the guest respond to that is beyond the
> concern of vfio in the kernel.  If the user/guest driver continues to
> interact with resources on the device, that's fine, but I think vfio in
> the kernel does need to prevent the user from interfering with the PCI
> state of the device for that brief window when we know the host kernel
> is operating on the device.  Otherwise the results are unpredictable
> and therefore unsupportable.  Does that make sense?  Thanks,
I understand.

I want to alter the VFIO driver like following.
During err occurs and resume:
1. Make config space read only.
    Ignore config space writing to prevent the user from
    interfering with the PCI state of the device.
    User can get the error infomation by reading the config space.
2. Disable INTx and MSI
    Write "Command Register" to disable INTx and MSI.
3. Do nothing for bar regions.
    Guest driver may access bar regions.
    It doesn't matter as device is going to be reset.

The following code will be modified.
1. vfio_pci_ioctl
    add flag for aer support
2. vfio_pci_ioctl
    During err occurs and resume:
    if (cmd == VFIO_DEVICE_SET_IRQS) return EAGAIN
    if (cmd == VFIO_DEVICE_RESET) return EAGAIN
    if (cmd == VFIO_DEVICE_GET_PCI_HOT_RESET_INFO) return EAGAIN
    if (cmd == VFIO_DEVICE_PCI_HOT_RESET) return EAGAIN
3. vfio_pci_write
    During err occurs and resume:
    block
4. vfio_pci_aer_err_detected
    Set aer state in "struct vfio_pci_device"
    Write "Command Register" to disable INTx and MSI.
5. vfio_pci_aer_resume
    Clear aer state in "struct vfio_pci_device"
    I don't need to enable INTx and MSI.
    The device will be initalized by guest driver.

Sincerely
Zhoujie

  reply	other threads:[~2016-06-25  1:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27  2:12 [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification handler for aer resume Zhou Jie
2016-05-27 16:06 ` Alex Williamson
2016-06-12  2:38   ` Zhou Jie
2016-06-20  7:41     ` Zhou Jie
2016-06-20 16:32       ` Alex Williamson
2016-06-21  2:16         ` Zhou Jie
2016-06-21  3:13           ` Alex Williamson
2016-06-21 12:41             ` Chen Fan
2016-06-21 14:44               ` Alex Williamson
2016-06-22  3:28                 ` Zhou Jie
2016-06-22  3:56                   ` Alex Williamson
2016-06-22  5:45                     ` Zhou Jie
2016-06-22  7:49                       ` Zhou Jie
2016-06-22 15:42                         ` Alex Williamson
2016-06-25  1:24                           ` Zhou Jie [this message]
2016-06-27 15:54                             ` Alex Williamson
2016-06-28  3:26                               ` Zhou Jie
2016-06-28  3:58                                 ` Alex Williamson
2016-06-28  5:27                                   ` Zhou Jie
2016-06-28 14:40                                     ` Alex Williamson
2016-06-29  8:54                                       ` Zhou Jie
2016-06-29 18:22                                         ` Alex Williamson
2016-06-30  1:45                                           ` Zhou Jie
2016-07-03  4:00                                             ` Zhou Jie
2016-07-05  1:36                                               ` Zhou Jie
2016-07-05 17:03                                                 ` Alex Williamson
2016-07-06  2:01                                                   ` Zhou Jie
2016-07-07 19:04                                                     ` Alex Williamson
2016-07-08  1:38                                                       ` Zhou Jie
2016-07-08 17:33                                                         ` Alex Williamson
2016-07-10  1:28                                                           ` Zhou Jie
2016-07-11 16:24                                                             ` Alex Williamson
2016-07-12  1:42                                                               ` Zhou Jie
2016-07-12 15:45                                                                 ` Alex Williamson
2016-07-13  1:04                                                                   ` Zhou Jie
2016-07-13  2:54                                                                     ` Alex Williamson
2016-07-13  3:33                                                                       ` Zhou Jie
2016-06-22 15:25                       ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7746532f-2fad-1304-0df7-7cd25ba761af@cn.fujitsu.com \
    --to=zhoujie2011@cn.fujitsu.com \
    --cc=alex.williamson@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=fan.chen@easystack.cn \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.