Re: [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 04/14/2016 11:18 AM, Juergen Gross wrote:
> On 14/04/16 10:01, Andrew Cooper wrote:
>> On 14/04/2016 08:46, Juergen Gross wrote:
>>> On 14/04/16 08:31, Razvan Cojocaru wrote:
>>>> On 04/14/16 09:09, Juergen Gross wrote:
>>>>> On 14/04/16 07:56, Razvan Cojocaru wrote:
>>>>>> This indeed doesn't guard against LOCKed instructions being run in
>>>>>> parallel with and without emulation, however that is a case that should
>>>>>> almost never occur - at least not with introspection, where currently
>>>>>> all emulation happens as a result of EPT faults - so either all
>>>>>> instructions hitting a restricted page are emulated, or all ar run
>>>>>> directly. As long as all emulation can safely run in parallel and all
>>>>>> parallel non-emulation is also safe, it should be alright. But, yes,
>>>>>> this patch doesn't cover the case you're mentioning.
>>>>> What about grant pages? There could be parallel accesses from different
>>>>> domains, one being introspected, the other not.
>>>> I'm not familiar with the code there, but the main issue is, I think,
>>>> LOCKed instructions that access (read / write) the same memory area - as
>>>> long as that doesn't happen, it should be fine, which may be the reason
>>>> why it hasn't caused problems so far.
>>> Depends on the guest, I suppose. :-)
>>>
>>> I've been bitten by this before in my former position: we had a custom
>>> pv-driver in dom0 which wasn't using LOCKed instructions accessing a
>>> grant page. Reason was dom0 had one vcpu only and the Linux kernel
>>> patched all LOCKs away as it didn't deem them being necessary. This
>>> resulted in a very hard to debug communication failure between domU
>>> and dom0.
>>>
>>>> While not perfect, I believe that the added safety is worth the small
>>>> performance impact for writes. I feel that going from unsafe parallel
>>>> emulation to safe parallel emulation is a good step to take, at least
>>>> until the problem can be fixed completely by more complex measures.
>>> I'm fine with you saying for your use case the solution is good enough.
>>>
>>> Just wanted to point out a possible problem. This might not happen
>>> for most guest types, but you can't be sure. :-)
>>
>> But accesses into a mapped grant don't trap for emulation.  Why would
>> locks here be any different to usual?
> 
> With memory introspection switched on they will trap, won't they?

Only write or execute instructions referencing a handful of a HVM
guest's pages trap for emulation with our introspection application,
otherwise performance would be terrible - we don't trap all instructions
for emulation.


Thanks,
Razvan

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