On 19/12/2019 19:49, Tamas K Lengyel wrote: > On Thu, Dec 19, 2019 at 12:41 PM Andrew Cooper > <andrew.coop...@citrix.com> wrote: >> On 19/12/2019 19:38, Tamas K Lengyel wrote: >>>>> --- a/xen/include/asm-x86/hvm/hvm.h >>>>> +++ b/xen/include/asm-x86/hvm/hvm.h >>>>> @@ -335,6 +335,10 @@ unsigned long hvm_cr4_guest_valid_bits(const struct >>>>> domain *d, bool restore); >>>>> bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v), >>>>> void *ctxt); >>>>> >>>>> +/* Caller must hold domain locks */ >>>> How about asserting so? >>> AFAICT there is no "domain_locked_by_me" function, only >>> paging/p2m/gfn_locked_by_me. So any suggestion on how to achieve that? >> spin_is_locked() gets you most of the way, and would be a start. >> >> But yes - now you say this, I remember that we don't currently have >> suitable infrastructure. > Is the domain lock even a spin lock (the on you use by > rcu_lock_live_remote_domain_by_id)? Looks to me it just goes down to > "rcu_read_lock" which only does a preempt_disable() call o.O
/sigh - of course we have two things called the domain lock. The RCU one is to ensure that the struct domain can't get freed behind our back, and shouldn't be interesting in this context (obtaining the d pointer in the first place causes it to be safe). If that is the only one which matters, I would drop the comment. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
