| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] question about patch 13252
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 19.03.09 15:49 >>>
>On 19/03/2009 14:34, "Lu, Guanqun" <guanqun.lu@xxxxxxxxx> wrote:
>
>> Thanks for your reply.
>>
>> It makes a little sense...
>> But the problem is that when we do S3,
>> we execute load_TR() again (in file arch/x86/acpi/suspend.c),
>> and this causes the bug.
>>
>> Do we need to go back to non-compat gdt_table when it resumes, and
>> switch to compat_gdt_table again?
There must be code clearing the B bit in the non-compat GDT already,
otherwise loading of the LDTR would always have faulted.
>Ah, I see. There are a few options, the easiest of which is to leave the B
>bit clear in both descriptors. I'm not certain whether that actually matters
>for any reason, but I think for our purposes it does not.
No, that's not an option afaict: On an outgoing TSS (i.e. during a double
fault) the B bit must be set iirc.
>If Jan can counter my claim, then you can instead switch back to the
>non-compat GDT for the LTR, or you can decide which descriptor to set B in
>based on which GDT you're running on, or force the B bit in both descriptors
>after the LTR, or... You have a few options. :-)
Correct. I wonder why you're running on the compat GDT in the first place -
is your Dom0 32-bit? If that's the case, then the clearing of the bit that must
exist somewhere simply should be extended to touch the current GDT
rather than the default one.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home