Re: [Xen-devel] [PATCH 2/2] x86/emul: Bugfixes to SYSCALL emulation

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/12/2016 08:22, Jan Beulich wrote:
>>>> On 19.12.16 at 17:37, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Introduce vendor_is() to allow emulation to have vendor-specific
>> behaviour.  Adjust the SYSCALL behaviour on Intel to raise #UD when
>> executed outside of 64bit mode.
> I'd rather not see us go this route. I've been carrying a patch
> making the vendor an input (not submitted so far due to other
> at least contextual prereqs missing when I last check, but sent
> out just a minute ago). What do you think?

Rebasing on top of that would be far more simple.

>
>> in_longmode() has different return semantics from rc, so use a separate
>> integer for the purpose.
> The ugliness of the additional #ifdef doesn't seem to warrant
> this.

It is a matter of correctness.  The only reason we exit from it cleanly
is because the cannot_emulate path discards rc, while the other paths
overwrite rc because of hitting the read_msr() or write_segment() hooks
in each case.

> What I've been thinking the other day though is: Why
> don't we put the whole SYSCALL emulation into a __XEN__
> conditional (implying __x86_64__, i.e. allowing the inner ones
> to be removed)?

This depends on whether we think it is ever realistic to be able to be
able to test things like this in the userspace harness.  I am not sure
we realistically can.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel