>>> On 06.12.16 at 17:49, <andrew.coop...@citrix.com> wrote: > On 06/12/16 11:13, Jan Beulich wrote: >> @@ -2359,7 +2360,7 @@ x86_decode( >> } >> } >> >> - if ( override_seg != -1 && ea.type == OP_MEM ) >> + if ( override_seg != x86_seg_none ) >> ea.mem.seg = override_seg; > > Could we get away with asserting ea.type == OP_MEM if override_seg is > set, to help validate our assumptions about state? (Possibly even > passing #UD back in the non-debug case)
That would be wrong - we'd be asserting guest controlled state. There's nothing preventing a segment override to be present on instructions without memory operands. And for example string insns don't have OP_MEM set despite having (implicit) memory operands (after all that's the hole reason for the change here [but not the patch as a hole], as the following PV priv-op patch requires the segment override to take effect on OUTS). Nor would such be correct for conditional branches, where some of the segment overrides have a different meaning (necessarily ignored by the emulator). > Otherwise, Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> Let me know of the applicability of this in the light of the above. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
