All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: vPT rework (and timer mode)
Date: Wed, 1 Jul 2020 11:02:10 +0200	[thread overview]
Message-ID: <20200701090210.GN735@Air-de-Roger> (raw)

Hello,

I've been doing some work with the virtual timers infrastructure in
order to improve some of it's shortcomings. See:

https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00919.html

For an example of such issues, and how the emulated timers are not
architecturally correct.

It's my understanding that the purpose of pt_update_irq and
pt_intr_post is to attempt to implement the "delay for missed ticks"
mode, where Xen will accumulate timer interrupts if they cannot be
injected. As shown by the patch above, this is all broken when the
timer is added to a vCPU (pt->vcpu) different than the actual target
vCPU where the interrupt gets delivered (note this can also be a list
of vCPUs if routed from the IO-APIC using Fixed mode).

I'm at lost at how to fix this so that virtual timers work properly
and we also keep the "delay for missed ticks" mode without doing a
massive rework and somehow keeping track of where injected interrupts
originated, which seems an overly complicated solution.

My proposal hence would be to completely remove the timer_mode, and
just treat virtual timer interrupts as other interrupts, ie: they will
be injected from the callback (pt_timer_fn) and the vCPU(s) would be
kicked. Whether interrupts would get lost (ie: injected when a
previous one is still pending) depends on the contention on the
system. I'm not aware of any current OS that uses timer interrupts as
a way to track time. I think current OSes know the differences between
a timer counter and an event timer, and will use them appropriately.

This would allow to get rid of pt_update_irq and pt_intr_post calls in
the VMX/SVM interrupt injection paths, and likely simplify the virtual
timers code quite a lot. Note the guest would also always track the
real wallclock.

AFAICT such change would also allow to get rid of the per-vCPU vpt
lists.

Wanted to get some feedback on this approach before starting to do the
work, since as said above it will involve dropping the timer modes.

Thanks, Roger.


             reply	other threads:[~2020-07-01  9:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01  9:02 Roger Pau Monné [this message]
2020-07-03 14:50 ` vPT rework (and timer mode) Jan Beulich
2020-07-03 15:02   ` Andrew Cooper
2020-07-06  7:03     ` Paul Durrant
2020-07-06  8:31       ` Roger Pau Monné
2020-07-06  8:58         ` Paul Durrant
2020-07-21 11:53           ` Roger Pau Monné
2020-07-21 13:14             ` Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200701090210.GN735@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.