Re: [Xen-devel] [PATCH v2 01/20] x86: make hvm_{get/set}_param accessible

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Thu, Dec 19, 2019 at 12:57 PM Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 19/12/2019 19:49, Tamas K Lengyel wrote:
> > On Thu, Dec 19, 2019 at 12:41 PM Andrew Cooper
> > <andrew.cooper3@xxxxxxxxxx> 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.

Yes, only the RCU lock gets taken right now by all callers, so I'll
drop the comment.

Thanks,
Tamas

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