[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.