From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 1/5] tools/xc_restore: Initialise console and store mfns Date: Mon, 25 Nov 2013 13:16:24 +0000 Message-ID: <52934DA8.5040300@citrix.com> References: <1385377551-20826-1-git-send-email-andrew.cooper3@citrix.com> <1385377551-20826-2-git-send-email-andrew.cooper3@citrix.com> <21139.16021.471316.355461@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21139.16021.471316.355461@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org On 25/11/13 12:12, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH 1/5] tools/xc_restore: Initialise console and store mfns"): >> If the console or store mfn chunks are not present in the migration stream, >> stack junk gets reported for the mfns. >> >> XenServer had a very hard to track down VM corruption issue caused by exactly >> this issue. Xenconsoled would connect to a junk mfn and incremented the ring >> pointer if the junk happend to look like a valid gfn. > A question that arises here is this: > > How come this was going undetected ? > > If the junk mfn _doesn't_ look like a valid gfn (which presumably it > mostly doesn't), surely this generates some error message somewhere > (even if it only causes the console not to work) ? > > Ian. This was a XenServer optimisation to avoid allocating an event channel in dom0 for hvm domains which wouldn't be using it anyway. We only officially support Windows hvm domains, so this is a blanket change for all hvm domains. We were not expecting any hvm consoles to work in the slightest, and xenconsoled gave no hint of errors. ~Andrew