Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jun 05, 2020 at 04:43:12PM -0700, Roman Shaposhnik wrote:
> On Fri, Jun 5, 2020 at 4:03 AM Roger Pau Monne <roger.pau@xxxxxxxxxx> wrote:
> >
> > Mediated access to the RTC was provided for PVHv1 dom0 using the PV
> > code paths (guest_io_{write/read}), but those accesses where never
> > implemented for PVHv2 dom0. This patch provides such mediated accesses
> > to the RTC for PVH dom0, just like it's provided for a classic PV
> > dom0.
> >
> > Pull out some of the RTC logic from guest_io_{read/write} into
> > specific helpers that can be used by both PV and HVM guests. The
> > setup of the handlers for PVH is done in rtc_init, which is already
> > used to initialize the fully emulated RTC.
> >
> > Without this a Linux PVH dom0 will read garbage when trying to access
> > the RTC, and one vCPU will be constantly looping in
> > rtc_timer_do_work.
> >
> > Note that such issue doesn't happen on domUs because the ACPI
> > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing
> > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the
> > accesses are not emulated but rather forwarded to the physical
> > hardware.
> >
> > No functional change expected for classic PV dom0.
> 
> For the dense guys like me: what is the user-visible feature that is now being
> offered with this? Would really appreciate a pointer or two.

Without this dom0 is not able to change the date. Note that
XENPF_settime{32/64} doesn't write the changes to the RTC (at least on
x86), so dom0 needs to write such changes to the RTC so they can
survive a poweroff.

However dom0 cannot be given direct access to the registers, since the
RTC uses an indirect access interface using two IO registers, so Xen
needs to trap such accesses by dom0 in order to serialize them and
prevent conflicts with Xen accesses to the RTC.

Roger.