This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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.


Xen-devel mailing list