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

[Juergen Gross <jgross@suse.com>]

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?


Juergen


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