Re: [Xen-devel] [PATCH v4 4/5] x86/PV: use generic emulator for privileged instruction handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/12/2016 07:35, Jan Beulich wrote:
>>>> On 13.12.16 at 17:53, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 13/12/16 11:28, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -1185,7 +1185,7 @@ static int ioport_access_check(
>>>  
>>>      fail_if(ops->read_segment == NULL);
>>>      if ( (rc = ops->read_segment(x86_seg_tr, &tr, ctxt)) != 0 )
>>> -        return rc;
>>> +        return rc == X86EMUL_DONE ? X86EMUL_OKAY : rc;
>> Please have at least a comment here
>>
>> /* Used by the PV path to defer the port permission check to the ioport
>> hooks. */
> I'll probably use a slight variation thereof, as I'd prefer to not
> mention specific uses (being too easy to go stale).
>
>>>      /* Ensure the TSS has an io-bitmap-offset field. */
>>>      generate_exception_if(tr.attr.fields.type != 0xb, EXC_GP, 0);
>>>
>> Other than that, subject to double checking the IOPL behaviour,
>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> These tests are fine.

I have to admit that I am now curious as to how.  By pretending that the
iopl of the guest kernel is 0 rather than 1, I'd expect the case of
vIOPL of 0 and real CPL 1 to break. The in-guest behaviour of this
scenario was to raise #GP faults with the guest kernel.

>  Of the pv-cpuid-faulting ones, which you had
> asked for during v3 review, the pv32pae one gets skipped (no
> faulting available), and the pv64 one even has a problem getting at
> the guest console. I am getting that same problem randomly for
> other tests too, though, if I run multiple ones in one batch. No idea
> what to do about that. Running that one test in isolation doesn't
> eliminate the problem though; the hypervisor log tells me that the
> test has been skipped just like the 32-bit one (as one would expect).

That is a race condition with `xl console`, which isn't sufficiently
synchronised with the previous `xl create` when setting up console
information in xenstore.

There is an alternative --results-mode=logfile and optional
--logfile-dir=/path if you have xenconsoled configured in a non-standard
way.

http://xenbits.xen.org/gitweb/?p=xtf.git;a=commitdiff;h=97541e1fde20b6823fa146357a57ec7c6f802c05

However, this isn't the default because it puts a large quantity of
serialisation in makes back-to-back running of tests an order of
magnitude slower, but it is the mode uses by OSSTest.

I am still trying to find a better solution to this problem.

~Andrew

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