From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: kvm-ppc@vger.kernel.org
Subject: Re: Ubuntu
Date: Thu, 12 Nov 2009 20:07:03 +0000 [thread overview]
Message-ID: <1258056423.2140.360.camel@pasglop> (raw)
In-Reply-To: <1257986097.2140.70.camel@pasglop>
On Thu, 2009-11-12 at 11:59 +0100, Alexander Graf wrote:
>
> Oh you mean it will basically avoid us firing off a timer for mtdec 1?
Well, I wasn't specifically thinking about the mtdec 1 case (which we
would get rid off by emulating an MPIC instead of the old pmac pic) but
in general, it would overall simplify the emulation.
So there are two aspects here we are mixing up. Let me clarify:
- Doing the TB based target thingy simplifies the calculation as to
whether we need to fire off a DEC interrupt to the guest and provides a
better overall emulation of the DEC behaviour since the DEC ticks at the
same rate as the TB.
- My other idea to modify the CPU DEC instead of firing a hrtimer is a
separate thing. We could stick to a hrtimer if you want, and thus only
set it at mtdec time, though as you said, it's going to be not nice with
the mtdec 1 that linux does with the pmac PIC. But in general, I find it
a lot simpler and -less-code- to just whack the real DEC on exit to be
the min(guest_DEC,host_DEC). No need to go through all of the hrtimer
code etc...
> So the only really novel thing I see here is that small mtdecs don't
> require a timer but instead the timer only gets issued on the next
> exit. I'm not sure that's a good idea though :-/. It'd probably be
> better to just define a minimum threshold.
I wasn't thinking about a minimum threshold. No, we must not have DEC
firing too early. The guest will get confused if it hits before the
timebase reaches the expected value and the interrupt will be "lost"
> on mtdec:
>
> if (reg < 5)
> fire_off_dec();
> else
> fire_dec_on(reg);
>
> Something like that.
>
> I don't want to depend on the host DEC being the clocksource btw. So
> anything munching guest and host DEC together (like pHyp does)
> sounds
> like bad design to me. Let's better have hrtimers handle the case
> where we don't need a real interrupt.
Why ? Everybody is asserted to the CPU timebase. That's the real clock
source for both host and guest today and you can't do anything about it
since mftb isn't going to trap. The DEC counts off the TB. So it's going
to be more precise and less code to just muck around with the DEC to
trigger the guest interrupts don't you think ?
Cheers,
Ben.
prev parent reply other threads:[~2009-11-12 20:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-12 0:34 Ubuntu Benjamin Herrenschmidt
2009-11-12 10:19 ` Ubuntu Alexander Graf
2009-11-12 10:28 ` Ubuntu Benjamin Herrenschmidt
2009-11-12 10:34 ` Ubuntu Alexander Graf
2009-11-12 10:53 ` Ubuntu Benjamin Herrenschmidt
2009-11-12 10:59 ` Ubuntu Alexander Graf
2009-11-12 20:07 ` Benjamin Herrenschmidt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1258056423.2140.360.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=kvm-ppc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.