[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS
>>> On 24.11.16 at 18:22, <andrew.cooper3@xxxxxxxxxx> wrote: > On 24/11/16 15:25, Jan Beulich wrote: >>>>> On 23.11.16 at 16:38, <andrew.cooper3@xxxxxxxxxx> wrote: >>> + case x86_seg_tr: >>> + ASSERT(reg->attr.fields.p); /* Usable. */ >>> + ASSERT(!reg->attr.fields.s); /* System segment. */ >>> + ASSERT(!(reg->sel & 0x4)); /* !TI. */ >>> + ASSERT(reg->attr.fields.type == SYS_DESC_tss16_busy || >>> + reg->attr.fields.type == SYS_DESC_tss_busy); >>> + ASSERT(is_canonical_address(reg->base)); >>> + break; >> I can't help thinking that the slightly more strict >> >> + if ( reg->attr.fields.type == SYS_DESC_tss_busy ) >> + ASSERT(is_canonical_address(reg->base)); >> + else if ( reg->attr.fields.type == SYS_DESC_tss16_busy ) >> + ASSERT(!(reg->base >> 32)); >> + else >> + ASSERT_UNREACHABLE(); >> >> would be better, even if that's going to make TR checking look a >> little different than the others (but we should leverage the >> information we have). > > I still don't like the use of ASSERT_UNREACHABLE(); as the "you failed > the typecheck" case. > > Would ASSERT(!"%tr typecheck failure") be acceptable? Sure. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |