[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? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |