[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: fix the TLB flush hypercall
>>> On 16.03.16 at 18:35, <Paul.Durrant@xxxxxxxxxx> wrote: >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> Sent: 16 March 2016 15:36 >> >>> On 16.03.16 at 15:21, <paul.durrant@xxxxxxxxxx> 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? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |