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

[Juergen Gross <jgross@suse.com>]

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. :-)


Juergen


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