qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KQEMU Darwin port status?


From: Mike Kronenberg
Subject: Re: [Qemu-devel] KQEMU Darwin port status?
Date: Tue, 20 Mar 2007 09:02:35 +0100

Cool :)

just dlded your tarball, and things work well.

I'm about to add the code to the "genuine" kqemu environment. With kqemu Variables and function stubs.
I hope to post back soon.

Mike


On 20.03.2007, at 03:18, Philip Boulain wrote:

Mike Kronenberg wrote:
> So any suggestions on how to lock user pages in Darwin would be very welcome.

Philip Boulain wrote:
Thanks; looking at this post, I'm probably barking up the right tree

Right. I've cobbled up the aformentioned prototype, and it working insofar that the modified and now-leaky version of Mike's test client is allocating sequential lumps of memory when you bash the EXEC button, and I'm getting plausible sequential physical addresses out; I can also read/write to the memory via the IOMemoryDescriptor (the client initialises the first uint8 of the 'lump' to 23, which will appear in the system log/console; the kext writes 42 to it, which will appear in the client).

http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- kqemu-19mar07.tar.bz2 (1934KB)

Summary of changes to Mike's earlier example:
- 'transporter' struct now has a 'uint8_t* lump_of_ram;' member, to act as some application-allocated memory (it mallocs (and never frees, ahem) 2K each EXEC ioctl). - I dropped Mike's KEXT code into the HelloIOKit example, so that it does all the IO KEXT initialisation. I'm not convinced that this is actually necessary. A side effect is that 'kqemu.ext' is now called 'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;)
 - The KQEMU_EXEC ioctl handling case now:
- Constructs a IOGeneralMemoryDescriptor and initialises it to point to the lump_of_ram in the transporter struct - 'Prepares' the Descriptor. I believe that this is performing the required locking: "This involves paging in the memory, if necessary, and wiring it down for the duration of the transfer." [1] - Prints the physical address to the system log, and does the aformentioned read/write
   - 'Completes' the Descriptor (unlocking)
- Destructs (pedantically: unreferences) the IOGeneralMemoryDescriptor

[De]constructing a fresh IOGMD each time is rough-prototype-code garbage. One can be recycled by just calling initWithAddress() again on it---at a _glance_, it looks like the kqemu_instance struct would be a sensible place to put it.

Phil
1. http://developer.apple.com/documentation/Darwin/Reference/ KernelIOKitFramework/IOMemoryDescriptor/Classes/IOMemoryDescriptor/ index.html



_______________________________________________
Qemu-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]