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:45:28PM +0200, Roger Pau Monné wrote:
> 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
                                                               ^ PIT.
> that using the emulated one should work just fine.
> 
> Roger.
>