[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.