From owner-freebsd-drivers@FreeBSD.ORG Thu May 24 15:39:58 2007 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E72FE16A421 for ; Thu, 24 May 2007 15:39:57 +0000 (UTC) (envelope-from die.gestalt@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 88BB413C455 for ; Thu, 24 May 2007 15:39:57 +0000 (UTC) (envelope-from die.gestalt@gmail.com) Received: by py-out-1112.google.com with SMTP id a29so955003pyi for ; Thu, 24 May 2007 08:39:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XaQW812yOBBYCWfVNDpG9Sy89CsmJtmnEwRSuOIOCOmYPPbxiPXQY4XThhLi1gH9c+e5ZLQZWeu+D8DuqLdjDvAkRER2r9rjgDLHikFlDr5BAZhXpfeGk9AkBJSHlbLpYsXghNSIMM4rDh7Uba7A4JheTtdT7qm7XspslyHb6vY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Ooe2s1XYKjDDUIc+M4RtRJaBmrAK8dOWo4kZ6J0u4dNZeDBABUnHmmgCRuhoim5acm3RBtowjsRaRqTU7y7JTbr0ThWZklILNMFMw+yvUY+T6I7m9Fs0/hHyyXFWdXbokF9JB4FY6N1DTmpKv1N+rs3TlCuxinTfPXBLWeSj6mY= Received: by 10.65.100.14 with SMTP id c14mr3774234qbm.1180021196810; Thu, 24 May 2007 08:39:56 -0700 (PDT) Received: by 10.64.184.8 with HTTP; Thu, 24 May 2007 08:39:56 -0700 (PDT) Message-ID: <5bf3e10d0705240839x17792a96hf17e6eebfa5a83da@mail.gmail.com> Date: Thu, 24 May 2007 17:39:56 +0200 From: "Die Gestalt" To: freebsd-drivers@freebsd.org In-Reply-To: <5bf3e10d0705230314w3038a532uf0d8c0ed18a5d05f@mail.gmail.com> MIME-Version: 1.0 References: <5bf3e10d0705150724q3f0fd25fq89094bd02d8f9d29@mail.gmail.com> <86veetgnk4.fsf@dwp.des.no> <5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff@mail.gmail.com> <5bf3e10d0705221130t222b80b5w64a4e446b04d6029@mail.gmail.com> <863b1nvqqa.fsf@dwp.des.no> <5bf3e10d0705230314w3038a532uf0d8c0ed18a5d05f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Generic int 13h driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2007 15:39:58 -0000 On 5/23/07, Die Gestalt wrote: > > > So I will have to write an interrupt handler that catches the IRQ14, has > got the address of the IRQ14 handler of the BIOS, run this handler in the > VM86, and pray The Great Sysop? :p > Indeed this is what I have to do. I've dwelled inside the heart of the kernel to see how I could set up a hardcore general IRQ 14 handler. This works. This handler should call do a simple vm86_intcall(0x76....) (int 76h is the BIOS handler for the IRQ 14), but the problem is that this results in a deadlock for the very simple fact that the BVM86 is still running waiting for the completion.... I thought about creating a second virtual machine monitor (well simply setting up some pages in locland modifying vm86_initialize and add some vm86_intcall2 functions), but my question is... If I do a vm86_intcall2 from my IRQ14 handler, will the first vm86_datacall (still running) be aware of it? This is Plan A. Plan B would be to be able to stop execution of the first vm86_datacall, save the current context, and replace the code to run before resuming to the IRQ14, when its finished, the previous context is restored. For now I have absolutely no idea about how to do it. :) Well the save/restore context is not very difficult, I could write the following code: save context save ip push marker on stack int 76h -> iret I will end up in vm86_trap in vm86_trap if I see my marker on the stack I do a pop marker restore context get ip back resume execution at ip But how to stop the vm86_datacall and patch it in. It would be much better if Plan A works. :p Any input greatly welcomed.