[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KQEMU Darwin port status?
From: |
Philip Boulain |
Subject: |
Re: [Qemu-devel] KQEMU Darwin port status? |
Date: |
Tue, 20 Mar 2007 02:18:45 +0000 |
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] KQEMU Darwin port status?, Philip Boulain, 2007/03/17
- Re: [Qemu-devel] KQEMU Darwin port status?, Mike Kronenberg, 2007/03/19
- Re: [Qemu-devel] KQEMU Darwin port status?, Philip Boulain, 2007/03/19
- Re: [Qemu-devel] KQEMU Darwin port status?, Derek Fawcus, 2007/03/19
- Re: [Qemu-devel] KQEMU Darwin port status?, Philip Boulain, 2007/03/19
- Re: [Qemu-devel] KQEMU Darwin port status?,
Philip Boulain <=
- Re: [Qemu-devel] KQEMU Darwin port status?, Mike Kronenberg, 2007/03/20
- Re: [Qemu-devel] KQEMU Darwin port status?, Mike Kronenberg, 2007/03/20
- Re: [Qemu-devel] KQEMU Darwin port status?, Mike Kronenberg, 2007/03/20
- Re: [Qemu-devel] KQEMU Darwin port status?, Derek Fawcus, 2007/03/21
- Re: [Qemu-devel] KQEMU Darwin port status?, Philip Boulain, 2007/03/21