[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

vPT rework (and timer mode)


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 1 Jul 2020 11:02:10 +0200
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • Delivery-date: Wed, 01 Jul 2020 09:02:27 +0000
  • Ironport-sdr: i8xnSH4MPIXch7CDs6lVi0mHG8WXUgDdXmURI54kbExyL3Z1gYHmQ/MIONC1VwCIl9dXwU8Y4K lPaCcdjNGB1TeAr6GCrU2lk9S+Y+oxcBn7kNkvmDDXTxMsNZT5gzzgt47/3LLrzcq4jpHS1KCm 2abuATUcY6TJFW3SoEFpPRalqkanCAH5XfkUFSC8IXz3HW+4jM6j78/VOTdRJKjM7BIUCzILsp AmoiT1LRijD/kM/tCGJW0A6A0Jkw0ybgaBcfD5hyd1vb+D25Ia1JR3bXCzcZgKqfEVAj4vRh3l GG8=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.