[Qemu-devel] changing simulated CPU frequency

[Jonathan ILIAS]

Hi,

I'm trying to bypass a bug in an old version of RTAI, which does not 
work correctly with processors that have a clock greater than 2^31 Hz 
(frequency stored in a signed 32 bits integer).


As I cannot use a earlier version and fixing this bug may not be 
trivial, I'm looking for a way to reduce the simulated Qemu CPU clock.


I tried to change linux-user/main.c to force the use of the following 
version of cpu_get_real_ticks function :

static uint64_t emu_time;

int64_t cpu_get_real_ticks(void)
{
return emu_time++;
}

But Linux in Qemu continues to detect a CPU at 3,4 GHz.

Do you know if there is a way to modify Qemu source to have a lower CPU 
clock ?


I hope I've described my problem clearly...
--
Jonathan ILIAS, assistant pédagogique
http://www.eseo.fr/~jilias/
ESEO
4, rue Merlet de la Boulaye
BP 30926 - 49009 ANGERS cedex 01 - FRANCE
tél : 02 41 86 67 57


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

[Qemu-devel] [patch] Misleading -net documentation

[Paul Brook]

The qemu documentation implies that "-net user" is the default. It's actually 
"-net user -net nic". The patch below clarifies the documentation. I've also 
moved the description of the default to -net none as that seems a more 
logical place for it.

Paul

Index: qemu-doc.texi
===
RCS file: /sources/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.78
diff -u -p -r1.78 qemu-doc.texi
--- qemu-doc.texi   19 Dec 2005 22:12:34 -  1.78
+++ qemu-doc.texi   31 Jan 2006 16:09:02 -
@@ -260,8 +260,7 @@ target. Optionally, the MAC address can 
 
 @item -net user[,vlan=n]
 Use the user mode network stack which requires no administrator
-priviledge to run. This is the default if no @option{-net} option is
-specified.
+priviledge to run.
 
 @item -net tap[,vlan=n][,fd=h][,ifname=name][,script=file]
 Connect the host TAP network interface @var{name} to VLAN @var{n} and
@@ -334,8 +333,8 @@ qemu linux.img -net nic,macaddr=52:54:00
 
 @item -net none
 Indicate that no network devices should be configured. It is used to
-override the default configuration which is activated if no
[EMAIL PROTECTED] options are provided.
+override the default configuration (@option{-net nic -net user}) which
+is activated if no @option{-net} options are provided.
 
 @item -tftp prefix
 When using the user mode network stack, activate a built-in TFTP


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

[Qemu-devel] Re: RE: qemu debian etch

[Alex]

This works for me:
eject cdrom
switch back to windows and try to access the cdrom. Now windows will 
complain that there is no media in the drive.
switch to qemu console
change cdrom /whatever
go back to windows and try again. This time Window should see the correct 
media.

-- 
Alex.

"De Leeuw Guy" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Thanks Juergen,

Finnally I Install first the win xp home, and after upgrade to the xp
pro and install the office 2003
I use windows under qemu just to maintain applications that are builded
with VS2002 and to help my users.
I don't know if this problem is a bug but I loose about 4 days with this
problem :)
I install now VS2002, and same problem appear except that I can going to
the windows explorer and start a refresh
of the cdrom (D:) but a lot of try is needed :(

No, the cdrom change does not crash my system, the only crash that I
know come when the resolution of the screen is not correct and in this
case qemu crash when I try to switch to full screen.

Except this problem, qemu is a incredible product, I use for differents
tests in the future, thanks a lot to the devellopers

(sorry for my poor english)
Best regards,
Guy

Juergen Pfennig a écrit :

>Hi,
>win2003 (and as you say win XP) does not detect the media change.
>As a consequence the cached data gets not flushed (inside win).
>The "change cd /dev/cdrom" sometimes caused a qemu crash for me.
>
>So you probably found a bug. If nobody else solves the problem it
>will stay on my list as a low priority problem.
>
>TIP: mount your cd rom (images) via loopback and export them via
>smb (allow samba to follow symlinks and use simple ln -s commands
>to point to your mount points). Evidently you need a working win
>to do this. For (ms) win apps you don't need the iso images, just
>do what ms calls an "administrative install" to your smb server.
>Administrative installs are compatible with wine (if you like
>that) and can be shared from multiple clients (e.g. also saving
>disk space).
>
>TIP: to install windows (from MSDN cds) ... step (1) install a
>minimal system from a bootable cd. (2) make sure that the vm
>can access your smb server. (3) create a "slip stream" image of
>the win and SP you want to install on your smb server. (4) making
>an MSDN cd bootable will often be a problem - don't try it if you
>don't know better. (5) From your running vm re-install the (slip
>stream) win that you want via smb. (6) You should not go the other
>way round (installing a SP on the VM), which takes longer and
>wastes disk space. (7) start your VM with -vga to activate windows
>(8) configure your WSUS or other update mechanism and let it
>install the official patches from MS.
>
>TIP: don't panic. At least for win2003 the disk io can degenerate
>completely so that a login can take 75s. Sometimes it helps to
>run a disk-defrag (but stop it after a minute or so, otherwise
>it fills your virtual disk with crap). Here some figures for a
>P4 2.4 GHz and 1GByte memory (qemu -m 300 with kqemu used):
>
>(1) win2003 takes about 60s to boot (a factor of 2-3)
>(2) a login takes 6s (a factor of 3)
>(3) old COM based apps like Word have a "slow down" factor of 3
>(4) .NET apps seem to run a little faster (VS 2003 is usable)
>(5) IO is a problem. Don't expect more than 5 MByte/s
>
>Win XP/2003 are a least usable and the cd rom bug is not so dramatic.
>It's also not a Debian problem.
>Yours Jürgen
>
>
>___
>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

Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32

[André Braga]

Wow, thanks! I almost gave up on seeing someone port over this patch :)


--
"I decry the current tendency to seek patents on algorithms. There are
better ways to earn a living than to prevent other people from making
use of one's contributions to computer science."
Donald Knuth



On 1/31/06, Kazu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I updated a patch to support tap for win32.
>
> Here is patches and a binary.
> These patches are applied by patch -p1 option. Tap patch can be applied on
> top of VLAN patch. VLAN patch is updated.
> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060111-vlan.patch
> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060111-tap.patch
>
> http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060111-vlan-tap.zip
>
> Options are:
> -net nic -net tap,ifname=my-tap
> Use ifname to set a name of Tap.
> my-tap is the name of  my TAP-Win32 Adapter.
>
> Don't use the same network address as a physical network.
> For example, if the physical network is 192.168.0.x, use different network
> 192.168.10.y for TAP-Win32 Adapter.
>
> For more information,
> http://www.h7.dion.ne.jp/~qemu-win/TapWin32-en.html#vlan
>
> Regards,
> Kazu


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

[Qemu-devel] Qemu on Intel Macs

[Jeshua Lacock]

Greetings,

I am trying to build Qemu on a Intel Mac and after a little bit of work 
I got it building. It is having trouble with the "mach-o/ppc/reloc.h" 
file. Someone from Apple says:


"Mac OS X's ABI for Intel uses 'generic' relocation entry types, which
  are defined in .  You can see this by running
  'otool -arch i386 -rv /path/to/binary', where the binary is 
universal or

Intel-only."

The generic entry types are:

enum reloc_type_generic
{
GENERIC_RELOC_VANILLA,  /* generic relocation as discribed 
above */
GENERIC_RELOC_PAIR, /* Only follows a GENRIC_RELOC_SECTDIFF 
*/
GENERIC_RELOC_SECTDIFF,
GENERIC_RELOC_PB_LA_PTR,/* prebound lazy pointer */
GENERIC_RELOC_LOCAL_SECTDIFF
};


I don't see anything similar to "PPC_RELOC_BR24" . I realize that those 
are specific to the PPC and "GENERIC_RELOC_VANILLA" will have to be 
used, although I have no idea how to implement them. The scheme should 
be pretty similar to the PPC Mach-O port.


The other (most likely related) error is:

struct relocation_info' has no member named 'r_offset'

This is above my understaning, I would be very grateful to pay you for 
your help. If you are interested I can create an account for you to log 
into. Any help is appreciated. I would be happy to provide the changes 
to the Qemu project.


Anyone out there feel qualified to help me get this going? Its a bit 
beyond my ability at this time and I would be happy to compensate for 
time.



Thanks,

Jeshua Lacock ___
Programmer/OwnerPhone:  877.240.1364
http://OpenOSX.com  Fax:415.462.6211
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_



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

Re: [Qemu-devel] Qemu on Intel Macs

[Gwenole Beauchesne]

Hi,

Anyone out there feel qualified to help me get this going? Its a bit  
beyond my ability at this time and I would be happy to compensate for  
time.


I still haven't had the time to merge back to QEMU the following change:


Probably on next weekend...


Jeshua Lacock ___
Programmer/OwnerPhone:  877.240.1364
http://OpenOSX.com  Fax:415.462.6211
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_


Ah, you claimed that Wintel^WBochs ran at near native performance, how  
would you communicate on QEMU then?




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