From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM Date: Thu, 23 Apr 2009 15:28:08 +0100 Message-ID: References: <8686c3cd0904230708w7e0f41c3he3ed303573d52e38@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0954511122==" Return-path: In-Reply-To: <8686c3cd0904230708w7e0f41c3he3ed303573d52e38@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tom Rotenberg Cc: Tim Deegan , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0954511122== Content-type: multipart/alternative; boundary="B_3323345291_6719827" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3323345291_6719827 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable All task switches are emulated, so you can add tracing to hvm_task_switch() to check if a switch has occurred. An alternative is that the guest did another LTR while not being emulated? If you want to remember the last VMEXIT, you=B9ll have to add code to store state away somewhere to pick up on the next VMENTRY. -- Keir On 23/04/2009 15:08, "Tom Rotenberg" wrote: > About the TR, i have re-checked it, and it seems like the TR value is sti= ll > 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the = LTR > code you sent me, and it seems ok, i tend to suspect, that there was some= kind > of (hardware) task switch, which changed the TR value without me knowing,= is > it possible? because otherwise, i can't really explain why the TR value i= s > different than what was loaded from the LTR operation... >=20 > BTW - how can i track what was the previous VMEXIT before this last VMENT= RY > which caused the exception? i think, that probably the last VMEXIT caused= the > "change" to vm86 mode, and this is waht causes the problem... >=20 > Tom >=20 > 2009/4/23 Keir Fraser >> On 23/04/2009 12:44, "Tom Rotenberg" wrote: >>=20 >>> > However, from the VMCS dump, i saw data, which doesn't seem compatibl= e >>> with >>> > this, as the LDTR sellector is indeed 0, but has attributes and limit >>> > different from zero (although it should have been totaly disabled, by= the >>> > LLDT, no?). >>=20 >> The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay= . >>=20 >>> > And more important, the TR selector is 0x58, although from the LTR, i= t was >>> > supposed to be 0x50, no? >>=20 >> If 0x50 was loaded then the selector should certainly be 0x50. >>=20 >> =A0-- Keir >>=20 >>> > (of-course it's possible that there were other instructions who chang= ed it >>> > back, however, i am wondering if there is a problem here). >>=20 >>=20 >=20 --B_3323345291_6719827 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] Doamin crash when trying to install disk encryption = (PointSec) on Windows HVM All task switches are emulated, so you can add tracing to hvm_task_switch(= ) to check if a switch has occurred. An alternative is that the guest did an= other LTR while not being emulated?

If you want to remember the last VMEXIT, you’ll have to add code to s= tore state away somewhere to pick up on the next VMENTRY.

 -- Keir

On 23/04/2009 15:08, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>About the TR, i have re-checked it, and it seems= like the TR value is still 0x58, althoug the LTR operation put 0x50 into it= . Since, i looked at the LTR code you sent me, and it seems ok, i tend to su= spect, that there was some kind of (hardware) task switch, which changed the= TR value without me knowing, is it possible? because otherwise, i can't rea= lly explain why the TR value is different than what was loaded from the LTR = operation...

BTW - how can i track what was the previous VMEXIT before this last VMENTRY= which caused the exception? i think, that probably the last VMEXIT caused t= he "change" to vm86 mode, and this is waht causes the problem... <= BR>
Tom

2009/4/23 Keir Fraser <keir.fraser@e= u.citrix.com>
<= SPAN STYLE=3D'font-size:11pt'>On 23/04/2009 12:44, "Tom Rotenberg" &= lt;tom.rotenberg@gmail.com> wrote:<= BR>
> However, from the VMCS dump, i saw data, which doesn't seem compatible= with
> this, as the LDTR sellector is indeed 0, but has attributes and limit<= BR> > different from zero (although it should have been totaly disabled, by = the
> LLDT, no?).

The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay.
> And more important, the TR selector is 0x58, although from the LTR, it= was
> supposed to be 0x50, no?

If 0x50 was loaded then the selector should certainly be 0x50.

=A0-- Keir

> (of-course it's possible that there were other instructions who change= d it
> back, however, i am wondering if there is a problem here).


=
--B_3323345291_6719827-- --===============0954511122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0954511122==--