Re: (tiny) patch review: return if RTC diag fails

On Thu, Feb 13, 2025 at 04:22:49PM -0500, Greg Troxel wrote:
> Manuel Bouyer <[email protected]> writes:
> 
> > I'm not sure what you call "bad/odd RTC behavior". Here we're just
> > reading a byte of the sram, its value can be anything from 0 to 0xff.
> > This value is supposed to be written by the BIOS.
> >
> > I think, from our current definition of NVRAM_DIAG_BITS, that some bits
> > are not supposed to be set to 1, but I'm not sure if our NVRAM_DIAG_BITS
> > is up to date.
> >
> > Are you suggecting that we should find another way to detect if the
> > mc146818 is present ? AFAIK it's the other way round: unless we know it's
> > not present (because e.g. we're in an environnement known to not have
> > it like some hypervisors or emulators) we have to assume it's present
> > (because it's a mandatory part of the hardware).
> 
> I am suggesting that if the code is going to decide the RTC is bad
> because of a timeout or a bad value, and not use it, then that shouldn't
> have anything to do with 'are we a vm'. That's all.

In the case of the VM the problem is not that it's bad, but that it's not
present (and, I guess, there is another RTC provised by the hypervisor in
this case). but AFAIK we don't have a way to know if the RTC is
present or not.

Maybe a solution would be to not call startrtclock() at all in the VM
case. It's called from cpu_configure() and we're already checking
for VM_GUEST_XENPVH here.

-- 
Manuel Bouyer <[email protected]>
     NetBSD: 26 ans d'experience feront toujours la difference
--