[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode
On 02/05/18 16:09, Jan Beulich wrote: >>>> On 02.05.18 at 17:08, <boris.ostrovsky@xxxxxxxxxx> wrote: >> On 05/02/2018 11:00 AM, Jan Beulich wrote: >>>>>> On 02.05.18 at 16:57, <boris.ostrovsky@xxxxxxxxxx> wrote: >>>> On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>>>>> On 30.04.18 at 18:23, <boris.ostrovsky@xxxxxxxxxx> wrote: >>>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> >>>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> >>>>> >>>>> But to understand why things have been working nevertheless it would >>>>> have been nice if the commit message wasn't empty, but instead said >>>>> something like "The two happen to be identical on 64-bit." >>>> Why do you think they are identical? __KERNEL_CS points to entry#12 >>>> (which we don't specify in PVH GDT) while __BOOT_CS is the second entry >>>> (which we do create). >>> That's 32-bit's __KERNEL_CS. If the two weren't identical, the ljmp >>> you adjust would never have worked afaict. >> >> Oh, right. My theory was that we were picking up something from the >> stack (which is where 12th entry would be pointing) and the L bit, which >> I think is the only one we'd care about, happened to always be set there. > I don't think the L bit is the only one we care about, as I don't think you > can load a non-code selector into CS (even if none of the attributes are > later used for anything). The type/s/dpl/p/d/l attributes still very much matter even in 64bit. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |