Re: [Qemu-devel] Sparc-linux-user problem
On Sat, 28 Apr 2007 18:20:55 +0100 Paul Brook <[EMAIL PROTECTED]> wrote: > On Saturday 28 April 2007, Blue Swirl wrote: > > Hi, > > > > I'm investigating why Sparc32 user emulator breaks when linked with > > -lrt. It seems that other libraries also cause the problem, for > > example -lm -ldl -lX11 -lbfd -lslang is okay, but -lm -ldl -lX11 > > -lbfd -lslang -lglib-2.0 segfaults just like -lm -lrt. If just > > address space conflict was the issue, I'd think 12 megs libbfd > > would trigger the problem instead of 64k librt. > > > > Any ideas? > > I've never got this to work reliably on either x86 or amd64 hosts. I > get mysterious segfaults in the depths of libc. My guess is that the > tricks qemu uses to link itself as a shared library are confusing > things (possibly the TLS initialisation). I don't suppose using gcc/binutils -fPIE/-pie would achieve qemu's goals, thus avoiding the need to specify bespoke ld scripts? -- Kevin F. Quinn signature.asc Description: PGP signature
CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)
On Fri, 9 Feb 2007 22:48:51 + Paul Brook <[EMAIL PROTECTED]> wrote: > I've very little sympathy (read: none) for people who "accidentally" > break things by running them as root. On a related note, I've been running qemu(-system 0.8.2) as root recently as a hopefully temporary measure so that it can setup the network interfaces. Recent linux kernels require CAP_NET_ADMIN for the tun network configuration that qemu does (specifically the TUNSETIFF ioctl), and the only way to get the capability is to start the process as root. Other capabilities could be dropped; as indeed could CAP_NET_ADMIN once the network configuration is done, but that means modifications to qemu itself to release the capabilities, and would still leave qemu as a suid-root binary, which it would be nicer to avoid. Is there any way around this? I expected to be able to configure capabilities for executables in the filesystem, but it appears there are serious problems with that concept so the kernel doesn't support it. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] OpenSPARC OBP source code available
On Sat, 02 Sep 2006 08:30:53 +0200 "Blue Swirl" <[EMAIL PROTECTED]> wrote: > But before downloading that 195,508,750 bytes package, would you > happen to know what is the licence for OBP source, and would there be > problems working with both OBP and OpenBIOS (GPL)? http://opensparc-t1.sunsource.net/download_sw.html "The Hypervisor and OBP source code is released under BSD license" http://opensparc-t1.sunsource.net/bsd.html Doesn't get much better than that :) -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to reply when receiving digest mode
On Wed, 02 Aug 2006 21:31:02 + "Steve Ellenoff" <[EMAIL PROTECTED]> wrote: > I must be blind and stupid, but I don't see any obvious easy way to > reply to a message when I get the list via dialy batched digest mode. > Replying is a pain, as I have to do it manually by surfing to the > mail archives, find the thread I want to reply, and cut & paste the > text etc.. Is there any easier way? I'd prefer to keep digest mode if > possible, but replying is becomming annoying. > I was thinking that each digest message would have some kind of reply > link, but if it does, I don't see it.. If you choose MIME digests (where every message is an attachment), and your email client is smart enough, you can reply to the individual attachments. I couldn't say whether hotmail is smart enough, however. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
On Fri, 28 Jul 2006 15:58:06 +0200 Udo 'Robos' Puetz <[EMAIL PROTECTED]> wrote: > Soo, do you have any more ideas what qemu can what the (free) > alternatives from M$/VMWare can't? Well, in addition to system emulation qemu that I'd guess most users want qemu for, it has "user" emulation where you can run for xample an ARM binary on an x86 host. It also emulates many targets, not just the x86/x86_64 that VMware or VirtualPC support - bear in mind these are virtualisation tools, not emulators, where as qemu is primarily an emulator with virtualisation acceleration for native x86/x86_64 targets. This makes qemu great for cross-target development. See www.scratchbox.org for example. Obviously qemu also has the advantage that (apart from the virualisation module kqemu) it's open source, which means a lot to many people, at least for me! -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
On Sat, 8 Jul 2006 11:13:52 -0400 "Jim C. Brown" <[EMAIL PROTECTED]> wrote: > Good question. I'm not aware of a way to call Python code from inside > of C. See http://docs.python.org/ext/ext.html However doing this just means yet another language dependency. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Have any ideas about how to detect whether a program is running inside QEMU?
On Thu, 6 Jul 2006 16:46:40 -0400
Daniel Serpell <[EMAIL PROTECTED]> wrote:
> But there is a way to detect virtual machines under x86, see
> http://invisiblethings.org/papers/redpill.html
>
> But if you run qemu without direct instruction copying, it won't
> work (and qemu will run slower), because qemu will correctly
> emulate the unprivileged instructions.
Out of interest, sidt returns limit:base 07ff:c0372000 on my
host, and 07ff:f005 on a linux guest with kqemu, and 07ff:c04b5000
on the same linux guest without kqemu, which illustrates the point.
I used the following code:
#include
int main(int argc, char **argv) {
unsigned char idtr[6];
__asm__ ("sidt %0" : "=m" (*&idtr));
fprintf(stdout,
"IDTR: limit %2.2x%2.2x base %2.2x%2.2x%2.2x%2.2x\n",
idtr[1],idtr[0],idtr[5],idtr[4],idtr[3],idtr[2]);
}
which doesn't need executable heap (my kernel is PaX-enabled), unlike
the redpill version, but is gcc-specific.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Have any ideas about how to detect whether a program is running inside QEMU?
On Thu, 6 Jul 2006 15:18:14 +0800 "James Lau" <[EMAIL PROTECTED]> wrote: > My program is a utility for internet payment. It takes an important > role in the payment process to ensure security. One of the key > functions is that the program should detect which machine is paying. Why does this matter? Why do you care which machine the user is using when they pay? What about people using internet cafes? Surely it's the user who is paying, and you need to securely authenticate the user. I don't see that whether they're using a virtual machine or not is relevant. > So while virtual machine (like QEMU) is present, it can cheat the > program. Checking the hard disk model, cpu type, and other hardward > informations makes little sense. Because the users or the hackers > can easily modify these informations. So I need a QEMU internal > checking method that hackers can't easily bypass. I think you're wasting your time. Any "internel checking method" will be easily bypassed anyway. Kev. > Thanks > > --James > > > 2006/7/6, John R. Hogerhuis <[EMAIL PROTECTED]>: > > > > On Thu, 2006-07-06 at 13:04 +0800, James Lau wrote: > > > hi everybody, > > > For some security issues, I want to detect whether my Windows > > > program is running inside qemu. Have any ideas? > > > > > > > Security issues? That's a bit vague. > > > > More information about what you're attempting to do would be > > helpful. > > > > There are probably lots of ways to do this, but which ones make > > sense for your situation depends on various factors. > > > > -- John. > > > > > > > > > > ___ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > -- Kevin F. Quinn ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Make -std-vga the default?
On Wed, 28 Jun 2006 06:30:51 +0100 Paul Brook <[EMAIL PROTECTED]> wrote: > On Wednesday 28 June 2006 02:21, Julian Seward wrote: > > I've been using -std-vga for a couple of weeks now, and it works > > well at least for the guests I've been using (Win2K/XP, Red Hat 9, > > SuSE 10.1). > > Really? My win2k install couldn't do anything useful with -std-vga. > It would only do the very basic 640x480x4 mode. I'm fairly sure win9x > can't do anything useful with straight VGA either. Same here. Also std-vga seemed to be slower than cirrus when I tried it recently on my linux guests, although I haven't actually measured anything. > > Overall it seems to work much better than the default 5446 Julian, in what way is std-vga better than the cirrus emulation? > > simulation and it seems to me that non-developer users, who are > > presumably the larger fraction of the user base, would benefit from > > having -std-vga as the default. The "it just works" property is > > important for new users, and -std-vga has more of that than the > > 5446 just at the moment. > > In my experience the Cirrus emulation "just works", and is supported > by pretty much every OS out the box. AFAIK Windows earlier than XP > doesn't needs additional 3rd party drivers to support anonymous VESA > hardware. Seconded - the default should be the one best supported by guests out of the box. As it stands, that's cirrus. > > Paul > -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On Thu, 22 Jun 2006 20:53:54 -0500 Anthony Liguori <[EMAIL PROTECTED]> wrote: > Kevin F. Quinn wrote: > > Part of that should be to determine what the GUI will actually do; > > You're getting ahead of yourself. Just getting qemu to start with > wxWidgets instead of SDL would be a big step in the right direction. > > > At this point you're talking about embedding the Qemu guest window > > directly into the wxWidgets GUI, yes? I'm thinking the primitives > > that the graphics driver in QEMU is emulating are not at the GL > > level, but at the raw hardware level - I don't know how far apart > > these things are, but I'd hazard that a GL canvas won't really help. > > > > QEMU doesn't expose any real 2d acceleration to the drawing > routines. Using GL canvas would be interesting though as you'd get > hardware scaling with interpolation. That's a big performance win. And scaling the guest window would be really useful... > > I do think the ability to pass through accelerated graphics stuff > > from the guest to the host should be a big factor. I assume this > > is what the cirrus emulation currently does through SDL, to some > > extent at least. This issue would make or break guest graphics > > performance. > > Nope, currently SDL is used as one big bitmap viewer. > > > I'm ignorant of details, but from a vague hand-wavy distance it > > should be simple enough to retain SDL for the emulation windows > > (and SDL does seem to be the tool for the job there), with a > > separate wxWidgets > > Bleh, why would you say that? SDL is pretty crappy on X. It's just > a wrapper around XShmImage. You can access the same thing via GTK or > any other reasonable toolkit. Ok; my ignorance is shining through :) I thought SDL did a lot more than that. > SDL is mostly useful because of the number of backend drivers that it > supports. Had a rummage through the wxWidgets code. It uses SDL for sound support (or can do so, at any rate) but not for video. With the GTK backend you get an XShm image if XShm is supported (wxGTK asks GTK for GDK_IMAGE_FASTEST). I don't find any references to XShm in the x11 backend, so I guess the raw X11 backend doesn't use it. On X you'd normally go for the GTK backend anyway. > Regards, > > Anthony Liguori > > > frontend GUI to manage the launch and visibility of emulation > > windows, assist in guest creation etc. > > > > Perhaps it's worth asking the WxWidgets people what they might > > suggest. > > > > > >> Regards, > >> > >> Anthony Liguori > >> > >> > >>> If someone is interested, I am ready to try to include such a GUI > >>> in the QEMU repository even if it is not usable yet. > >>> > >>> Regards, > >>> > >>> Fabrice. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On Thu, 22 Jun 2006 16:50:10 -0500 Anthony Liguori <[EMAIL PROTECTED]> wrote: > Fabrice Bellard wrote: > > Hi, > > > > Concerning the QEMU GUI, my mind slightly evolved since my last > > posts on the topic: I think that a wxWidgets GUI would be the best > > as it is reasonnably portable and because it uses the native GUIs. > > I think the first step is to validate whether wxWidgets will be > adequate. Part of that should be to determine what the GUI will actually do; in particular should it "wrap" the guest window, or should it be a separate window for guest selection, configuration etc (which is my preference). The latter case should allow the guest window to remain SDL, with the guest selection/configuration stuff in wxWidgets. > I've not used it myself but poked around the site a > little. It appears there's a gl canvas which should be a reasonable > place to start. It seems like overkill for QEMU though. At this point you're talking about embedding the Qemu guest window directly into the wxWidgets GUI, yes? I'm thinking the primitives that the graphics driver in QEMU is emulating are not at the GL level, but at the raw hardware level - I don't know how far apart these things are, but I'd hazard that a GL canvas won't really help. > Does anyone know a wxWidget which provides direct pixel access to > something that ends up being a XShmImage? If they're canvas uses a > normal XImage performance is going to be pretty crappy. I do think the ability to pass through accelerated graphics stuff from the guest to the host should be a big factor. I assume this is what the cirrus emulation currently does through SDL, to some extent at least. This issue would make or break guest graphics performance. I'm ignorant of details, but from a vague hand-wavy distance it should be simple enough to retain SDL for the emulation windows (and SDL does seem to be the tool for the job there), with a separate wxWidgets frontend GUI to manage the launch and visibility of emulation windows, assist in guest creation etc. Perhaps it's worth asking the WxWidgets people what they might suggest. > Regards, > > Anthony Liguori > > > If someone is interested, I am ready to try to include such a GUI > > in the QEMU repository even if it is not usable yet. > > > > Regards, > > > > Fabrice. > > > > > > ___ > > 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 -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Fri, 16 Jun 2006 17:07:32 +0200 "Christian MICHON" <[EMAIL PROTECTED]> wrote: > you're putting c++ inside the qemu source tree when it is not > needed (yet). Perhaps I'm still not making myself clear. I did _not_ suggest that a WxWidgets GUI be integrated into QEMU. I assumed we were all talking about an independent controller app to provide a pretty clicky-button way to start/stop qemu instances, provide console and serial i/o terminals, that sort of thing. The only thing that may be worth thinking about is a way to redirect the SDL output from QEMU, if VNC proves too slow. Even that would only be if you want the QEMU screen to be embedded in the frontend, and to be honest I see no need for that. > if SDL is common to most guest screens: I agree with you > that the gui/toolkit should overlay the SDL. > > Yet Fabrice mentionned months ago this was not his > intention, so we should respect it and (hopefully) close > this long thread. > > On 6/16/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote: > > On Fri, 16 Jun 2006 13:45:24 +0100 > > Stuart Brady <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote: > > > > > > > WxWidgets (www.wxwidgets.org) provides a nice way out of this - > > > > provides a uniform API for the application developer, and local > > > > look-and-feel for each platform. WxWidgets can sit on gtk, > > > > motif, x11, win32, mac, cocoa (doesn't appear to be a qt > > > > backend yet, but no reason there couldn't be). > > > > > > Yes, there should be abstraction between the UI and the VM, but I > > > think that the approach taken by xine, gstreamer, cdrecord, > > > cdparanoia, etc. is much cleaner. You could still write a > > > frontend with WxWidgets... > > > > > > I think it would be best if QEMU didn't depend on any particular > > > toolkit, and that includes WxWidgets. > > > > I was suggesting WxWidgets as a way to avoid writing separate gui > > frontends for each platform (that's what WxWidgets is for). I wasn't > > suggesting WxWidgets be embedded into Qemu (or the other way around > > for that matter). If you want a pretty controller app and you want > > to avoid cross-platform issues WxWidgets does a lot of the work for > > you (much more than just gtk for example). In particular I was > > responding to the statement > > > > > Face it, putting a GUI on something like QEMU is going to require > > > at least a one per desktop/platform effort. > > > > I don't see any reason to hack up qemu just to put a pretty face on > > it. VNC support already provides an easy way to place the guest > > screen wherever you want if you don't like the SDL window (although > > I think SDL remains the best choice for the guest screen). > > http://code.technoplaza.net/wx-sdl/ talks about combining WxWidgets > > and SDL, although I don't know if that's useful. > > > > -- > > Kevin F. Quinn > > > > > > ___ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > > -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Fri, 16 Jun 2006 13:45:24 +0100 Stuart Brady <[EMAIL PROTECTED]> wrote: > On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote: > > > WxWidgets (www.wxwidgets.org) provides a nice way out of this - > > provides a uniform API for the application developer, and local > > look-and-feel for each platform. WxWidgets can sit on gtk, motif, > > x11, win32, mac, cocoa (doesn't appear to be a qt backend yet, but > > no reason there couldn't be). > > Yes, there should be abstraction between the UI and the VM, but I > think that the approach taken by xine, gstreamer, cdrecord, > cdparanoia, etc. is much cleaner. You could still write a frontend > with WxWidgets... > > I think it would be best if QEMU didn't depend on any particular > toolkit, and that includes WxWidgets. I was suggesting WxWidgets as a way to avoid writing separate gui frontends for each platform (that's what WxWidgets is for). I wasn't suggesting WxWidgets be embedded into Qemu (or the other way around for that matter). If you want a pretty controller app and you want to avoid cross-platform issues WxWidgets does a lot of the work for you (much more than just gtk for example). In particular I was responding to the statement > Face it, putting a GUI on something like QEMU is going to require at > least a one per desktop/platform effort. I don't see any reason to hack up qemu just to put a pretty face on it. VNC support already provides an easy way to place the guest screen wherever you want if you don't like the SDL window (although I think SDL remains the best choice for the guest screen). http://code.technoplaza.net/wx-sdl/ talks about combining WxWidgets and SDL, although I don't know if that's useful. -- Kevin F. Quinn ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Thu, 15 Jun 2006 16:17:09 -0500 John Morris <[EMAIL PROTECTED]> wrote: > On Thu, 2006-06-15 at 09:18, Joe Lee wrote: > > > I appreciate the effort that some are making to develop a GUI for > > QEMU - There's a few project I see that trying to achieve this. > > But, I wish they all could come together and work together to > > develop a nice GUI. I would like to see a sub-project exist in the > > QEMU site so all can come and contribute to that effort. > > Geez, why not ask for world peace while you are at it. One GUI? So > which toolkit? Pick Gtk and watch the K folk whine. Ok, so KDE it > is. Oops, now the Gnomes are all over ya. And of course since I > suspect a non-trivial percentage of QEMU users are on Windows, > Solaris, etc. they ain't gonna like either of those choices much. WxWidgets (www.wxwidgets.org) provides a nice way out of this - provides a uniform API for the application developer, and local look-and-feel for each platform. WxWidgets can sit on gtk, motif, x11, win32, mac, cocoa (doesn't appear to be a qt backend yet, but no reason there couldn't be). > Face it, putting a GUI on something like QEMU is going to require at > least a one per desktop/platform effort. And that can best be kept > with the GNOME/KDE/etc software repositories because they require > constant updating on the schedule of the rest of the desktop > environment to stay current. > > Think of it like mkisofs/cdrecord/growisofs/cdrdao vs the abundance of > graphical front ends that all make use of them. Nobody has to totally > reinvent the wheel because those solid CLI only parts can be reused by > each project and each graphical environment gets a totally native (ok, > several) GUI CD/DVD authoring/burning program instead of one crappy > ported program. > -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu
On Sat, 13 May 2006 20:08:47 -0500 "wayne tempel" <[EMAIL PROTECTED]> wrote: > I have versions 0.7.2 and 0.8.1 > installed on my computer. It was working just fine, but now it's not. > Do I need to uninstall the 0.7.2 version? It keeps telling me Qemu > acceleration layer is not activated. If you've updated your kernel since installing Qemu, you'll need to re-install the kernel module. Check whether /lib/modules/`uname -r`/misc/kqemu.ko exists and is loaded before you run Qemu: lsmod | grep kqemu should show it loaded. I'd remove 0.7.2 if you're successfully using 0.8.1. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug report : kqemu and self-writing code
Looks like SELinux to me. Even - you should raise it with whoever
writes your policy.
On Mon, 01 May 2006 23:29:54 +0200
Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Are you sure that the bug is really in kqemu ? It is possible that
> your guest kernel implements a security system which prevents self
> modifying code using segment limits which QEMU does not check (but
> kqemu checks them !).
>
> Regards,
>
> Fabrice.
>
> Even Rouault wrote:
> > Guest OS : Linux 2.6.15-1.2054_FC5 i686 (Fedora Core 5 i386)
> > Host OS: Linux 2.6.12-10-amd64-k8 #1 x86_64 (Ubuntu 5.10 amd64)
> > QEMU Version : today CVS compiled with kqemu support
> > KQEMU : 1.3.0pre6
> > Binary used : qemu-system-x86-64 (so kqemu user-mode is used)
> >
> > I'm running the simple C code attached. With kqemu user-mode, this
> > fails (sigsegv) with the following warning in dmesg :
> >
> > audit(1146505373.813:12): avc: denied { execheap } for pid=1860
> > comm="selfmodifying scontext=user_u:system_r:unconfined_t:s0
> > tcontext=user_u:system_r:unconfined_t:s0 tclass=process
> > Erreur de segmentation
> >
> > Without kqemu enabled, it runs fine.
> >
> >
> >
> >
> >
> > #define _XOPEN_SOURCE 600
> > #include
> > #include
> > #include
> > #include
> >
> > int main(int argc, char** argv)
> > {
> > int pagesize = getpagesize();
> > unsigned char* addr = NULL;
> > posix_memalign((void**)&addr, pagesize, pagesize);
> > mprotect(addr, pagesize, PROT_WRITE | PROT_READ | PROT_EXEC);
> > addr[0] = 0x8b; addr[1] = 0x44; addr[2] = 0x24; addr[3] =
> > 0x04; /* mov0x4(%esp),%eax */ addr[4] = 0x83; addr[5] = 0xc0;
> > addr[6] = 0x01; /* add$0x1,%eax */ addr[7] = 0xc3; /* ret */
> >
> > printf("10+1=%d\n", ((int (*)(int))addr)(10));
> > free(addr);
> > return 0;
> > }
> >
> >
> >
> >
> > _______
> > 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
--
Kevin F. Quinn
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ./configure --help and gcc checks
On Thu, 6 Apr 2006 14:33:30 +0200 (CEST) Sylvain Petreolle <[EMAIL PROTECTED]> wrote: > Hi people, > I have gcc 3.2.3 (run as gcc32) and gcc 4.1.0. > > ./configure --help runs the gcc check, thus displaying the following > error : ERROR: "gcc" looks like gcc 4.x > > IMHO this should be changed to avoid running things like this : > ./configure --cc=gcc32 --help I see what you mean now :) It would enough to just move the gcc check in the configure script to after the help processing. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ./configure --help and gcc checks
On Thu, 6 Apr 2006 15:40:53 -0400 "Jim C. Brown" <[EMAIL PROTECTED]> wrote: > having configure check for gcc3, gcc31, gcc32, gcc33, gcc34, etc > before checking for gcc itself might work. > > is it really worth the trouble to check every possible combination? >[...] > > IMHO this should be changed to avoid running things like this : > > ./configure --cc=gcc32 --help How about doing: CC=gcc32 ./configure -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
On Sat, 1 Apr 2006 23:06:07 +0300 Jonas Maebe <[EMAIL PROTECTED]> wrote: > On 01 Apr 2006, at 22:51, Chris Wilson wrote: > > > and they have been an extensive user of software patents, > > And how: >http://www.patent.gov.uk/patent/legal/summaries/2004/o29204.htm > > "The invention in this case involves locating all of the input > registers in one data storage area, and all of the output registers > in another data storage area. Then the simulator only has to switch > the two storage areas around (eg. by exchanging two pointer values) > in order to effectively COPY all of the output registers to the > corresponding input registers of the next stage in a single > operation. The Hearing Officer concluded that this invention did > involve a technical contribution — not simply because it produced a > faster simulator, but because the fundamental construction of the > simulator had been modified." I've got a better idea. In an imaginary 3-stage pipeline, instead of doing: i1[*] -> -> o1[*] i2[*] -> -> o2[*] i3[*] -> -> o3[*] i2[*] = o1[*] i3[*] = o2[*] which the patent optimises to: i1[*] -> -> o1[*] i2[*] -> -> o2[*] i3[*] -> -> o3[*] i2,o1 = o1,i2 i3,o2 = o2,i3 how about this: o2i3[*] -> -> o3[*] o1i2[*] -> -> o2i3[*] i1[*] -> -> o1i2[*] which saves mucking around with pointers completely (requires the stages are implemented sequentially not in pararllel, but since we're talking about a software simulation that's likely to be the case). Doesn't break the patent (well, the summary at least) and is a fraction quicker :) To be honest both optimisations are clearly obvious to anyone sufficiently skilled in the field - maybe not so much to hardware engineers who tend to think in parallel but certainly to software engineers who tend to think in series. > In fact, wouldn't surprise me if Qemu violates this patent. Qemu doesn't simulate the pipeline as such as it emulates each instruction completely before starting the next one. Makes things much simpler - if you don't simulate the pipeline, you don't have to simulate flushing it etc :). The patent is talking about much deeper simulation, probably for use in simulating the core in relation to other components, or for use in accurate timing simulations. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VM Memory limit with kernel-kqemu?
On Sun, 26 Mar 2006 14:48:11 -0500 Andrew Barr <[EMAIL PROTECTED]> wrote: > I'm running a Windows 2000 SP4 guest on a Linux 2.6.16 host with Qemu > CVS and kqemu 1.3.0pre3. I am trying to use -kernel-kqemu. I have > been allocating 256 MB of RAM to my guest (out of 768 MB total) and I > have found that using that amount of memory with -kernel-kqemu causes > Windows 2000 to freeze at the graphical boot up screen (after > 'Starting Windows...') and qemu to take up 95-100% CPU. Reducing the > amount of guest RAM to 160 MB makes that problem go away. I also > tried 192 MB and that did not work. Is there a limit to the amount of > memory that may be used with the -kernel-kqemu option? I found the same when I tried 256M - it works with 384M (with which qemu uses about half of my 1GB) so I didn't look into it further. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kernel-kqemu and linux
Sorry, still fails at the same place. It recognises the APIC:
...
Found and enabled local APIC!
mapped APIC to d000 (fee0)
...
I noticed that before the 'kernel BUG' message I got a warning that
scrolled off the screen; so I halted qemu and captured it piece by
piece:
...
hda: cache flushes not supported
hda:Badness in blk_remove_plug at block/ll_rw_blk.c:1436
xx blk_remove_plug+0x69/0x70
xx ide_do_request+0x3c2/0x3f0
xx do_ide_request+0x24/0x30
xx generic_unplug_device+0x10/0x20
xx block_sync_page+0x3a/0x50
...
xx kernel_thread_helper+0x5/0xc
hda1 hda2 hda3
[ cut here ]
kernel BUG at mm/swap.c:215!
... then as before (I can transcribe the whole trace if you want).
The warning is the following code:
int blk_remove_plug(request_queue_t *q)
{
WARN_ON(!irqs_disabled())
"Badness in" comes from the WARN_ON macro. So it appears that linux
expects the irqs to have been disabled, which they are in the normal
emulation but not in the virtualised kernel mode.
Without -kernel-kqemu I don't get the warning (or the BUG):
...
hda: cache flushes not supported
hda1 hda2 hda3
hdc: ATAPI 4X CD-ROM drive, 512kB Cache
and it boots up & works fine.
Kev.
On Tue, 21 Mar 2006 00:39:15 +0100
Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Try the following patch:
>
> diff -u -w -r1.39 helper2.c
> --- helper2.c 4 Dec 2005 18:46:06 - 1.39
> +++ helper2.c 20 Mar 2006 23:38:51 -
> @@ -110,6 +110,7 @@
> env->pat = 0x0007040600070406ULL;
> env->cpuid_ext_features = 0;
> env->cpuid_features |= CPUID_FXSR | CPUID_MMX | CPUID_SSE |
> CPUID_SSE2
> | CPUID_PAE | CPUID_SEP;
> +env->cpuid_features |= CPUID_APIC; /* TEST */
> env->cpuid_xlevel = 0;
> {
> const char *model_id = "QEMU Virtual CPU version "
> QEMU_VERSION;
>
> If it works then APIC usage will become the default on i386...
>
> Fabrice.
>
> Kevin F. Quinn wrote:
> > Hi.
> >
> > I'm successfully running Windows 2000 guest on qemu (linux host)
> > with kernel-kqemu, and the speed is excellent. However I can't get
> > linux to run as a guest (still linux host); no matter what kernel
> > or kernel config I create, it always BUGs at the same point:
> >
> > hda: hda1 hda2 hda3
> > [ cut here ]
> > kernel BUG at mm/swap.c:215!
> > invalid operand: [#1]
> > Modules linked in:
> > CPU:0
> > EIP:0060:[]Not tainted VLI
> > EFLAGS: 00010256 (2.6.15-gentoo-r1)
> > EIP is at release_pages+0x131/0x140
> > eax: ebx: c12f98e0 ecx: c0458c94 edx: c12f98e0
> > esi: edi: ebp: 0001 esp: d7fc1da8
> > ds: 007b es: 007b ss: 0068
> > Process swapper (pid: 1, threadinfo=d7fc task=d7fe4a10)
> > Stack: c136eca8 d7fc1e30 0040
> > 000e c12fb160
> >c0458bc0 0001 c04f2ac0 c0141bca c04f2ac8 0001
> > d7fc1e28
> >0001 d7fc1e28 0001 0001 c01419b5
> > d7fc1e30 0001
> > Call TRace:
> > [] __pagevec_lru_add_active+0xaa/0xc0
> > [] __pagevec_release+0x25/0x30
> > [] invalidate_mapping_pages+0xf9/0x100
> > [] invalidate_inode_pages+0x1e/0x30
> > [] kill_bdev+0x19/0x40
> > [] add_disk+0x49/0x60
> > ... (during ide probe)
> >
> >
> > If kernel-kqemu works with linux 2.6 for anyone, could you email
> > a .config that works?)
> >
> > Thanks,
> >
> >
> > ------------
> >
> > ___
> > 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
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] kernel-kqemu and linux
Hi. I'm successfully running Windows 2000 guest on qemu (linux host) with kernel-kqemu, and the speed is excellent. However I can't get linux to run as a guest (still linux host); no matter what kernel or kernel config I create, it always BUGs at the same point: hda: hda1 hda2 hda3 [ cut here ] kernel BUG at mm/swap.c:215! invalid operand: [#1] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010256 (2.6.15-gentoo-r1) EIP is at release_pages+0x131/0x140 eax: ebx: c12f98e0 ecx: c0458c94 edx: c12f98e0 esi: edi: ebp: 0001 esp: d7fc1da8 ds: 007b es: 007b ss: 0068 Process swapper (pid: 1, threadinfo=d7fc task=d7fe4a10) Stack: c136eca8 d7fc1e30 0040 000e c12fb160 c0458bc0 0001 c04f2ac0 c0141bca c04f2ac8 0001 d7fc1e28 0001 d7fc1e28 0001 0001 c01419b5 d7fc1e30 0001 Call TRace: [] __pagevec_lru_add_active+0xaa/0xc0 [] __pagevec_release+0x25/0x30 [] invalidate_mapping_pages+0xf9/0x100 [] invalidate_inode_pages+0x1e/0x30 [] kill_bdev+0x19/0x40 [] add_disk+0x49/0x60 ... (during ide probe) If kernel-kqemu works with linux 2.6 for anyone, could you email a .config that works?) Thanks, -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu 0.7.0 does not compile with binutils 2.16
On 10/6/2005 19:54:53, Gioele Barabucci ([EMAIL PROTECTED]) wrote: > I tried to compile qemu 0.7.0 on my gentoo-ppc box. ... > I used gcc-3.4.3, binutils 2.16 and gentoo's glibc 2.3.4.20041102-r1 with > > NPTL. Posting a bug to Gentoo's bugzilla would be a good idea (http://bugs.gentoo.org). Since binutils-2.16 is ~ppc (i.e. being tested), you could try the latest stable version of binutils (2.15.90.0.3-r5). That would demonstrate whether it's a binutils issue or not. Kev. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] 1) mouse and xinerama 2) ntvdm 3) win98se protection error
Hi. I've finally successfully installed Windows 2000 and SP4 from scratch with kqemu under linux. I applied the IDE patch recently mentioned and that got around the disk-full problem. This is on latest CVS. I have an observation, and a couple of problems hopefully someone can help me with. 1) I've been using qemu with a dual-head setup, with xinerama. I had trouble with the mouse, which behaved strangely on the second head. Discovered it worked ok on the primary head. Traced mouse data back through qemu, then SDL and worked out that for some reason the mouse position deltas aren't being served up properly to SDL (and hence to qemu). A rummage around yielded an idea which did indeed sort the problem out. Doing: export SDL_VIDEO_X11_DGAMOUSE=0 before running qemu did the trick. It seems DGA mouse behaviour isn't entirely sane yet with xinerama. I don't think there's anything qemu can do; the data coming through SDL was bizarre. Moving on, I have a couple of problems, but I can't think of a neat way to isolate and debug them. If anyone has some tricks up their sleeves for this kind of thing, it'd be much appreciated. 2) ntvdm crashes, no matter what app I try to launch with it (ntvdm is the compatibility layer in NT for legacy apps). The crash report on Windows 2000 (SP4) is as follows: X#=0D, CS=00C7, IP=3016 The NTVDM CPU has encountered an unhandled exception. Choose 'Close' to terminate the application. Choosing 'ignore' each time leads to more errors, with IP=00E9, 21E3 and 0646 before the applicaion is forcibly terminated by Windows. 3) Windows 98 SE installation isn't successful. It gets all the way through the setup to rebooting Windows proper (cloudburst Windows 98 background) however it crashes with "Windows protection error. You need to restart your computer." before loading the desktop. Stepping through Windows the initialisation shows it happens after the VXDs etc. have loaded (last one to load is psmouse.vxd). Cheers, Kev. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
