From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: XSAVE IRC thread Date: Sat, 4 May 2013 16:51:47 +0100 Message-ID: <51852E93.3020202@citrix.com> References: <517FCF4F.70209@citrix.com> <5183ECC002000078000D3274@nat28.tlf.novell.com> <4ADD30FB-F54D-4A25-93B0-25275753E3C4@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4ADD30FB-F54D-4A25-93B0-25275753E3C4@citrix.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: Ben Guthro Cc: Mark Roddy , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On 04/05/2013 12:13, Ben Guthro wrote: > On May 3, 2013, at 10:58 AM, Jan Beulich > wrote: > >>>>> On 30.04.13 at 18:24, Mark Roddy wrote: >>> The two values are pointers to the before and after regions: >>> >>> 1: kd> dd 841c4880 >>> 841c4880 0000027f 00000000 6e83506e 0000001b >>> 841c4890 01d113d8 00000023 00001f80 0000ffff >>> 841c48a0 00000000 00000000 00000000 00000000 >>> 841c48b0 00000000 00000000 00000000 00000000 >>> 841c48c0 00000000 00000000 00000000 00000000 >>> 841c48d0 00000000 00000000 00000000 00000000 >>> 841c48e0 00000000 00000000 00000000 00000000 >>> 841c48f0 00000000 00000000 00000000 00000000 >>> >>> 1: kd> dd 841c4600 >>> 841c4600 0000027f 00000000 6e83506e 00000000 >>> 841c4610 01d113d8 00000000 00001f80 0000ffff >>> 841c4620 00000000 00000000 00000000 00000000 >>> 841c4630 00000000 00000000 00000000 00000000 >>> 841c4640 00000000 00000000 00000000 00000000 >>> 841c4650 00000000 00000000 00000000 00000000 >>> 841c4660 00000000 00000000 00000000 00000000 >>> 841c4670 00000000 00000000 00000000 00000000 >>> >>> I don't know if that helps, but obviously there are differences, two of >>> them, at offsets 0xc and 0x12. >>> >>> " Interrupt Service Routine 88CAC91C has changed extended thread context. >>> Context saved before executing ISR: 841C4880. Context saved after executing >>> ISR: 841C4600." >>> >>> 841C4880 is before and 841C4600 is after. >> Attached a patch that I think should address this problem. It's >> against the tip of the staging tree, and doesn't apply without >> adjustment to 4.2 (and making it work for 4.1 would be quite a >> bit more work) - please let me know whether that's sufficient for >> you testing this, or whether you need me to do any backporting. >> >> I didn't verify this with any Windows, but since the same issue >> can - if one is looking for it - be observed on PV Linux, I did verify >> the patch to help there. >> >> I'd like to note though that while this is expected to help with >> 32-bit guests, and with a 64-bit guest kernels doing such checking >> after using the respective save (and possibly restore) instructions >> with a 64-bit operand size, the hypervisor has no way of knowing >> whether the context actually belongs to a 32-bit process while the >> guest is in kernel (64-bit) mode. That means that from a 32-bit >> app's perspective, inconsistencies could still be observed under >> certain conditions (but the case where the hypervisor side save >> happens after a VM exit from user mode should also work with >> that patch). I don't see any way to hide that, other than running >> on CPUs that don't save/restore the selector values at all >> anymore (Intel at least has a feature bit for this). >> >> Jan >> >> > Jan, > > Thank you very much for looking into this so quickly. > > Our QA infrastructure is currently set up for testing against our XenClient product built on Xen 4.2.2. > Since this is an intermittent failure, in order to reduce the number of variables in testing this solution, > I'll look into backporting this on Mon to 4.2, and report back after a night, or two of testing. > > Thanks again for your help > > Ben I will also look to getting this into XenServer testing ASAP ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel