Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

[Pierre d'Herbemont]

On 16 mai 05, at 09:54, Benjamin Herrenschmidt wrote:

OK, I did put this in my working repository and I'll submit this to
Fabrice.
Please try to do this change to check if other bits need to be relax 
or
not:

Index: target-ppc/translate.c
===
RCS file: /cvsroot/qemu/qemu/target-ppc/translate.c,v
retrieving revision 1.31
diff -u -r1.31 translate.c
--- target-ppc/translate.c  12 May 2005 18:46:11 -  1.31
+++ target-ppc/translate.c  14 May 2005 17:14:35 -
@@ -2123,7 +2123,7 @@
 }
 /* mtcrf */
-GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00100801, PPC_MISC)
+GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x0801, PPC_MISC)
 {
 gen_op_load_gpr_T0(rS(ctx->opcode));
 gen_op_store_cr(CRM(ctx->opcode));
I've tested it: it works fine as expected.
And maybe someone should fill an Apple bug report to tell them their 
as
is buggy ;-)
It is definitely a bug in Apple assembler I would say, so I suggest you
add a comment in the above patch in order to avoid somebody later on
"fixing" your mask :)
I thought it was, but it seems to be not so buggy ;)
I have had a look at the Apple's as source code of Darwin 8.0 (10.4) 
[1] and I have found an interesting comment :
	/*
	 * If this is the mtcrf opcode (0x7c000120) and val is not zero and
	 * has exactly one bit set then use the new form of the mtcrf
	 * opcode.  This has bit 0x0010 set and the FXM field is a bit
	 * mask. Else use the old form without bit 0x0010 set.
  */

I don't know what they are refering to, but that may have been 
introduced by the PowerPC 970 or an other new PPC, since it was not 
present on the Mac OS X 10.2's as [2].

Pierre.
 [1] http://darwinsource.opendarwin.org/10.4/cctools-576/as/ppc.c
 [2] http://darwinsource.opendarwin.org/10.2/cctools-435/as/ppc.c

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

Re: [Qemu-devel] [patch] gcc4 host support

[Paul Brook]

On Monday 16 May 2005 10:41, David Woodhouse wrote:
> On Wed, 2005-05-11 at 22:04 +0100, Paul Brook wrote:
> > My solution is to search the function for the "ret" instruction and
> > replace them with a jmp to the next block of code. On RISC targets this
> > would be easy.
>
> About this easy, in fact...
>...
> +
> + if (get32((uint32_t *)p) == 0x4e800020) {
> + blr_addr = p;
> + copy_size = p_end - p_start;
> + break;
> + }

You probably want to scan the whole function to check there aren't multiple 
blr instructions, and throw an error if there are.

Other than that it looks ok to me.

Paul


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

Re: [Qemu-devel] Re: request : qemu-smp as target

[Paul Brook]

> What inter processor synchronization issues are there?  Could you take
> this a step further and use processes on different machines for each
> processor? (There are many shared memory implementations to choose
> from.)  Are there so many resources shared  
> between the CPUs to make this a ridiculous proposition?

Baically most SMP/shared memory systems assume very low latency communication 
between CPUs and memory. For example on opteron systems remote memory latency 
is of the order of 200 cpu cycles. Typical ethernet latency is several 
million cycles.

To do single-system image over a high latency interconnect (eg. ethernet) you 
need OS and preferably use application support to avoid high-contention 
memory areas. Simulating a SMP system over multiple separate nodes is 
theoretically possible, but performance would probaby be abysmal.

The only solution I can imagine being even vaguely worthwhile is a running 
user-mode qemu on top of a native openmozix system.

> I have ignorantly implemented an SH2 emulator, 

Cool. Any chance you're going to make these changes publicly available?

Paul


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

Re: [Qemu-devel] Re: request : qemu-smp as target

[Joe Batt]

On Tue, 2005-05-17 at 21:21 +0100, Paul Brook wrote:
> > What inter processor synchronization issues are there?  Could you take
> > this a step further and use processes on different machines for each
> > processor? (There are many shared memory implementations to choose
> > from.)  Are there so many resources shared  
> > between the CPUs to make this a ridiculous proposition?
> 
> Baically most SMP/shared memory systems assume very low latency communication 
> between CPUs and memory. For example on opteron systems remote memory latency 
> is of the order of 200 cpu cycles. Typical ethernet latency is several 
> million cycles.

But how often will the virtual CPUs need the same page and is there any
other shared resource other than memory?  I don't know how independent
each CPU is.  Though in side discussions, everyone agrees with you, I
haven't seen numbers to convince my gut.  If page only needs to be
faulted back and forth every couple million cycles, then it might work.

> The only solution I can imagine being even vaguely worthwhile is a running 
> user-mode qemu on top of a native openmozix system.
OpenMosix is very interesting, but is a pain to setup.  How about this:

  ssh -f host1 qemu -cpu-server $KEY
  ssh -f host2 qemu -cpu-server $KEY
  qemu -cpu-client host1:$KEY \
   -cpu-client host2:$KEY \
   -hda server.image

> > I have ignorantly implemented an SH2 emulator, 
> 
> Cool. Any chance you're going to make these changes publicly available?
It was a Java implementation for a customer.  Not my property and not
integrated with any free software.

> Paul
-- 
Joe Batt <[EMAIL PROTECTED]>



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

Re: [Qemu-devel] Re: request : qemu-smp as target

[Paul Brook]

On Tuesday 17 May 2005 21:41, Joe Batt wrote:
> On Tue, 2005-05-17 at 21:21 +0100, Paul Brook wrote:
> > > What inter processor synchronization issues are there?  Could you take
> > > this a step further and use processes on different machines for each
> > > processor? (There are many shared memory implementations to choose
> > > from.)  Are there so many resources shared
> > > between the CPUs to make this a ridiculous proposition?
> >
> > Baically most SMP/shared memory systems assume very low latency
> > communication between CPUs and memory. For example on opteron systems
> > remote memory latency is of the order of 200 cpu cycles. Typical ethernet
> > latency is several million cycles.
>
> But how often will the virtual CPUs need the same page and is there any
> other shared resource other than memory?  I don't know how independent
> each CPU is.  Though in side discussions, everyone agrees with you, I
> haven't seen numbers to convince my gut.  If page only needs to be
> faulted back and forth every couple million cycles, then it might work.

Everything but the cpu (and possibly the APIC) is shared. This is why big SMP 
systems cost orders of magnitude more than a similar size cluster.

One of the biggest sources of contention is probably going to be kernel 
spinlocks. Every time the kernel needs to acquire a spinlock that page will 
need to be faulted across to that CPU.

> > Cool. Any chance you're going to make these changes publicly available?
>
> It was a Java implementation for a customer.  Not my property and not
> integrated with any free software.

Oh! I thought you'd implemented SH support for qemu :-)

Paul


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

Re: [Qemu-devel] Cursor problems.

[Juergen Lock]

In article <[EMAIL PROTECTED]> you write:
>When running qemu on my HP laptop, I cannot seem to use the cursor in the
>guest os.  The guest OS can be any os, windows reactos linux, etc.  The
>host OS is fedora core 3. Basically, the cursor shows up as normal on the
>screen, but when I click in to let qemu grab the focus, the cursor jumps
>to the bottom right as soon as any motion happens.  The buttons all still
>function properly, I know this because in reactos the curusor is
>positioned just above the time.
>[...]

I cannot help you other than by saying this is the exact same
phenomenon i have on linux since switching to a 2.4 kernel (because
of this promise sata card i got, apparently there's no 2.6 driver
for that for some reason.)

 Same box runs qemu just fine with working cursor using FreeBSD as
host os...

Juergen


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

Re: [Qemu-devel] [PATCH] Mingw32 cross compile fixes from 64-bit host

[Paul Brook]

On Tuesday 17 May 2005 10:01, Gwenole Beauchesne wrote:
> I had the following in my tree for a while but forgot to submit it. This 
> fixes cross compilation to mingw32 from 64-bit host (x86_64). Actually, 
> this makes dyngen aware of correct COFF format.
>...
> +  char

It doesn't really make any difference, but wouldn't it be more consistent to 
use [u]int8_t instead of char?

Paul


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

[Qemu-devel] Dynamic bridging

[Ben Taylor]

I was trying to get the bridging working (with the help
of pbrook and nox- on the irc #qemu channel) and
eventually got it working under Sun JDS/3 (Suse 9.1)
after adding the bridge-util's rpm.

After some experimentation, I found that once I setup
the bridge on my primary interface, (eth0) and I used
the qemu-ifup script, the tunnels would automatcially
attach to the bridge, and when qemu shuts down, they
automatically go away.

primary-ifup
Code:

#!/bin/sh
/sbin/brctl addbr br0
/sbin/ifconfig eth0 0.0.0.0 promisc up
/sbin/ifconfig eth0 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 up
/sbin/brctl stp br0 off
/sbin/brctl setfd br0 1
/sbin/brctl sethello br0 1
/sbin/brctl addif br0 eth0
/sbin/route add default gw 192.168.1.1

Then I ran qemu with a "-n ./qemu-ifup" (not the default /etc/qemu-ifup script) 
and the Damn Small Linux connected to the tun0 interface and got a DHCP address 
from the LAN's dhcp server.  This was pretty exciting, given that I asked
a bunch of non-qemu networking questions trying to 
understand the tunnels and bridges.

qemu-ifup

#!/bin/sh
/sbin/ifconfig $1 0.0.0.0 promisc up
/sbin/brctl addif br0 $1 

Thanks to pbrook and nox- for helping my find this
gem. Now if I could only get bridging to work on
Solaris like this. 




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

Re: [Qemu-devel] Cursor problems.

[Jason]

On Wed, 2005-05-18 at 01:42 +0200, Juergen Lock wrote:
> In article <[EMAIL PROTECTED]> you write:
> >When running qemu on my HP laptop, I cannot seem to use the cursor in the
> >guest os.  The guest OS can be any os, windows reactos linux, etc.  The
> >host OS is fedora core 3. Basically, the cursor shows up as normal on the
> >screen, but when I click in to let qemu grab the focus, the cursor jumps
> >to the bottom right as soon as any motion happens.  The buttons all still
> >function properly, I know this because in reactos the curusor is
> >positioned just above the time.
> >[...]
> 
> I cannot help you other than by saying this is the exact same
> phenomenon i have on linux since switching to a 2.4 kernel (because
> of this promise sata card i got, apparently there's no 2.6 driver
> for that for some reason.)
> 
>  Same box runs qemu just fine with working cursor using FreeBSD as
> host os...
> 
>   Juergen

Well, I did a bit more investigation and put a printf into the function
sdl_send_mouse_event in sdl.c to see what was being sent from the Host
OS to the guest OS.  It would seem that the SDL_GetRelativeMouseState
function is reporting odd values for dx and dy on my laptop but not on
my other machine.  Both of them are running the same OS for the host OS,
Fedora Core 3.  One is a normal computer with a PS/2 mouse and the other
is a  laptop with a Synaptics Touch pad and a USB attached mouse.  The
laptop actually has both devices going through GPM which is set as a
repeater in PS/2 mode.  So the data being sent to xorg should be PS/2
data.  Thus the data that SDL is getting should also be PS/2 data, but
from the look of it, it isn't.  From the look of it, it should be
reporting small changes either a small positive value or a small
negative value.

On my laptop it actually jumps all over the place but it's usually
large positive values.  I have more investigation to do but it might be
something like a buffer not getting written write or getting written
with junk data.  

Juergen, what type of pointing device do you have?


-- 
Jason <[EMAIL PROTECTED]>



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

Re: [Qemu-devel] Cursor problems.

[Jason Gress]

Jason,

I had this problem once.  It turned out to be an SDL problem.  Try 
upgrading/downgrading SDL packages.  I had the problem on Gentoo.

Jason



On Monday 16 May 2005 02:27 pm, Jason wrote:
> When running qemu on my HP laptop, I cannot seem to use the cursor in the
> guest os.  The guest OS can be any os, windows reactos linux, etc.  The
> host OS is fedora core 3. Basically, the cursor shows up as normal on the
> screen, but when I click in to let qemu grab the focus, the cursor jumps
> to the bottom right as soon as any motion happens.  The buttons all still
> function properly, I know this because in reactos the curusor is
> positioned just above the time.
>
> I've posted this to the forums but no one has responded.  I am quite
> perlexed at this because this works fine on my other system which is also
> fedora core 3.  The laptop is using a USB attached mouse or a Synaptics
> touch pad.  Neither of which seem to work.  One question I Have is does
> qemu use the X windows curor or is it connecting directly to something
> like /dev/input/mice?  Because if it's using the X windows pointer, it
> should be getting a generic PS/2 mouse.
>
>
> ___
> 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] slirp 64-bit fixes

[John Hogerhuis]

Curious if the patches to slirp are being forwarded upstream to the
current slirp maintainer.

I wonder if he even knows QEMU uses it?

http://lists.sourceforge.net/lists/listinfo/slirp-devel

-- John.


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

[Qemu-devel] weird errors on x86_64 target (i686 host)

[VMiklos]

hi
i just tried out the new x86_64 target (version 0.7.0), wanted to 
install a gentoo system.

i downloaded the install livecd:
http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/releases/amd64/2005.0/installcd/install-amd64-minimal-2005.0.iso
here are the first problem. most commands works fine, but for example if 
you try to 'ssh someserver', it'll fail

the full installation works fine, you can boot the target system, but 
major upgrades (gcc, glibc compilations) fails with internal compiler error

yes, i checked that if i do the same on a real x86_64 host, it compiles 
without any problem

if you need any additional info pls let me know
udv / greetings,
VMiklos
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

[Herbert Poetzl]

On Tue, May 17, 2005 at 11:10:52PM +0200, J. Mayer wrote:
> 
> I will implement the new form, so it most crf transfers can be
> optimized.
> 
> The latest PowerPC specification is to be found here:
> 
> 
> 

you sure about that?

best,
Herbert

> -- 
> J. Mayer <[EMAIL PROTECTED]>
> Never organized
> 
> 
> 
> ___
> 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] gcc4 host support

[Herbert Poetzl]

On Tue, May 17, 2005 at 09:46:30PM +0100, Paul Brook wrote:
> On Monday 16 May 2005 10:41, David Woodhouse wrote:
> > On Wed, 2005-05-11 at 22:04 +0100, Paul Brook wrote:
> > > My solution is to search the function for the "ret" instruction and
> > > replace them with a jmp to the next block of code. On RISC targets this
> > > would be easy.
> >
> > About this easy, in fact...
> >...
> > +
> > +   if (get32((uint32_t *)p) == 0x4e800020) {
> > +   blr_addr = p;
> > +   copy_size = p_end - p_start;
> > +   break;
> > +   }
> 
> You probably want to scan the whole function to check there aren't multiple 
> blr instructions, and throw an error if there are.

hmm, wouldn't it be much easier to separate compiling
from assembling, and do the 'changes' on the assembler
files instead?

just an idea ...

best,
Herbert

> Other than that it looks ok to me.
> 
> Paul
> 
> 
> ___
> 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] target-ppc mtcrf instruction not recognized

[J. Mayer]

On Wed, 2005-05-18 at 11:06 +0200, Herbert Poetzl wrote:
> On Tue, May 17, 2005 at 11:10:52PM +0200, J. Mayer wrote:
> > 
> > I will implement the new form, so it most crf transfers can be
> > optimized.
> > 
> > The latest PowerPC specification is to be found here:
[...]

> you sure about that?

No, sorry: Here are the right links:




-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized



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

qemu-devel@nongnu.org

[info]

$B"v!&!yL5NAEPO?%-%c%s%Z!<%sCf!y!&"v(B



$B!!$d$C$Q$j=P0)$&$J$i$46a=j$G2q$($kAjhttp://www.jumpb2.net/?imasugu



$B!!%3%3$K%"%I8x3+$GBT$C$F$$$k$46a=jL<$,$$$C$Q$$(B(o^$B"O(B^o)[EMAIL 
PROTECTED]&!&(B

$BEPO?8e(B5$BJ,0JFb$K$46a=j$G2q$([EMAIL PROTECTED]>R2pCW$7$^$9!#(B

$B$^$:$O$*;n$7L5NAEPO?$+$i(B

$B!!"-"-"-"-"-"-(B

$B(Bhttp://www.jumpb2.net/?imasugu

$B(B

$B!!(B $B%U%j!<%a!<%kBP1~$G$9!*(B



















$B5qH](B

[EMAIL PROTECTED]



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

Re: [Qemu-devel] Re: request : qemu-smp as target

[Mark Williamson]

> The only solution I can imagine being even vaguely worthwhile is a running
> user-mode qemu on top of a native openmozix system.

Probably if you want to run a distributed SMP-style sytem using QEmu, the most 
effective approach is going to be running OpenMosix *in* QEmu, on multiple 
hosts.

Sadly, this is much less transparent than QEmu / the host doing the 
distribution for you :-( but I can probably think of situations where it 
might be useful... (how about running a virtual OM cluster on a bunch of 
mostly-idle Windows boxes?)

Cheers,
Mark

>
> > I have ignorantly implemented an SH2 emulator,
>
> Cool. Any chance you're going to make these changes publicly available?
>
> Paul
>
>
> ___
> 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] Re: request : qemu-smp as target

[Mark Williamson]

> But how often will the virtual CPUs need the same page and is there any
> other shared resource other than memory?  I don't know how independent
> each CPU is.  Though in side discussions, everyone agrees with you, I
> haven't seen numbers to convince my gut.  If page only needs to be
> faulted back and forth every couple million cycles, then it might work.

In the applications, probably very independent.  In the kernel, highly 
dependent: different CPUs may access shared data structures *and* protect 
them with spinlocks.  As Paul said in a separate mail, spinlocks are going to 
be way more expensive in this sort of distributed environment.

All that being said, a company called "Virtual Iron" has got a 
fully-virtualising solution that presents an SMP to the guest OS but actually 
distributes computation across a cluster.  I have yet to see the product 
itself - no idea when it'll be released.  It also sounds *really* difficult 
to make go fast but at least suggests this sort of thing can perform 
reasonably for some workloads.

Cheers,
Mark

> > The only solution I can imagine being even vaguely worthwhile is a
> > running user-mode qemu on top of a native openmozix system.
>
> OpenMosix is very interesting, but is a pain to setup.  How about this:
>
>   ssh -f host1 qemu -cpu-server $KEY
>   ssh -f host2 qemu -cpu-server $KEY
>   qemu -cpu-client host1:$KEY \
>-cpu-client host2:$KEY \
>-hda server.image
>
> > > I have ignorantly implemented an SH2 emulator,
> >
> > Cool. Any chance you're going to make these changes publicly available?
>
> It was a Java implementation for a customer.  Not my property and not
> integrated with any free software.
>
> > Paul


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

Re: [Qemu-devel] Dynamic bridging

[Paul Brook]

On Wednesday 18 May 2005 01:52, Ben Taylor wrote:
> I was trying to get the bridging working (with the help
> of pbrook and nox- on the irc #qemu channel) and
> eventually got it working under Sun JDS/3 (Suse 9.1)
> after adding the bridge-util's rpm.
>
> After some experimentation, I found that once I setup
> the bridge on my primary interface, (eth0) and I used
> the qemu-ifup script, the tunnels would automatcially
> attach to the bridge, and when qemu shuts down, they
> automatically go away.
>
> primary-ifup
> Code:
>
> #!/bin/sh
> /sbin/brctl addbr br0
> /sbin/ifconfig eth0 0.0.0.0 promisc up
> /sbin/ifconfig eth0 192.168.1.2 netmask 255.255.255.0 broadcast \
>   192.168.1.255 up

This line should be changes to ifconfig br0 , and moved to the end of the 
script. 

You shouldn't give the component devices an IP address, just the br interface. 
Using the component interfaces directly is liable to lead to weird problems 
on the host.

Also, if youdon't want to use a static IP, you can just run dhclient
(or equivalent) on the br0 interface as normal.

My setup looks someting like:

/sbin/brctl addbr br0
/sbin/ifconfig eth0 0.0.0.0 up
/sbin/brctl addif br0 eth0
dhclient br0

Paul


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

qemu-devel@nongnu.org

[info]

$B"v!&!yL5NAEPO?%-%c%s%Z!<%sCf!y!&"v(B



$B!!$d$C$Q$j=P0)$&$J$i$46a=j$G2q$($kAjhttp://www.jumpb2.net/?imasugu



$B!!%3%3$K%"%I8x3+$GBT$C$F$$$k$46a=jL<$,$$$C$Q$$(B(o^$B"O(B^o)[EMAIL 
PROTECTED]&!&(B

$BEPO?8e(B5$BJ,0JFb$K$46a=j$G2q$([EMAIL PROTECTED]>R2pCW$7$^$9!#(B

$B$^$:$O$*;n$7L5NAEPO?$+$i(B

$B!!"-"-"-"-"-"-(B

$B(Bhttp://www.jumpb2.net/?imasugu

$B(B

$B!!(B $B%U%j!<%a!<%kBP1~$G$9!*(B



















$B5qH](B

[EMAIL PROTECTED]



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

Re: Re: [Qemu-devel] Dynamic bridging

[Ben Taylor]

Paul Brook <[EMAIL PROTECTED]> wrote:
> 
> On Wednesday 18 May 2005 01:52, Ben Taylor wrote:
> > I was trying to get the bridging working (with the help
> > of pbrook and nox- on the irc #qemu channel) and
> > eventually got it working under Sun JDS/3 (Suse 9.1)
> > after adding the bridge-util's rpm.
> >
> > After some experimentation, I found that once I setup
> > the bridge on my primary interface, (eth0) and I used
> > the qemu-ifup script, the tunnels would automatcially
> > attach to the bridge, and when qemu shuts down, they
> > automatically go away.
> >
> > primary-ifup
> > Code:
> >
> > #!/bin/sh
> > /sbin/brctl addbr br0
> > /sbin/ifconfig eth0 0.0.0.0 promisc up
> > /sbin/ifconfig eth0 192.168.1.2 netmask 255.255.255.0 broadcast \
> >   192.168.1.255 up
> 
> This line should be changes to ifconfig br0 , and moved to the end of the 
> script. 

Darn. I think I transcribed it wrong when I cleansed
the addreses.  Thanks for the catch.

> 
> You shouldn't give the component devices an IP address, just the br 
> interface. 
> Using the component interfaces directly is liable to lead to weird problems 
> on the host.

Yes.  It was just a typo.

 
> Also, if youdon't want to use a static IP, you can just run dhclient
> (or equivalent) on the br0 interface as normal.
> 
> My setup looks someting like:
> 
> /sbin/brctl addbr br0
> /sbin/ifconfig eth0 0.0.0.0 up
> /sbin/brctl addif br0 eth0
> dhclient br0

Are the other brctl commands I had in there not required? I was just working 
off the how-to in the qemu user forums as a template, so this was the first 
time I've worked with bridging.

Again, thanks for all the help.  Now having a bridge interface doesn't seem so 
bad since the tunnel can easily add itself and goes away automagically when 
qemu is done.

Ben



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

Re: [Qemu-devel] Cursor problems.

[Jason]

I did some quick looking around on SDL's site and came aross a FAQ about
DGA mouse support,
http://www.libsdl.org/faq.php?action=listentries&category=3#28
On a whim, I decided to give this a shot.  I ran

# export SDL_VIDEO_X11_DGAMOUSE=0

before running qemu and it worked like a charm.  I'm not quite sure what
DGA Mouse Support is, but it would appear that disabling it fixes my
problems with the mouse acting funny.   I just thought someone might like
to know.  I have a thread on the forms that I'll post this to as well. 
Perhaps it'll help someone.

Jason

> Jason,
>
>   I had this problem once.  It turned out to be an SDL problem.  Try
> upgrading/downgrading SDL packages.  I had the problem on Gentoo.
>
>   Jason
>
>
>
> On Monday 16 May 2005 02:27 pm, Jason wrote:
>> When running qemu on my HP laptop, I cannot seem to use the cursor in
>> the
>> guest os.  The guest OS can be any os, windows reactos linux, etc.  The
>> host OS is fedora core 3. Basically, the cursor shows up as normal on
>> the
>> screen, but when I click in to let qemu grab the focus, the cursor jumps
>> to the bottom right as soon as any motion happens.  The buttons all
>> still
>> function properly, I know this because in reactos the curusor is
>> positioned just above the time.
>>
>> I've posted this to the forums but no one has responded.  I am quite
>> perlexed at this because this works fine on my other system which is
>> also
>> fedora core 3.  The laptop is using a USB attached mouse or a Synaptics
>> touch pad.  Neither of which seem to work.  One question I Have is does
>> qemu use the X windows curor or is it connecting directly to something
>> like /dev/input/mice?  Because if it's using the X windows pointer, it
>> should be getting a generic PS/2 mouse.
>>
>>
>> ___
>> 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

Re: [Qemu-devel] [patch] gcc4 host support

[David Woodhouse]

On Wed, 2005-05-18 at 17:02 +0100, Paul Brook wrote:
> For x86 maybe. For ppc it's easier to just scan the binary code.
> You'd have to write an assembly code parser.

It wouldn't have to know much. I suspect you could do it in awk without
much trouble.

-- 
dwmw2



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

Re: [Qemu-devel] [patch] gcc4 host support

[Paul Brook]

On Wednesday 18 May 2005 11:06, Herbert Poetzl wrote:
> On Tue, May 17, 2005 at 09:46:30PM +0100, Paul Brook wrote:
> > On Monday 16 May 2005 10:41, David Woodhouse wrote:
> > > On Wed, 2005-05-11 at 22:04 +0100, Paul Brook wrote:
> > > > My solution is to search the function for the "ret" instruction and
> > > > replace them with a jmp to the next block of code. On RISC targets
> > > > this would be easy.
> > >
> > > About this easy, in fact...
> > >...
> > > +
> > > + if (get32((uint32_t *)p) == 0x4e800020) {
> > > + blr_addr = p;
> > > + copy_size = p_end - p_start;
> > > + break;
> > > + }
> >
> > You probably want to scan the whole function to check there aren't
> > multiple blr instructions, and throw an error if there are.
>
> hmm, wouldn't it be much easier to separate compiling
> from assembling, and do the 'changes' on the assembler
> files instead?

For x86 maybe. For ppc it's easier to just scan the binary code.
You'd have to write an assembly code parser.

Paul


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

Re: [Qemu-devel] fsp support

[Henrik Nordstrom]

On Sun, 15 May 2005, Juergen Lock wrote:
Radim Kolar <[EMAIL PROTECTED]> asked me to post this (he is not subscribed):
He'd like to see fsp protocol support in qemu in addition to tftp,
the protocol's home page is here:
http://fsp.sourceforge.net/
Note: it should work to just run a fsp server on the host.
Regards
Henrik
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Cursor problems.

[Juergen Lock]

On Tue, May 17, 2005 at 09:10:58PM -0400, Jason wrote:
> On Wed, 2005-05-18 at 01:42 +0200, Juergen Lock wrote:
> > In article <[EMAIL PROTECTED]> you write:
> > >When running qemu on my HP laptop, I cannot seem to use the cursor in the
> > >guest os.  The guest OS can be any os, windows reactos linux, etc.  The
> > >host OS is fedora core 3. Basically, the cursor shows up as normal on the
> > >screen, but when I click in to let qemu grab the focus, the cursor jumps
> > >to the bottom right as soon as any motion happens.  The buttons all still
> > >function properly, I know this because in reactos the curusor is
> > >positioned just above the time.
> > >[...]
> > 
> > I cannot help you other than by saying this is the exact same
> > phenomenon i have on linux since switching to a 2.4 kernel (because
> > of this promise sata card i got, apparently there's no 2.6 driver
> > for that for some reason.)
> > 
> >  Same box runs qemu just fine with working cursor using FreeBSD as
> > host os...
> > 
> > Juergen
> 
> Well, I did a bit more investigation and put a printf into the function
> sdl_send_mouse_event in sdl.c to see what was being sent from the Host
> OS to the guest OS.  It would seem that the SDL_GetRelativeMouseState
> function is reporting odd values for dx and dy on my laptop but not on
> my other machine.  Both of them are running the same OS for the host OS,
> Fedora Core 3.  One is a normal computer with a PS/2 mouse and the other
> is a  laptop with a Synaptics Touch pad and a USB attached mouse.  The
> laptop actually has both devices going through GPM which is set as a
> repeater in PS/2 mode.  So the data being sent to xorg should be PS/2
> data.  Thus the data that SDL is getting should also be PS/2 data, but
> from the look of it, it isn't.  From the look of it, it should be
> reporting small changes either a small positive value or a small
> negative value.
> 
> On my laptop it actually jumps all over the place but it's usually
> large positive values.  I have more investigation to do but it might be
> something like a buffer not getting written write or getting written
> with junk data.  
> 
> Juergen, what type of pointing device do you have?

An optical wheelmouse connected on ps2, kudzu on kanotix detects it as
`ImPS/2 Generic Wheel Mouse'.

 And yes, SDL_VIDEO_X11_DGAMOUSE=0 fixes the problem for me too...

Juergen


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

[Qemu-devel] Nothing happens

[Rudi Lippert]

Hi!
I keep wondering why QEMU does not do anything when I start it.
First of all: yes, I know how to use QEMU. When I use it on my other PC, it
works like a charm.
The major difference between the two systems is, that this one is an AMD64.
And here is what happens when I start QEMU:
Nothing. No output, no CPU activity.
I know that this is not a whole lot of information, but I will provide any
further information that is requested.
Thanks in advance!

Rudi Lippert (Herzogenaurach, Germany)



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

Re: [Qemu-devel] [patch] gcc4 host support

[John Hogerhuis]

This all feels wrong in general. The changes should either be adding
some facility to gcc which permits QEMU to use it in this way (gcc is
an open source project after all, so it's at least a possibility), or
we should generate the dynamic code generator once with whatever
version of GCC and make that part of the build, perhaps even letting
it diverge (i.e. add enhancements/optimizations directly to the
generated assembly).

-- John.


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

Re: [Qemu-devel] [patch] gcc4 host support

[Paul Brook]

On Wednesday 18 May 2005 20:29, John Hogerhuis wrote:
> This all feels wrong in general. The changes should either be adding
> some facility to gcc which permits QEMU to use it in this way (gcc is
> an open source project after all, so it's at least a possibility), 

Are you willing to write and maintain the gcc patches necessary to do this?

qemu is pretty much the only think that has this particular set of 
requirelents (the return instruction must be the last instruction in the 
function). The fact is qemu is abusing the output of gcc in ways that were 
never guaranteed to work.

> or we should generate the dynamic code generator once with whatever
> version of GCC and make that part of the build, perhaps even letting
> it diverge (i.e. add enhancements/optimizations directly to the
> generated assembly).

IMHO That's not really an option. The whole point of dyngen is to avoid having 
to write and maintain big chunks of assembly for every single target.

It's been said before that the long-term solution is to [incrementally] remove 
dyngen altogether, and replace it with a had-written code generator.
I've discussed this in a bit more detail with Fabrice, and have an 
almost-working prototype implementation. When I get something that actually 
works I'll post it to the list for comments.

Paul


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

Re: [Qemu-devel] [patch] gcc4 host support

[David Woodhouse]

On Wed, 2005-05-18 at 21:48 +0100, Paul Brook wrote:
> It's been said before that the long-term solution is to
> [incrementally] remove dyngen altogether, and replace it with a
> had-written code generator. I've discussed this in a bit more detail
> with Fabrice, and have an almost-working prototype implementation.
> When I get something that actually works I'll post it to the list for
> comments.

How feasible would it be to do this as an alternative front end to GCJ's
JIT?

-- 
dwmw2



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

Re: [Qemu-devel] Nothing happens

[Hetz Ben Hamo]

How about starting with trivial details such as:

* Which host OS do you use?
* Which QEMU version?
* binaries downloaded or did you compile it?

Thanks,
Hetz

On 5/18/05, Rudi Lippert <[EMAIL PROTECTED]> wrote:
> Hi!
> I keep wondering why QEMU does not do anything when I start it.
> First of all: yes, I know how to use QEMU. When I use it on my other PC, it
> works like a charm.
> The major difference between the two systems is, that this one is an AMD64.
> And here is what happens when I start QEMU:
> Nothing. No output, no CPU activity.
> I know that this is not a whole lot of information, but I will provide any
> further information that is requested.
> Thanks in advance!
> 
> Rudi Lippert (Herzogenaurach, Germany)
> 
> ___
> 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] Re: Nothing happens

[Rudi Lippert]

My OS:
GNU/Linux (Gentoo)
QEMU Version:
0.7.0, compiled using the standard ebuild; no kqemu or qvm86
I'd include the exact build options, but they're rather lengthy.

I've experienced the same problem with 0.6.1 and CVS somewhere in between
0.6.1 and 0.7.0.

Cheers,
Rudi

Hetz Ben Hamo wrote:

> How about starting with trivial details such as:
> 
> * Which host OS do you use?
> * Which QEMU version?
> * binaries downloaded or did you compile it?
> 
> Thanks,
> Hetz
> 
> On 5/18/05, Rudi Lippert <[EMAIL PROTECTED]> wrote:
>> Hi!
>> I keep wondering why QEMU does not do anything when I start it.
>> First of all: yes, I know how to use QEMU. When I use it on my other PC,
>> it works like a charm.
>> The major difference between the two systems is, that this one is an
>> AMD64. And here is what happens when I start QEMU:
>> Nothing. No output, no CPU activity.
>> I know that this is not a whole lot of information, but I will provide
>> any further information that is requested.
>> Thanks in advance!
>> 
>> Rudi Lippert (Herzogenaurach, Germany)
>> 
>> ___
>> 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] gcc4 host support

[Paul Brook]

On Wednesday 18 May 2005 21:55, David Woodhouse wrote:
> On Wed, 2005-05-18 at 21:48 +0100, Paul Brook wrote:
> > It's been said before that the long-term solution is to
> > [incrementally] remove dyngen altogether, and replace it with a
> > had-written code generator. I've discussed this in a bit more detail
> > with Fabrice, and have an almost-working prototype implementation.
> > When I get something that actually works I'll post it to the list for
> > comments.
>
> How feasible would it be to do this as an alternative front end to GCJ's
> JIT?

GCJ doesn't really have a JIT. It has an interpreter, and the ability to 
compile classes with gcj. I'd expect anything using gcc at runtime would be 
too slow to be worthwhile.

Paul


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

Re: [Qemu-devel] [patch] gcc4 host support

[jeebs]

From: "David Woodhouse"

> On Wed, 2005-05-18 at 21:48 +0100, Paul Brook wrote:
>> It's been said before that the long-term solution is to
>> [incrementally] remove dyngen altogether, and replace it with a
>> had-written code generator. I've discussed this in a bit more detail
>
> How feasible would it be to do this as an alternative front end to GCJ's
> JIT?

I am definetly out of my depth here, but... Speaking of GCJ's JIT...

Sometime back, Ian Rogers here brought up the PearColator project at: 
http://www.binarytranslator.org/

***
I have been working on an open source Java based PowerPC emulator based
around a JVM's optimising compiler. If you have long running server like
workloads then I have found the performance is approaching QEMU fast
whilst having memory supported by a page based system. However, the
system is a lot less sophisticated - booting operating systems and being
a generic emulator is a distant reality. I have created a website at
http://www.binarytranslator.org/ or
http://www.cs.man.ac.uk/apt/projects/jamaica/tools/PearColator/ . I'm
sure some people would be interested in this and may feel like they want
to contribute. I'm happy to oblige and to share with QEMU. Thanks,
***

Looks like he's getting at least some tolerable numbers...

As I said above, I'm out of my depth here.  I just thought it was worth 
bringing this up in case people had forgotten about it.





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

Re[2]: [Qemu-devel] Re: request : qemu-smp as target

[Igor Shmukler]

Hi,

I mostly agree with everything said, but I'd like to add some thoughts tp the 
pot.

I think it's important to understand that that a product that coverts clusters 
to 
virtual MP could be designed with different requirements in mind.

We are working on a research project that represents cluster as a NUMA machine. 
This 
is enough for a NUMA aware OS and performace is not bad.

If we were to make a regular SMP, it would probably not work as well.

I am not a Mosix guy, but I would think that installing QEMU on OM will solve 
nothing. It will only shift problems to be addressed at a different layer. 
Maybe I 
am wrong

Sincerely,

Igor.

> In the applications, probably very independent.  In the kernel, highly 
> dependent: different CPUs may access shared data structures *and* protect 
> them with spinlocks.  As Paul said in a separate mail, spinlocks are going to 
> be way more expensive in this sort of distributed environment.
> 
> All that being said, a company called "Virtual Iron" has got a 
> fully-virtualising solution that presents an SMP to the guest OS but actually 
> distributes computation across a cluster.  I have yet to see the product 
> itself - no idea when it'll be released.  It also sounds *really* difficult 
> to make go fast but at least suggests this sort of thing can perform 
> reasonably for some workloads.
> 
> Cheers,
> Mark



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

Re: [Qemu-devel] Re: Nothing happens

[Struan Bartlett]

How do you mean 'nothing'? Can you be more precise?

Does it display the network interface configuration? open the guest
window? Or really is does it just hang immediately? With the '-monitor
stdio' option does it give you a monitor prompt?

Have you tried running qemu with:

strace qemu  2>/tmp/qemu.log

On Wed, 18 May 2005, Rudi Lippert wrote:

> My OS:
> GNU/Linux (Gentoo)
> QEMU Version:
> 0.7.0, compiled using the standard ebuild; no kqemu or qvm86
> I'd include the exact build options, but they're rather lengthy.
>
> I've experienced the same problem with 0.6.1 and CVS somewhere in between
> 0.6.1 and 0.7.0.
>
> Cheers,
> Rudi
>
> Hetz Ben Hamo wrote:
>
> > How about starting with trivial details such as:
> >
> > * Which host OS do you use?
> > * Which QEMU version?
> > * binaries downloaded or did you compile it?
> >
> > Thanks,
> > Hetz
> >
> > On 5/18/05, Rudi Lippert <[EMAIL PROTECTED]> wrote:
> >> Hi!
> >> I keep wondering why QEMU does not do anything when I start it.
> >> First of all: yes, I know how to use QEMU. When I use it on my other PC,
> >> it works like a charm.
> >> The major difference between the two systems is, that this one is an
> >> AMD64. And here is what happens when I start QEMU:
> >> Nothing. No output, no CPU activity.
> >> I know that this is not a whole lot of information, but I will provide
> >> any further information that is requested.
> >> Thanks in advance!
> >>
> >> Rudi Lippert (Herzogenaurach, Germany)
> >>
> >> ___
> >> 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

Re: [Qemu-devel] [patch] gcc4 host support

[Paul Brook]

> I am definetly out of my depth here, but... Speaking of GCJ's JIT...
>
> Sometime back, Ian Rogers here brought up the PearColator project at:
> http://www.binarytranslator.org/
>
> ***
> I have been working on an open source Java based PowerPC emulator based
> around a JVM's optimising compiler. If you have long running server like
> workloads then I have found the performance is approaching QEMU fast
> whilst having memory supported by a page based system. However, the
> system is a lot less sophisticated - booting operating systems and being
> a generic emulator is a distant reality. I have created a website at
> http://www.binarytranslator.org/ or
> http://www.cs.man.ac.uk/apt/projects/jamaica/tools/PearColator/ . I'm
> sure some people would be interested in this and may feel like they want
> to contribute. I'm happy to oblige and to share with QEMU. Thanks,
> ***
>
> Looks like he's getting at least some tolerable numbers...

I know I'd seen something like this before, thanks for reminding me.

There are several issues with PearColator/RVM:

- It's written in java. qemu is written in C, so a lot of porting would be 
required to get anything working.
- The best benchmark results are half the speed of qemu, and ten times slower 
appears to be a more typical result.
- I can't see an any way of doing an incremental transition. My code generator 
coexists with dyngen, allowing a gentle migration away from dyngen.

Paul


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

Re: [Qemu-devel] [patch] gcc4 host support

[Ian Rogers]

[EMAIL PROTECTED] wrote:
I am definetly out of my depth here, but... Speaking of GCJ's JIT...
Sometime back, Ian Rogers here brought up the PearColator project at: 
http://www.binarytranslator.org/
 

We're still here and hacking. PearColator and QEMU are quite different 
projects and we rely on the Jikes RVM code generator - however, that is 
quite advanced. We can run on other JVMs using reflection, but the 
performance is so slow to not make that attractive. QEMU is far more 
developed than we are in terms of running things. I appologize for the 
now broken links, our main project page is:
http://www.cs.manchester.ac.uk/apt/projects/jamaica/
We're under the CPL as is the Jikes RVM and we're following their 
typical development cycle of work, publication and then source release. 
Please contact us for more information.

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

Re: [Qemu-devel] [PATCH] slirp 64-bit fixes

[Tim]

> Curious if the patches to slirp are being forwarded upstream to the
> current slirp maintainer.

I found a number of security holes in slirp before, and tried to notify
them.  I found the package isn't being maintained anymore.


tim


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

Re: [Qemu-devel] [patch] gcc4 host support

[Ian Rogers]

Paul Brook wrote:
I know I'd seen something like this before, thanks for reminding me.
There are several issues with PearColator/RVM:
- It's written in java. qemu is written in C, so a lot of porting would be 
required to get anything working.
- The best benchmark results are half the speed of qemu, and ten times slower 
appears to be a more typical result.
- I can't see an any way of doing an incremental transition. My code generator 
coexists with dyngen, allowing a gentle migration away from dyngen.
 

The currently published benchmark results are for PearColator with just 
an optimizing compiler (worst case in Jikes RVM is over 100 compiler 
stages). We also emulate a TLB in much the same way as PearPC, so 
comparing us to QEMU fast isn't fair (we generate in the region of 10 
instructions for loads and stores whereas QEMU fast can generate 1). Our 
best results are for things that sit in dynamic code for a long period 
of time, which isn't too surprising. We are working on equivalent 
results to QEMU fast, but our approach is different to that of QEMU and 
I completely agree that trying to get QEMU/PearColator to co-exist 
wouldn't be that great.

Regards,
Ian Rogers

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

[Qemu-devel] $B$*EA$($7$?$$$3$H$,M-$j$^$9!#(B

[info]

$B$O$8$a$^$7$F!"EvJ}=P2q$N9->l$r3+:E$7$*$+$2$5$^$G9%I>[EMAIL PROTECTED](B
$B(Bhttp://www.lovegal2.net/?square2
[EMAIL PROTECTED]|!"[EMAIL 
PROTECTED]"%s%1!<%H$r/$J$$0Y!"=P2q$($J$$!&!&!&!W(B

$B!V>R2p$5$l$?$1$I!"=;=j$,N%$l$F$$$k$+$i!"BT$A9g$o$;>l=j$K9T$1$J$$!&!&!&!W(B

[EMAIL PROTECTED]"[EMAIL 
PROTECTED]:]$7$F$O?.Mj$N$*$1$kJ}$+$I$&$+$H$$$&?3::[EMAIL PROTECTED],!"@[EMAIL 
PROTECTED],05E]E*$K>/$J$/$J$C$F$7$^$C$?$?$a$K!"[EMAIL 
PROTECTED]::L5$7$G"(L5NAEPO?"($,$G$-$k$h$&$K$$$?$7$^$7$?!#99$K$"[EMAIL 
PROTECTED];~L5NA$G>R2p$5$;$FD:$-$^$9!#(B

$B"-"-"-<+F0>R2p(B24$B;~4Vhttp://www.lovegal2.net/?syoukai2
$B$4EPO?D>[EMAIL 
PROTECTED]>R2p$5$;$FD:$-$^$9!#(B24$B;~4VBN@)!!$GC4Ev$NpJs$r8x3+CW$7$^$9!#(B

















$B$J$*!"4uK>$r$5$l$J$$>l9g$O(B
$B!!([EMAIL PROTECTED]
$B$^$G$*4j$$$7$^$9!#;j5^!"G[?.Dd;_$Nhttp://lists.nongnu.org/mailman/listinfo/qemu-devel