qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 00/10] i8254, i8259 and running Microport UNI


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH v7 00/10] i8254, i8259 and running Microport UNIX (ca 1987)
Date: Tue, 11 Dec 2012 11:20:05 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Matthew Ogilvie wrote:
> 2. Just fix it immediately, and don't worry about migration.  Squash
>    the last few patches together.  A single missed periodic
>    timer tick that only happens when migrating
>    between versions of qemu is probably not a significant
>    concern.  (Unless someone knows of an OS that actually runs
>    the i8254 in single shot mode 4, where a missed interrupt
>    could cause a hang or something?)

Hi Matthew,

Such as Linux?  0x38 looks like mode 4 to me.  I suspect it's used in
tickless mode when there isn't a better clock event source.

linux/drivers/clocksource/i8253.c:

        #ifdef CONFIG_CLKEVT_I8253
           /* ... */

                case CLOCK_EVT_MODE_ONESHOT:
                        /* One shot setup */
                        outb_p(0x38, PIT_MODE);

           /* ... */

        /*
         * Program the next event in oneshot mode
         *
         * Delta is given in PIT ticks
         */
        static int pit_next_event(unsigned long delta, struct 
clock_event_device *evt)
        {
                raw_spin_lock(&i8253_lock);
                outb_p(delta & 0xff , PIT_CH0); /* LSB */
                outb_p(delta >> 8 , PIT_CH0);           /* MSB */
                raw_spin_unlock(&i8253_lock);

                return 0;
        }

           /* ... */
        #endif

> 4. Support both old and fixed i8254 models, selectable at runtime
>    with a command line option.  (Question: What should such an
>    option look like?)  This may be the best way to actually
>    change the 8254, but I'm not sure changes are even needed.
>    It's certainly getting rather far afield from running Microport
>    UNIX...

I can't see a reason to have the old behaviour, if every guest works
with the new one, except for this awkward cross-version migration
thing.

I guess ideally, device emulations would be versioned when their
behaviour changes, rather like shared libraries are, and the
appropriate old version kept around to be loaded for a particular
machine that's still running with it.  Sounds a bit complicated though.

Best,
-- Jamie



reply via email to

[Prev in Thread] Current Thread [Next in Thread]