On Aug 18, 2014, at 12:13 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Il 17/08/2014 23:09, Paolo Bonzini ha scritto: >> Il 17/08/2014 21:32, Nadav Amit ha scritto: >>> This reverts commit 5045b468037dfe1c848827ce10e99d87f5669160. Although the >>> cs.dpl=cs.rpl check is mentioned in table 7-1 of the SDM as causing a #TSS >>> exception, it is not mentioned in table 6-6 that lists "invalid TSS conditions" >>> which cause #TSS exceptions. As it causes some tests, which pass on bare-metal, >>> to fail - it should be reverted. >> >> Right. However, I think reverting the patch is too big a hammer. We >> still need in_task_switch to raise TS_VECTOR instead of GP_VECTOR, so I >> propose instead something like: >> >> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c >> index 56657b0bb3bb..cd230b035514 100644 >> --- a/arch/x86/kvm/emulate.c >> +++ b/arch/x86/kvm/emulate.c >> @@ -1468,7 +1468,7 @@ static int __load_segment_descriptor(struct x86_emulate_ctxt *ctxt, >> return ret; >> >> err_code = selector & 0xfffc; >> - err_vec = GP_VECTOR; >> + err_vec = in_task_switch ? TS_VECTOR : GP_VECTOR; >> >> /* can't load system descriptor into segment selector */ >> if (seg <= VCPU_SREG_GS && !seg_desc.s) >> @@ -1491,9 +1491,6 @@ static int __load_segment_descriptor(struct x86_emulate_ctxt *ctxt, >> goto exception; >> break; >> case VCPU_SREG_CS: >> - if (in_task_switch && rpl != dpl) >> - goto exception; >> - >> if (!(seg_desc.type & 8)) >> goto exception; >> > > Also, what about the rpl > cpl test below, for non-conforming code > segments? It is not mentioned in table 6-6 either. As far as I understand, after task-switch cpl = cs.rpl. This is how the load_state_from_tss32 does it, and follows SDM 7.3, Task Switching: "The new task begins executing at the privilege level specified in the CPL field of the CS register, which is loaded from the TSS.” As a result, this condition can never occur during task-switch. Do I miss anything? Nadav -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
