Re: [Xen-devel] [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Nov 22, 2018 at 06:52:07PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 5:37 PM, Roger Pau Monné wrote:
> > I don't think you are supposed to try to pause other vcpus while
> > holding a lock, as you can see it's quite likely that you will end up
> > deadlocking because the vCPU you are trying to pause is stuck waiting
> > on the lock that you are holding.
> > 
> > You should figure out whether you can get into vmx_start_reexecute
> > without holding any locks, or alternatively drop the lock, pause the
> > vCPUs and pick the lock again.
> > 
> > See for example how hap_track_dirty_vram releases the lock before
> > attempting to pause the domain for this same reason.
> 
> Right, this will take more thinking.
> 
> I've unlocked the p2m for testing and the initial hang is gone, however
> the same problem now applies to rexec_lock: nothing prevents two or more
> VCPUs from arriving in vmx_start_reexecute_instruction() simultaneously,
> at which point one of them might take the lock and try to pause the
> other, while the other is waiting to take the lock, with predictable
> results.
> 
> On the other hand, releasing rexec_lock as well will allow two VCPUs to
> end up trying to pause each other (especially unpleasant in a 2 VCPU
> guest). At any given moment, there should be only one VCPU alive and
> trying to reexecute an instruction - and at least one VCPU alive on the
> guest.
> 
> We'll get more coffee, and of course suggestions are appreciated (as has
> been all your help).

Hm, I don't think it's generally safe to try to pause domain vCPUs
from the same domain context, as you say it's likely to deadlock since
two vCPUs from the same domain might try to pause one another.

My knowledge of all this introspection logic is very vague, do you
really need to stop the other vCPUs while performing this reexecution?

What are you trying to prevent by pausing other vCPUs?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel