From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Chao Gao' <chao.gao@intel.com>, Roger Pau Monne <roger.pau@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Stefano Stabellini <sstabellini@kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [Qemu-devel] [RFC Patch] xen/pt: Emulate FLR capability
Date: Fri, 6 Sep 2019 09:20:33 +0000 [thread overview]
Message-ID: <1307d03945d948fd89a6956d77c5ce28@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <20190906090107.GA25703@gao-cwp>
> -----Original Message-----
> From: Chao Gao <chao.gao@intel.com>
> Sent: 06 September 2019 10:01
> To: Roger Pau Monne <roger.pau@citrix.com>
> Cc: xen-devel@lists.xenproject.org; qemu-devel@nongnu.org; Stefano Stabellini
> <sstabellini@kernel.org>; Anthony Perard <anthony.perard@citrix.com>; Paul Durrant
> <Paul.Durrant@citrix.com>; Jan Beulich <jbeulich@suse.com>
> Subject: Re: [RFC Patch] xen/pt: Emulate FLR capability
>
> On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote:
> >On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote:
> >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
> >> perspective, assigned devices cannot be reset. But some devices rely on PCI
> >> reset to recover from hardware hangs. When being assigned to a VM, those
> >> devices cannot be reset and won't work any longer if a hardware hang occurs.
> >> We have to reboot VM to trigger PCI reset on host to recover the device.
> >>
> >> This patch exposes FLR capability to VMs if the assigned device can be reset on
> >> host. When VM initiates an FLR to a device, qemu cleans up the device state,
> >> (including disabling of intx and/or MSI and unmapping BARs from guest, deleting
> >> emulated registers), then initiate PCI reset through 'reset' knob under the
> >> device's sysfs, finally initialize the device again.
> >
> >I think you likely need to deassign the device from the VM, perform
> >the reset, and then assign the device again, so that there's no Xen
> >internal state carried over prior to the reset?
>
> Yes. It is the safest way. But here I want to present the feature as FLR
> (such that the device driver in guest can issue PCI reset whenever
> needed and no change is needed to device driver). Current device
> deassignment notifies guest that the device is going to be removed
> It is not the standard PCI reset. Is it possible to make guest unaware
> of the device deassignment to emulate a standard PCI reset?
It should be, I would have thought. QEMU emulates all config space so any config access by the guest would be unaffected by de-assignment. The BARs and interrupts would be unmapped... but that's what you'd want anyway.
> In my mind,
> we can expose do_pci_remove/add to qemu or rewrite them in qemu (but
> don't remove the device from guest's PCI hierarchy). Do you think it is
> the right direction?
Long term I think we want to get pass-through emulation out of QEMU and into Xen.
Paul
>
> Thanks
> Chao
next prev parent reply other threads:[~2019-09-06 9:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 9:02 [Qemu-devel] [RFC Patch] xen/pt: Emulate FLR capability Chao Gao
2019-08-29 10:03 ` Jan Beulich
2019-08-29 15:22 ` Chao Gao
2019-08-29 10:21 ` Roger Pau Monné
2019-09-06 9:01 ` Chao Gao
2019-09-06 9:20 ` Paul Durrant [this message]
2019-09-06 10:28 ` Roger Pau Monné
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=1307d03945d948fd89a6956d77c5ce28@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=chao.gao@intel.com \
--cc=jbeulich@suse.com \
--cc=qemu-devel@nongnu.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).