Re: [Qemu-devel] CVS build error
Well done, guys. Someone's trying to build CVS QEMU on gcc4, and
you're flaming them. This'll really encourage people to work on
making development versions of QEMU work with gcc4.
On 14 Mar 2008, at 10:53, Johannes Schindelin wrote:
WTF?
The point at which you start using profanity on a -devel list is the
point at which you need to put the keyboard down and come back later.
Rick suggested removing that configure message that you need to
explicitely override its quite sane default to refuse work with gcc4,
because at least one platform (the most common one) has problems
with it.
No, by the looks of it, he was refuting Ben's suggestion that it should:
Ben/Rick:
Apparently, we should make configure fail horribly if gcc4 is
found even
if disable-gcc-check is enabled.
Make configure fail horribly? Well, that seems a bit counter-
productive,
don't you think?
--
| Philip Boulain PhD student | #!bash | "After all, dumbing down |
| IAM, ECS, Uni of Southampton | :(){:| | Xanadu sure worked well for |
| http://zepler.net/~lionsphil | :&};:# | Tim Berners-Lee!"-Ted Nelson |
Re: [Qemu-devel] [PATCH] OpenGL for OS X
On 6 Feb 2008, at 06:00, Gwenole Beauchesne wrote: 2008/2/5, Fabrice Bellard <[EMAIL PROTECTED]>: This is an SDL related issue (i.e. SDL may or may not use OpenGL to display graphics). Fixing SDL for Mac OS X would also be interesting. I think SDL trunk (1.3) supports OpenGL rendering more specifically for various platforms. Besides, on my MacBook, fullscreen SDL with a HW surface can indeed perform much better (550 Mpixels/sec) than fullscreen GL (190 Mpixels/sec). With a SW surface, results are equivalent to GL though. In windowed (800x600) mode, SDL performs at 28 Mpixels/sec and GL at 150 Mpixels/sec. So, SDL 1.2 for OSX (CG?) in windowed mode is indeed sub-optimal. I have not tried with SDL trunk yet. You can get my tests as svn co http://svn.beauchesne.info/svn/gwenole/projects/blitter-tests/trunk blitter-tests After some more figures? Modern MacBook Pro (ATI Radeon X1600), just ./configure'd and make'd with defaults: WINDOWED X11 (Apple's server, circa OS X 10.4) best: * Testing XShmPutImage() 607 frames in 10.0 secs, 60.53 fps, 47.600 Mpixels/sec SDL (1.2.12 stable release) best: * Testing SDL_Blit() with RGB masks 00ff,ff00,00ff 600 frames in 10.0 secs, 59.86 fps, 47.078 Mpixels/sec OpenGL (without pixel buffer objects; with was slower) best: * Testing glTexSubImage2D with target GL_TEXTURE_RECTANGLE_ARB, format GL_BGRA, type GL_UNSIGNED_INT_8_8_8_8_REV 2628 frames in 10.0 secs, 262.67 fps, 206.571 Mpixels/sec FULLSCREEN X11 could only produce a screen-size window; it achieved 28.1 Mp/s for comparison. * Testing SDL_Blit() with RGB masks 00ff,ff00,00ff 1379 frames in 10.0 secs, 137.78 fps, 178.558 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_RECTANGLE_ARB, format GL_BGRA, type GL_UNSIGNED_INT_8_8_8_8_REV 1845 frames in 10.0 secs, 184.37 fps, 238.945 Mpixels/sec So, yes, can confirm that stable SDL is currently slooow in windowed mode compared to OGL, and still slower in fullscreen. Interestingly, use of pixel buffer objects made things /slower/ here. I noted very heavy CPU activity for glperf for the GL_TEXTURE_2D, format GL_BGRA, type GL_UNSIGNED_BYTE case, too (also the fastest, RECTANGLE_ARB case, but this may have just been that it was shunting so much more data). Full details below. LionsPhil --- WINDOWED --- # # Running program x11perf # Global test configuration: Per-test duration: 10 seconds Display size: 1024x768, 24 bpp, windowed mode * Testing XPutImage() 361 frames in 10.0 secs, 35.96 fps, 28.279 Mpixels/sec * Testing XShmPutImage() 607 frames in 10.0 secs, 60.53 fps, 47.600 Mpixels/sec # # Running program sdlperf # Test global configuration: Per-test duration: 10 seconds Display size: 1024x768, 32 bpp, windowed mode, SW surface * Testing SDL_Blit() with RGB masks 00ff,ff00,00ff 600 frames in 10.0 secs, 59.86 fps, 47.078 Mpixels/sec * Testing SDL_Blit() with RGB masks 00ff,ff00,00ff 303 frames in 10.1 secs, 30.11 fps, 23.677 Mpixels/sec # # Running program glperf # OpenGL version : 2.0 ATI-1.4.56 OpenGL vendor: ATI Technologies Inc. OpenGL renderer : ATI Radeon X1600 OpenGL Engine OpenGL extensions: GL_APPLE_client_storage GL_APPLE_texture_range GL_APPLE_packed_pixels GL_EXT_abgr GL_EXT_bgra GL_ARB_shading_language_100 GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_pixel_buffer_object GL_EXT_framebuffer_object GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_ARB_texture_non_power_of_two GL_ARB_imaging GL_SGI_color_matrix Global test configuration: Per-test duration: 10 seconds Display size: 1024x768, 32 bpp, windowed mode Use non-power-of-two textures : yes Use pixel buffer objects: no Use Apple client storage extension : no Use Apple texture range extension : no * Testing glTexSubImage2D with target GL_TEXTURE_2D, format GL_RGB, type GL_UNSIGNED_BYTE 257 frames in 10.0 secs, 25.58 fps, 20.115 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_2D, format GL_RGBA, type GL_UNSIGNED_BYTE 2397 frames in 10.0 secs, 239.56 fps, 188.395 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_2D, format GL_BGRA, type GL_UNSIGNED_BYTE 1034 frames in 10.0 secs, 103.21 fps, 81.171 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_2D, format GL_BGRA, type GL_UNSIGNED_INT_8_8_8_8_REV 2618 frames in 10.0 secs, 261.62 fps, 205.744 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_RECTANGLE_ARB, format GL_RGB, type GL_UNSIGNED_BYTE 259 frames in 10.1 secs, 25.75 fps, 20.251 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_RECTANGLE_ARB, format GL_RGBA, type GL_UNSIGNED_BYTE 2377 frames in 10.0 secs, 237.53 fps, 186.804 Mpixels/sec * Testing glTexSubImage2D with target GL_TEXTURE_RECTANGLE_ARB, format GL_BGRA, type GL_UNSIGNED_BYTE 1034 frames in 10.0 secs, 103.22 fps, 81.179 Mpixels/sec
Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
On 1 Feb 2008, at 16:09, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Robert William Fuller <[EMAIL PROTECTED]> writes: : Avi Kivity wrote: : > Anthony Liguori wrote: : >> I think I'll change this too into a single qemu_ram_alloc. That will : >> fix the bug with KVM when using -kernel and large memory anyway :-) : > Won't that cause all of the memory in the hole to be wasted? : Linux doesn't commit mapped memory until it's faulted. As for other : platforms, who knows? It would appear that modern Windows also overcommits: "This memory isn’t allocated until the application explicitly uses it. Once the application uses the page, it becomes committed." "When an application touches a virtual memory page (reads/write/ programmatically commits) the page becomes a committed page. It is now backed by a physical memory page. This will usually be a physical RAM page, but could eventually be a page in the page file on the hard disk, or it could be a page in a memory mapped file on the hard disk." -- http://blogs.msdn.com/ntdebugging/archive/2007/10/10/the-memory- shell-game.aspx So it looks like you could get away with this on the two big host platforms. Most BSDs are also similarly overcommitted. 95% of the users think this is a feature, but the other 5 argue 20 times harder sometimes :-( Some of us don't like the idea that our operating systems lie about how many resources they have available, then have to club innocent processes over the head when their lies catch up with them. ;) Phil
Re: [Qemu-devel] WE NEED GCC 4 please
On 20 Jan 2008, at 22:56, Mike Frysinger wrote: On Sunday 20 January 2008, Sunil Amitkumar Janki wrote: ...what is being done or who can give directions on what would have to be done to make qemu build using gcc4. as i said, review the archives and you'll find many discussions with real information on the topic http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00380.html Work forward (by date) from here. Now please stop this pointless thread. *Useful* gcc4 discussion belongs in critique of those patches. (Thanks to Alex et. al., while I'm posting---hopefully this'll be a great boon for getting Q (kju) to build against SVN qemu some day soon!) LionsPhil
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 18 Sep 2007, at 00:56, Ben Taylor wrote: "J. Mayer" <[EMAIL PROTECTED]> wrote: On Mon, 2007-09-17 at 23:14 +0200, Luca wrote: On 9/17/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Am 17.09.2007 um 14:18 schrieb Christian MICHON: On 9/17/07, Philip Boulain <[EMAIL PROTECTED]> wrote: ...merely acts as bait for the grand old "version repository" flamewar. ...this commit was not disruptive to any of the Git users, and will never be. Both the qemu.org and the Savannah project page only mention CVS. http://brick.kernel.dk/git/?p=qemu.git;a=summary Another point is CVS is an industry standard. The wine folks have been using [git] for a while, (maybe a year?)... ARGH. Unless QEMU is /actually/ going to spend the time switching repository systems for no forward progress, _off-topic_! LionsPhil (SVN beats all, clearly. ;) )
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
> > > > DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. > > > if we were using git (but you can do it locally anyway), you would not > > > have these conflicts problems... > > Maybe... but Savannah uses a CVS frontend, as far as I know... > Those are excuses. So is a "you should have used X" argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old "version repository" flamewar.* > Like whitespace change is breaking your code. Really, I mean, come on. > Who do think you are kidding? Python programmers. ;) LionsPhil * See also, "if they'd used Perl instead of find/xargs/sed...".
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
On Mon, 2007-09-03 at 12:01 +0200, Christian Brunschen wrote: > On 3 Sep 2007, at 11:19, Philip Boulain wrote: > > What's the difference between having to hack about a plain-text, > > few-lines configuration file, and a plain-text, few-lines shell > > script? > The same shells are not (at least by default) available on all > platforms. You only need sh, because all you're doing is an exec, which covers all POSIX platforms. For Windows, use a shortcut. > Basically, requiring a shell script means that you have to meta- > program around qemu itself, whereas a configuration file means you're > writing something within the context of qemu (and thus don't have to > venture outside qemu's domain). Given that the goal is "simple", I'd consider this a plus. 95% of UNIX-like systems is glue.[1] > 2) if 'foo' is a directory: >verify that 'foo' is in fact a vm bundle directory... If this is going to move from frontends to QEMU itself, given that the Q devs have already created a QEMU VM bundle format, it makes sense to use theirs. It's a sensible format, consistent at least with OS X bundle conventions. (Not sure about GNUStep bundles, but given that their both NeXT offspring, I doubt there's much difference.) > Saying that 'Q already handles this' means that any other program > that wants to offer a similar ease-of-use would have to be able to > read and interpret Q's configuration file format. I don't see a problem with this. > If instead there is > a wrapper-neutral format, then each wrapper can use that. This is what Q bundles should be absorbed as. For "simple", there are shell scripts. For "complete", there are bundles, and Q's format is a good one to absorb as "the QEMU bundle format". I don't see the point in a config format which adds nothing but complexity over a shell script. LionsPhil 1. This figure drawn from entirely unauthoritative sources. ;)
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
On 1 Sep 2007, at 21:26, Jorge Lucángeli Obes wrote: I think the problem here is that the scope of this change is not clear. I _really_ wish to keep this simple. I _really_ wish to avoid having giant command lines and useless shell scripts. Surely the small shell script /is/ the simple solution, as it requires zero changes to QEMU itself. What's the difference between having to hack about a plain-text, few- lines configuration file, and a plain-text, few-lines shell script? LionsPhil (Ok, the latter is needlessly Turing complete, so tools can't understand it, but "tools" are i) out of scope ii) better served by Q- style XML plists anyway.)
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 14 Aug 2007, at 00:31, Thiemo Seufer wrote: Philip Boulain wrote: On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: ...implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I don't think it has anything to do with bash. Apparently Windows(NT) cmd.exe introduced this as a way to avoid unwieldy command lines. Cygwin (or MingGW?) added the same to their tools in order to avoid command line length problems. Not so long ago it was implemented for gcc and binutils... Ugh. This is in-application magic that does a pre-parsing step on argv []? I'm suddenly being flooded with horrible memories of how Win-DOS requires each individual application to implement its own wildcards in arguments, and how these implementations were inevitably inconsistent in ways that stabbed you in the face. Maybe QEMU /should/ have a "...and read this file as arguments..." argument, but this really doesn't seem a good way to do it. "-c qemu.cfg" is a lot less ambiguous, as you don't have to worry about whether an '@' in an argument is an include command, or a literal, e.g. part of a filename (it could be either, and escaping it at the shell level won't help). LionsPhil
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I wanted an image to be self-contained as much as possible. That's what I set to achieve. Which tends to collect all the complexity in a single piece. That seems to be the common problem of the option discussed here. As far as I can tell, this is desirable for easy distribution of images to other machines; this is pretty much my only objection to the 'directory' idea, which is otherwise a nice, clean solution. (If not, I can't really see what's wrong with a one-liner sh script alongside the image, which is basically what has been reinvented.) All that said, I rethought Anthony's idea of storing plain text in the image and with proper tools, it can work out. Requiring "proper tools" doesn't leave much of a point for plain text. Correct, but qemu's command-line arguments (and it makes sense to use the same syntax for embedded ones, such that the parser can be re- used) /are/ plain text. Still, it's probably worth thinking of it as a shebang and a serialised (subset of) argv[], rather than /a command line/. In particular, you can avoid having to do sh's job of splitting and escaping again. LionsPhil
Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
Anthony Liguori wrote: Philip Boulain wrote: That should probably be "#!/usr/bin/env qemu", or something similar... I think the magic should just be "#!". Whatever you put as the QEMU executable is your choice. Separating the args to the next line actually does make it pretty portable. Not really; you'd still have to use the editing tool (qemu-img?) to prep it for your particular QEMU binary location on that particular host. But, yes: being able to set arbitrary binaries is essential. Using env is probably a good /default/, though. Yes, I think that another argument should be required as Dan suggested although I'd like something more explicit like "-read-args-from-image". In the case where the image was directly executable, it would be embedded as part of the interpreter arguments. This works, so long as qemu disregards "-read-args-from-image" unless it's being called as an interpreter. Otherwise, you've put the lock and the key in the same place. :) If an image says: #!/whatever/qemu -read-args-from-image -curious-and-interesting-flags This should use those flags: $ ./image.qcow2 And this shouldn't, because you don't need to have made it executable: $ qemu -hda image.qcow2 (But this would:) $ qemu -read-args-from-image -hda image.qcow2 (Side thought: presumably, we're assuming that the in-file and on-command-line arguments are unioned, ideally with the latter taking precidence if mutually exclusive.) This also doesn't apply outside of UNIX-like environments, e.g. Windows... I think this is covered by requiring the additional argument. Agreed. LionsPhil
Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
Yikes. I like the intent, but the idea of a previously just-data file format suddenly being able to imply "-hdb fat:rw:/home/" does not strike me as a good one. :/ andrzej zaborowski wrote: Yes, the file format starting with "#! /path/to/qemu" is a much better idea... That should probably be "#!/usr/bin/env qemu", or something similar, if the intent is that "self-executing" image files are mostly zero-effort portable across (UNIX-y) host environments. Anthony Liguori wrote: The disk image is directly executable and it makes it very clear to the user that they have to trust the disk image. Only if qemu only read the embedded arguments in the case where it was executed as a script interpreter for the image, and/or only if the image's execute bit is set. In other words, this should prevent embedded arguments from being used: $ chmod -x dubious-image.qcow2 $ qemu -hda dubious-image.qcow2 This also doesn't apply outside of UNIX-like environments, e.g. Windows; if someone had told Explorer to launch image files as "qemu.exe -hda (image)" (which is as close to shebanging a data file as you can really get), this could really be a nasty surprise. LionsPhil
Re: [Qemu-devel] Triple-fault causes abort(), which doesn't end pointer grabs
On Tue, 2007-05-08 at 18:38 +0200, Andreas Schwab wrote: > Samuel Bronson <[EMAIL PROTECTED]> writes: > > So, if the guest system has a triple-fault, and I had had my mouse grabbed, > > it > > stays grabbed, so that X has to be restarted (as far as I know). > Not if you have XF86_Ungrab bound to a key. That's a workaround, not a fix. Phil
Re: [Qemu-devel] KQEMU Darwin port status?
On 21 Mar 2007, at 15:39, Derek Fawcus wrote: Well, they seemed to be suggesting that the kernel importing and locking the user space memory was a bit dodgy, and that the kernel should export memory to user space. Or maybe that only really applies in the case of devices... Yes. It's perfectly valid to point out that this is usually a bad thing to do, but to refuse to help on those grounds is---well, unhelpful. Sometimes, you have no choice but to do something which is normally bizzare. (What I /don't/ get is why Bhavesh didn't explain the 'bizzare' circumstances, given that that thread appears to be post-GPL-KQEMU.) I can see why this appears to be a bad thing, but it's also how KQEMU works, and I'm guessing that /that/ is for good reasons, even if they're good reasons on some other platform it supports. (One that comes to mind is that you /probably/ don't want to ask for 4GB of kernel-allocated memory in order to run a VM with 4GB of RAM.) AFAICT, the worst /effect/ of this is that a userland application could cause the kernel to either wire down so much memory that it can't swap things in, or run out of kernel address space, and I would expect those risks to affect other platforms too---in other words, you could probably crash the system from a userland application with access to the /dev/kqemu device. I /don't/ see any reason why it should be "dodgy" in the unpleasant-to-debug--side-effects sense; hopefully because no such reason exists. :) Phil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Documentation bug in QEMU/KQEMU
On 21 Mar 2007, at 06:13, James Jacobs wrote: It is not mentioned that KQEMU is incompatible with Win98SE. It is also not mentioned that it is incompatible with Linux 0.1. However, if you make a closed world assumption (things which are not stated to be true are false), this is easy to infer: "KQEMU is supported on x86 or x86_64 Linux 2.4 or 2.6 hosts. Experimental versions are available for FreeBSD and Windows NT/ 2000/2003/XP." -- http://fabrice.bellard.free.fr/qemu/kqemu-doc.html#SEC1 * Also, \\.\kqemu is not a legal pathname under any version of Windows. If I remember correctly, this is roughly NT-flavour Windows' version of /dev, and you can find such curiosities as \\.\PhysicalDrive0 under there. MSDN probably has more details, if you can find them. Phil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
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
Re: [Qemu-devel] KQEMU Darwin port status?
On 19 Mar 2007, at 20:23, Derek Fawcus wrote: There was just a discussion relating to this on the darwin-kernel list, you may wish to review the archive. (The thread starts at http://lists.apple.com/archives/Darwin-kernel/ 2007/Mar/msg00010.html). Thanks; looking at this post, I'm probably barking up the right tree: http://lists.apple.com/archives/Darwin-kernel/2007/Mar/msg00031.html Unfortunately, rather than confirm or deny this path of reasoning, the others got unhelpfully uppity. =/ LionsPhil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
On 19 Mar 2007, at 08:49, Mike Kronenberg wrote: I have made a empty kext and a dummy client to do some tests on this topics. Boundary crossing is working well, so by now the kext part is ready. http://www.kronenberg.org/files/kqemu_poc.zip Neat, thanks. Unfortunately, Apple decided to remove/hide some of the vm_* API (especially vm_map_(un)wire in Tiger. (It was available on Panther. vm_map_user_pageable was never part of Darwin). So any suggestions on how to lock user pages in Darwin would be very welcome. Mmm, that's rather unhelpful. From my own reading, it looks like the Apple-approved way of doing this would be to use an IOMemoryDescriptor: initWithAddress() would initialise one which represents the appropriate lump of application-space memory (vm_address_t, length, direction [1] and task_t [2]); prepare() and complete() wire and unwire it respectively; and presumably getPhysicalSegment() covers the 'get physical address' part. Using this probably requires making the extension a I/O Kit Device Driver, but that's just a few extra methods to implement AFAICT. I'll see if I can make a trivial test for this approach. Phil 1. kIODirectionOutIn (or InOut) appears suitable here---the kernel- side IOKit headers show both as equivilent to VM_PROT_READ | VM_PROT_WRITE 2. Looking at the FreeBSD version, that's just "current process", so literally current_task() ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] KQEMU Darwin port status?
Hi! I'll keep this succinct, because I'm sure they'd be FAQ-grade questions if this list had a FAQ: :) 1) Where's the version repository for KQEMU? It doesn't appear to be under/alongside QEMU itself. 2) Has anyone made any progress with porting KQEMU to Darwin x86? I've had a look at the GPL release (hurrah) and it looked to me like the platform-specific parts would mostly involve writing an I/O Kit Device Driver which provided a device node with suitable ioctl support [1], as the FreeBSD version does. The mailing list archives show some activity in this area, but without 1) it's hard to get an overview. (There are also obvious-looking compilation problems with the distributed 1.3.0pre11 sources, but I'm guessing that someone who knows assembler better than now has fixed them by now.) Thanks, LionsPhil 1. http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/boundaries/chapter_14_section_6.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
