On Thu, 21 Jun 2018 16:01:22 +0200
David Hildenbrand <da...@redhat.com> wrote:
> On 21.06.2018 15:14, Thomas Huth wrote:
> > On 20.06.2018 12:08, David Hildenbrand wrote:
> >> +/* Set Clock */
> >> +uint32_t HELPER(sck)(CPUS390XState *env, uint64_t tod_low)
> >> +{
> >> + S390TODState *td = s390_get_tod();
> >> + S390TODClass *tdc = S390_TOD_GET_CLASS(td);
> >> + S390TOD tod = {
> >> + .high = 0,
> >> + .low = tod_low,
> >> + };
> >> + Error *err = NULL;
> >> +
> >> + qemu_mutex_lock_iothread();
> >> + tdc->set(td, &tod, &err);
> >> + qemu_mutex_unlock_iothread();
> >> + g_assert(!err);
> >
> > I know it currently can't happen, but still, I think it would be nicer
> > to use CC3 to tell the guest that something went wrong with the clock,
> > instead of abort QEMU here.
>
> Hmm, I thing I should either use error_abort here or do what you suggest.
>
> However, CC=3 means "Clock in not-operational state".
>
> And this implies that also STORE CLOCK and friends will have to fail and
> that we have to present a machine check. Especially, once we would
> implement the TOD-clock steering facility, CC=3 would not apply anymore.
>
> So instead of faking something that is not architecturally correct, I
> think we really should just quit QEMU, as we expect this to never fail.
I think error_abort is the best way to handle that, then.
