> -----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. > > Once I have aforementioned confirmation, would you mind if I > asked you to look over the backports, should I manage to create > them in the first place? > Sure. No problem. Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
