[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110112095428.GA15835@fermat.math.technion.ac.il>
Date: Wed, 12 Jan 2011 11:54:28 +0200
From: "Nadav Har'El" <nyh@...h.technion.ac.il>
To: Xiao Guangrong <xiaoguangrong@...fujitsu.com>
Cc: Avi Kivity <avi@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] KVM: send IPI to vcpu only when it's in guest mode
On Wed, Jan 12, 2011, Xiao Guangrong wrote about "[PATCH v3 2/3] KVM: send IPI to vcpu only when it's in guest mode":
> We can interrupt the vcpu only when it's running in guest mode
> to reduce IPI
Hi,
I am afraid there's a risk of confusion between the new
vcpu->mode = IN_GUEST_MODE;
and the existing
is_guest_mode() (i.e., vcpu->arch.hflags & HF_GUEST_MASK)
The latter says that the virtual cpu is in guest mode (i.e., the guest used
VMLAUNCH and is runnning a nested guest), while the former says that the
physical CPU that this vcpu is currently being run on, is in guest mode - or
in other words, this vcpu is currently running.
I'm not sure what is the best way to resolve this potential for confusion.
Maybe on of them is better renamed (e.g., instead of vcpu->mode = IN_GUEST_MODE
have something like vcpu->running = NOW_RUNNING). Or maybe some good comments
need to to be written to explain the situation.
Actually, I just noticed that there's already a vcpu->guest_mode which you
are apparently replacing, so the potential for confusion is already in the
current code... I.e., in the current code, is_guest_mode(vcpu) does NOT check
vcpu->guest_mode...
--
Nadav Har'El | Wednesday, Jan 12 2011, 7 Shevat 5771
nyh@...h.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Hi! I'm a signature virus! Copy me into
http://nadav.harel.org.il |your signature to help me spread!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists