From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: kvm-ppc@vger.kernel.org
Subject: Re: Ubuntu
Date: Thu, 12 Nov 2009 10:53:40 +0000 [thread overview]
Message-ID: <1258023220.2140.346.camel@pasglop> (raw)
In-Reply-To: <1257986097.2140.70.camel@pasglop>
> Hum, that would defer DEC interrupts to "the next exit". So if your
> guest is sitting in a spin lock for example, it wouldn't get a DEC
> because it doesn't exit from the guest context to actually check if
> TARGET_DEC < TB.
Ah no, you still set a target..
> I think the only really good way of doing this is to use the hrtimer
> to trigger the interrupt, not clear the interrupt injection bit, but
> only clear it on mtdec.
>
> That way we get the interrupt to actually interrupt the guest context,
> but instantly trigger the DEC in the guest when it sets IF=1.
>
> I think I had a define for an "alternative" DEC method in book3s.c,
> that basically checks mfdec() against 0 on every exit. Feel free to
> try out of that one helps :-).
I saw that. My idea was more low-level:
- Guest set DEC, you calculate & cache target
- On exit to guest, you check target against TB, if passed, then a DEC
interrupt is pending for guest. If EE is set, you "deliver" it.
- If not passed, the substraction give you a DEC value (time to next
DEC expected by guest). You set the DEC to min(DEC,value), ie, you
make it fire the soonest of the guest DEC target vs. linux host guest
target. Linux can cope just fine with spurrious DEC interrupts btw.
You have to do some modulo 32 bit etc... but basically, it should work
and it sounds simpler to me and will avoid the churn with timers etc...
Cheers,
Ben.
next prev parent reply other threads:[~2009-11-12 10:53 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 ` Benjamin Herrenschmidt [this message]
2009-11-12 10:59 ` Ubuntu Alexander Graf
2009-11-12 20:07 ` Ubuntu Benjamin Herrenschmidt
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=1258023220.2140.346.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.