From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Wed, 04 Apr 2007 11:09:22 -0500 Message-ID: <4613CDB2.4000903@codemonkey.ws> References: <4610A6A9.BA47.005A.0@novell.com> <46134B74.1080004@qumranet.com> <4613B438.60107@codemonkey.ws> <4613B89F.8090806@qumranet.com> <4613BC6B.1070708@codemonkey.ws> <4613BF07.50606@qumranet.com> <4613C993.9020405@codemonkey.ws> <4613CC01.1090500@qumranet.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: Avi Kivity Return-path: In-Reply-To: <4613CC01.1090500-atKUWr5tajBWk0Htik3J/w@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 Avi Kivity wrote: > Anthony Liguori wrote: >>> Maybe some brave soul can hack kvm to patch the new instruction in >>> place of the mmio instruction Windows uses to bang on the tpr. >> >> It seems like that shouldn't be too hard assuming that the MMIO >> instructions are <= the new CR8 instruction. It would require >> knowing where the TPR is mapped into memory of course. > > Well, we know the physical address (some msr) and the virtual > mapping. But we must be sure that the instruction is only used for > setting the tpr, and not other registers. > > Er, thinking a bit more, cr8 is just 4 bits (and no, not the least > significant) out of the 8-bit tpr, so it doesn't work without serious > hackery. Hrm, so this not nearly as straight forward as I initially hoped :-/ >> >> If we do this, then we can probably just handle the TPR as a special >> case anyway and not bother returning to userspace when the TPR is >> updated through MMIO. That saves the round trip without adding >> emulation complexity. > > That means the emulation is split among user space and kernel. Not > nice. One of the advantages of moving the entire thing is that it is > at least clearly defined. It still exists in userspace. Having the code duplication (especially when it's not the same code base) is unfortunate. Plus, it complicates save/restore/migration since now some device state is in the kernel. It further complicates things if you want to make sure that KVM saved images are loadable in QEMU (you have to make sure that the device state is identical for the kernel and userspace). Special casing the TPR emulation seems like the lesser of two evils to me. Regards, Anthony Liguori ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV