Here we go:
www.kronenberg.org/qemu/qemu-devel-darwin-kqemu-20mar07.tar.bz2
- Made a new IOKit kext proj to match all the kqemu name requirements
- moved kext header inside kqemu-darwin.cpp to lessen stray darwin
related files
- added kqemu-kernel.h to the target
- added kqemu.h to the target
- added stubs from kqemu-kernel.h
- moved the test cases to the "playground"
The kqemuClient is updated to work with the kext and its playground.
Next I will start filling in the stubs and kqemu_open/close and
kqemu_ioctl based on Phils prototype.
- Wondering how to convert a physical address to a page index on...
feel free to be faster :)
Mike
On 20.03.2007, at 09:02, Mike Kronenberg wrote:
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
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
