[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v1 1/1] Invalidate cache for cpus affinitized to the domain
On 14.12.2020 10:26, Shamsundara Havanur, Harsha wrote: > On Mon, 2020-12-14 at 09:52 +0100, Jan Beulich wrote: >> On 11.12.2020 12:44, Harsha Shamsundara Havanur wrote: >>> A HVM domain flushes cache on all the cpus using >>> `flush_all` macro which uses cpu_online_map, during >>> i) creation of a new domain >>> ii) when device-model op is performed >>> iii) when domain is destructed. >>> >>> This triggers IPI on all the cpus, thus affecting other >>> domains that are pinned to different pcpus. This patch >>> restricts cache flush to the set of cpus affinitized to >>> the current domain using `domain->dirty_cpumask`. >> >> But then you need to effect cache flushing when a CPU gets >> taken out of domain->dirty_cpumask. I don't think you/we want >> to do that. >> > If we do not restrict, it could lead to DoS attack, where a malicious > guest could keep writing to MTRR registers or do a cache flush through > DM Op and keep sending IPIs to other neighboring guests. Could you outline how this can become a DoS? Throughput may be (heavily) impacted, yes, but I don't see how this could suppress forward progress altogether. Improved accounting may be desirable here, such that the time spent in the flushes gets subtracted from the initiator's credits rather than the vCPU's which happens to run on the subject pCPU at the time. This is a more general topic though, which was previously brought up: Time spent in servicing interrupts should in general not be accounted to the vCPU running of which happened to be interrupted. It's just that for the majority of interrupts the amount of time needed to handle them is pretty well bounded, albeit very high interrupt rates could have the same effect as a single interrupt taking very long to service. An intermediate option (albeit presumably somewhat intrusive) might be to use e.g. a tasklet on each CPU to effect the flushing. This wouldn't reduce the overall hit on the system, but would at least avoid penalizing other vCPU-s as to their scheduling time slices. The issuing vCPU would then need pausing until all of the flushes got carried out. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |