> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 17 March 2016 08:12 > To: Paul Durrant > Cc: Andrew Cooper; xen-de...@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.durr...@citrix.com> wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 16 March 2016 15:36 > >> >>> On 16.03.16 at 15:21, <paul.durr...@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
