summaryrefslogtreecommitdiff
path: root/Documentation/nvmem
diff options
context:
space:
mode:
authorJuergen Gross <jgross@suse.com>2020-11-03 15:29:10 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-11-18 18:28:02 +0100
commit4bca9cfde93cf6be2b5e34b87b348e0445dc9727 (patch)
treedd02a884926bf1d82f7c06f93bea592b6134b650 /Documentation/nvmem
parente8947cebce49599fe00bf588954b42742d62c2b2 (diff)
xen/events: defer eoi in case of excessive number of events
commit e99502f76271d6bc4e374fe368c50c67a1fd3070 upstream. In case rogue guests are sending events at high frequency it might happen that xen_evtchn_do_upcall() won't stop processing events in dom0. As this is done in irq handling a crash might be the result. In order to avoid that, delay further inter-domain events after some time in xen_evtchn_do_upcall() by forcing eoi processing into a worker on the same cpu, thus inhibiting new events coming in. The time after which eoi processing is to be delayed is configurable via a new module parameter "event_loop_timeout" which specifies the maximum event loop time in jiffies (default: 2, the value was chosen after some tests showing that a value of 2 was the lowest with an only slight drop of dom0 network throughput while multiple guests performed an event storm). How long eoi processing will be delayed can be specified via another parameter "event_eoi_delay" (again in jiffies, default 10, again the value was chosen after testing with different delay values). This is part of XSA-332. Cc: stable@vger.kernel.org Reported-by: Julien Grall <julien@xen.org> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Wei Liu <wl@xen.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/nvmem')
0 files changed, 0 insertions, 0 deletions