> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 February 2017 10:46 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: xen-devel <xen-de...@lists.xenproject.org> > Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > completion handling" ? > > >>> On 16.02.17 at 11:36, <paul.durr...@citrix.com> wrote: > >> -----Original Message----- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 16 February 2017 10:23 > >> To: Paul Durrant <paul.durr...@citrix.com> > >> Cc: xen-devel <xen-de...@lists.xenproject.org> > >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > >> completion handling" ? > >> > >> >>> On 16.02.17 at 11:13, <paul.durr...@citrix.com> wrote: > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 16 February 2017 09:21 > >> >> > >> >> as it looks to be quite non-trivial an operation, did you happen to > >> >> have to backport commit 480b83162a to 4.4 or older, without > >> >> backporting all the ioreq server stuff at the same time? It looks to > >> >> me as if the issue predates the addition of ioreq servers, and us > >> >> having had customer reports here would seem to make this a > >> >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix > >> >> ioreq-server event channel vulnerability"] also backported, which > >> >> also appears to address a pre-existing issue). > >> > > >> > Sorry, no I don't have a back-port. Agreed that the issue existed prior > >> > to > >> > ioreq servers but the checking was probably sufficiently lax that it > >> > never > >> > resulted in a domain_crash(), just bad data coming back from an > emulation > >> > request. > >> > >> Well, according to the reports we've got, maybe it was less likely > >> to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to > >> get confirmation that the issue was only seen during domain > >> shutdown, which aiui was (leaving aside a guest fiddling with the > >> shared structure, in which case it deserves being crashed) the > >> only condition triggering that domain_crash(). > > > > If it is only on shutdown then that's probably just a toolstack race (since > > QEMU should really by dying cleanly when the guest goes to S5) unless > we're > > talking about a forced shutdown. > > Then I may have misunderstood the original mail thread: Under > what other conditions did this trigger for the original reporters > (Sander and Roger)?
Now you're asking... I'll have to see if I can find the original mail threads. It's possible it was stubdom related... but I could be thinking of something else. Paul > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
