Re: [PATCH v2] x86/hvm/viridian: fix the TLB flush hypercall

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 17 March 2016 08:12
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel@lists.xenproject.org; Keir (Xen.org)
> Subject: RE: [PATCH v2] x86/hvm/viridian: fix the TLB flush hypercall
> 
> >>> On 16.03.16 at 18:35, <Paul.Durrant@citrix.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: 16 March 2016 15:36
> >> >>> On 16.03.16 at 15:21, <paul.durrant@citrix.com> wrote:
> >> > @@ -656,7 +647,9 @@ int viridian_hypercall(struct cpu_user_regs
> *regs)
> >> >           * so we may unnecessarily IPI some CPUs.
> >> >           */
> >> >          if ( !cpumask_empty(pcpu_mask) )
> >> > -            flush_tlb_mask(pcpu_mask);
> >> > +            smp_send_event_check_mask(pcpu_mask);
> >> > +
> >> > +        output.rep_complete = input.rep_count;
> >>
> >> Questions on this one remain: Why only for this hypercall? And
> >> what does "repeat count" mean in this context?
> >>
> >
> > It's only for this hypercall because it's the only 'rep' hypercall we
> > implement. For non-rep hypercalls the spec states that the rep count and
> > starting index in the input params must be zero. It does not state what the
> > value of reps complete should be on output for non-rep hypercalls but I
> think
> > it's safe to assume that zero is correct.
> > For rep hypercalls the spec says that on output "the reps complete field is
> > the total number of reps complete and not relative to the rep start index.
> > For example, if the caller specified a rep start index of 5, and a rep count
> > of 10, the reps complete field would indicate 10 upon successful
> completion".
> >
> > Section 12.4.3 of the spec defines the HvFlushVirtualAddressList hypercall
> > as a rep hypercall and each rep refers to flush of a single guest VA range.
> > Because we invalidate all VA ranges in one go clearly we complete all reps
> > straight away :-)
> 
> Ah, there's an address list associated with it. So if the flush
> request was just for a single page, isn't a flush-all then pretty
> heavy handed?
> 

Yes, it is overkill, but it's probably still less expensive than waking up a de-scheduled vCPU to flush a single page and possibly still less expensive than an IPI to do the same.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel