From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/8] KVM: Adds ability to preempt an executing VCPU Date: Wed, 16 May 2007 13:05:38 +0300 Message-ID: <464AD772.4050007@qumranet.com> References: <20070509023731.23443.86578.stgit@novell1.haskins.net> <20070509030325.23443.90129.stgit@novell1.haskins.net> <46482D2E.7040809@qumranet.com> <464845AD.BA47.005A.0@novell.com> <46488426.8090705@qumranet.com> <46486FD4.BA47.005A.0@novell.com> <46496125.5020909@qumranet.com> <4649679C.BA47.005A.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-Reply-To: <4649679C.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Gregory Haskins wrote: > >> Later we'll have vcpu and thread_info point to each other and then you >> can do that kind of optimization. >> > > I am not familiar with thread_info, but if it solves the dangling pointer problem, that sounds great. It's fairly tricky, but it's the right way forward. It means a 1:1 association of a vcpu and a thread for the lifetime of the vcpu. > It sounds like you are in favor of leaving this optimization for a later time. As long as you are ok with every interrupt related ioctl such as KVM_APIC_MSG, and KVM_ISA_INTERRUPT posting a signal to itself, we can pull this for now. Perhaps you can disable this by noticing that you're injecting an interrupt now (another icky variable in struct kvm_vcpu). > Conversely, if the thread_info approach isn't hard, I would prefer to get this right now, as the double interrupt thing seems nasty to me. > > Alternatively, perhaps I can just replace irq.task with irq.pid? And I could also replace irq.guest_mode with irq.guest_cpu. I will then record the pid where today I record the task. Likewise, I can extract the guest_cpu (using task_cpu(current)) where today I assign irq.guest_mode = 1. That would effectively remove the dangling pointer problem while retaining the features that I like. > pid can dangle just the same as a task pointer, only much worse. > Thoughts? > > >> Oh, and nobody said that the task waiting on the event is the same as >> the task running the vcpu. >> > > I'm a little confused by this statement. I don't use irq.task for assigning a target for the event. That is all self contained in the eventfd. Its true that some of the older designs used this as the send_sig() target, but the assumption there was we were posting a signal to the entire PID, not a specific TID. That could have been a bad assumption, but its moot now. Let me know if you meant something else. > Strike that. I was confused. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/