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

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

On Fri, Jun 05, 2020 at 04:20:31PM +0200, Jan Beulich wrote:
> On 05.06.2020 16:16, Roger Pau Monné wrote:
> > On Fri, Jun 05, 2020 at 12:05:12PM +0200, Jan Beulich wrote:
> >> On 05.06.2020 11:20, Roger Pau Monné wrote:
> >>> On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote:
> >>>> On 05.06.2020 09:50, Roger Pau Monne wrote:
> >>>>> This patch provides such mediated access to the
> >>>>> RTC for PVH dom0, just like it's provided for a classic PV dom0.
> >>>>>
> >>>>> Instead of re-using the PV paths implement such handler together with
> >>>>> the vRTC code for HVM, so that calling rtc_init will setup the
> >>>>> appropriate handlers for all HVM based guests.
> >>>>
> >>>> Hooking this into rtc_init() makes sense as long as it's really
> >>>> just the RTC. Looking at the PV code you're cloning from, I
> >>>> wonder though whether pv_pit_handler() should also regain callers
> >>>> for PVH. As it stands the function is called for PV only, yet was
> >>>> deliberately put/kept outside of pv/.
> >>>
> >>> IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not
> >>> enable it for PVHv2 because no one really knew why the PIT was
> >>> actually needed for by dom0.
> >>
> >> I think the reason PV Dom0 has it applies to PVH Dom0 as well:
> >> At least back at the time there were video BIOSes needing this.
> >> As it now turns out to have been a mistake to not enable the
> >> RTC handling for v2, I would still think it would be better to
> >> enable the PIT logic as well there, just to be on the safe side.
> > 
> > I have to admit I haven't used video output very much with PVH, I've
> > had reports of people having success with it, but I have no idea how
> > many failures there might be.
> > 
> > Enabling the PIT for PVH dom0 is mostly a matter of adding
> > XEN_X86_EMU_PIT to the emulation flags, like it's currently done for
> > PV dom0.
> > 
> > There's going to be a slight issue though, which is that the PIT will
> > try to inject the interrupts using the PIC IRQ0, and thus would either
> > need to also enable the PIC, or to instead set the timer source to
> > PTSRC_ioapic instead of PTSRC_isa and use GSI 0. I haven't actually
> > tried whether this would work, but seems better than enabling the PIC.
> 
> But what we do for PV Dom0 doesn't go as far as injecting IRQs (let
> alone IRQ0). It's just the few port accesses that we allow them to
> make (successfully, i.e. seeing the relevant bare hardware bits).

It seems cleaner to me to just provide the whole thing for PVH, rather
than what we do for classic PV, in which we allow some accesses to the
real hardware.

I understand there's no need to give dom0 access to the real PIC, and
that using the emulated one should work just fine.

Roger.