On Fri, Mar 18, 2011 at 11:18:40AM +0100, Jan Kiszka wrote:
> On 2011-03-15 21:12, Jan Kiszka wrote:
> > On 2011-03-15 18:10, Marcelo Tosatti wrote:
> >> On Tue, Mar 15, 2011 at 12:26:17PM +0100, Jan Kiszka wrote:
> >>> KVM only requires to set the raised IRQ in CPUState and to kick the
> >>> receiving vcpu if it is remote.
> >>>
> >>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
> >>> ---
> >>> kvm-all.c | 11 +++++++++++
> >>> 1 files changed, 11 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/kvm-all.c b/kvm-all.c
> >>> index 226843c..25ab545 100644
> >>> --- a/kvm-all.c
> >>> +++ b/kvm-all.c
> >>> @@ -650,6 +650,15 @@ static CPUPhysMemoryClient kvm_cpu_phys_memory_client = {
> >>> .log_stop = kvm_log_stop,
> >>> };
> >>>
> >>> +static void kvm_handle_interrupt(CPUState *env, int mask)
> >>> +{
> >>> + env->interrupt_request |= mask;
> >>> +
> >>> + if (!qemu_cpu_is_self(env)) {
> >>> + qemu_cpu_kick(env);
> >>> + }
> >>> +}
> >>> +
> >>
> >> Not sure its worthwhile to allow different handlers. The advantage over
> >> tcg version is that its shorter, without cpu_unlink_tb and icount
> >> handler?
> >
> > I thought about this again as well before posting, and I came to the
> > conclusion that an important advantage is avoiding TCG surprises in KVM
> > code paths. This way, KVM does not need to bother if cpu_unlink_tb or
> > icount related code changes. Maybe I should have added this to the
> > commit message.
>
> What's your opinion on this? Should I repost the remaining three with
> comments adjusted?
>
> Jan
>
Its up to you. Your argument above makes sense.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
