Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]

[J. Mayer]

On Sat, 2007-10-13 at 10:11 +0300, Blue Swirl wrote:
> On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> >  Forwarded Message 
> > > From: Jocelyn Mayer <[EMAIL PROTECTED]>
> > > Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
> > > To: qemu-devel@nongnu.org
> > > Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
> > > Date: Fri, 12 Oct 2007 20:24:44 +0200
> > >
> > > On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
> > > > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > Here's a small patch that allow an optimisation for code fetch, at 
> > > > > least
> > > > > for RISC CPU targets, as suggested by Fabrice Bellard.
> > > > > The main idea is that a translated block is never to span over a page
> > > > > boundary. As the tb_find_slow routine already gets the physical 
> > > > > address
> > > > > of the page of code to be translated, the code translator could then
> > > > > fetch the code using raw host memory accesses instead of doing it
> > > > > through the softmmu routines.
> > > > > This patch could also be adapted to RISC CPU targets, with care for 
> > > > > the
> > > > > last instruction of a page. For now, I did implement it for alpha, 
> > > > > arm,
> > > > > mips, PowerPC and SH4.
> > > > > I don't actually know if the optimsation would bring a sensible speed
> > > > > gain or if it will be absolutelly marginal.
> > > > >
> > > > > Please comment.
> > > >
> > > > This will not work correctly for execution of MMIO registers, but
> > > > maybe that won't work on real hardware either. Who cares.
> > >
> > > I wonder if this is important or not... But maybe, when retrieving the
> > > physical address we could check if it is inside ROM/RAM or an I/O area
> > > and in the last case do not give the phys_addr information to the
> > > translator. In that case, it would go on using the ldxx_code. I guess if
> > > we want to do that, a set of helpers would be appreciated to avoid
> > > adding code like:
> > > if (phys_pc == 0)
> > >   opc = ldul_code(virt_pc)
> > > else
> > >   opc = ldul_raw(phys_pc)
> > > everywhere... I could also add another check so this set of macro would
> > > automatically use ldxx_code if we reach a page boundary, which would
> > > then make easy to use this optimisation for CISC/VLE architectures too.
> > >
> > > I'm not sure of the proper solution to allow executing code from mmio
> > > devices. But adding specific accessors to handle the CISC/VLE case is to
> > > be done.
> >
> > [...]
> >
> > I did update my patch following this way and it's now able to run x86
> > and PowerPC targets.
> > PowerPC is the easy case, x86 is maybe the worst... Well, I'm not really
> > sure of what I've done for Sparc, but other targets should be safe.
> 
> It broke Sparc, delay slot handling makes things complicated. The
> updated patch passes my tests.

OK. I will take a look of how you solved this issue.

> For extra performance, I bypassed the ldl_code_p. On Sparc,
> instructions can't be split between two pages. Isn't translation
> always contained to the same page for all targets like Sparc?

Yes, for RISC targets running 32 bits mode, we always stop translation
when we reach the end of a code page. The problem comes with CISC
architectures, like x86 or m68k, or RISC architecture running 16/32 bits
code, like ARM in thumb mode or PowerPC in VLE mode. In all those case,
there can be instructions spanning on 2 pages, then we need the
ldx_code_p functions.
My idea of always using the ldx_code_p function is that we may have the
occasion to make it more cleaver and make the slow case handle code
execution in mmio areas, when it will be possible.

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

Re: [Qemu-devel] RFC: avoid #ifdef for target cpu list - for x86, too.

[J. Mayer]

On Fri, 2007-10-12 at 10:54 +0200, Dan Kenigsberg wrote:
> This seems like a good excuse to send my suggested -cpu option for the
> x86 target. It is just like my previous "take 4", but fits to the newly
> unified cpu_list.

I don't know x86 so well to comment the x86 CPU definitions, but having
this option for x86 too is welcome...

[...]

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

Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

[Blue Swirl]

On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> The problem:
> some CPU architectures, namely PowerPC and maybe others, offers
> facilities to access the memory or I/O in the reverse endianness, ie
> little-endian instead of big-endian for PowerPC, or provide instruction
> to make memory accesses in the "reverse-endian". This is implemented as
> a global flag on some CPU. This case is already handled by the PowerPC
> emulation but is is far from being optimal. Some other implementations
> allow the OS to store an "reverse-endian" flag in the TLB or the segment
> descriptors, thus providing per-page or per-segment endianness control.
> This is mostly used to ease driver migration from a PC platform to
> PowerPC without taking any care of the device endianness in the driver
> code (yes, this is bad...).

Nice, this may be useful for Sparc64. It has a global CPU flag for
endianness, individual pages can be marked as reverse endian, and
finally there are instructions that access memory in reverse endian.
The end result is a XOR of all these reverses. Though I don't know if
any of these features are used at all.

Other memory access functions could be merged too. Is the 32 bit load
with sign extension to 64 bits used in other architectures?

Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]

[Blue Swirl]

On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 10:11 +0300, Blue Swirl wrote:
> > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > >  Forwarded Message 
> > > > From: Jocelyn Mayer <[EMAIL PROTECTED]>
> > > > Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
> > > > To: qemu-devel@nongnu.org
> > > > Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
> > > > Date: Fri, 12 Oct 2007 20:24:44 +0200
> > > >
> > > > On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
> > > > > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > > Here's a small patch that allow an optimisation for code fetch, at 
> > > > > > least
> > > > > > for RISC CPU targets, as suggested by Fabrice Bellard.
> > > > > > The main idea is that a translated block is never to span over a 
> > > > > > page
> > > > > > boundary. As the tb_find_slow routine already gets the physical 
> > > > > > address
> > > > > > of the page of code to be translated, the code translator could then
> > > > > > fetch the code using raw host memory accesses instead of doing it
> > > > > > through the softmmu routines.
> > > > > > This patch could also be adapted to RISC CPU targets, with care for 
> > > > > > the
> > > > > > last instruction of a page. For now, I did implement it for alpha, 
> > > > > > arm,
> > > > > > mips, PowerPC and SH4.
> > > > > > I don't actually know if the optimsation would bring a sensible 
> > > > > > speed
> > > > > > gain or if it will be absolutelly marginal.
> > > > > >
> > > > > > Please comment.
> > > > >
> > > > > This will not work correctly for execution of MMIO registers, but
> > > > > maybe that won't work on real hardware either. Who cares.
> > > >
> > > > I wonder if this is important or not... But maybe, when retrieving the
> > > > physical address we could check if it is inside ROM/RAM or an I/O area
> > > > and in the last case do not give the phys_addr information to the
> > > > translator. In that case, it would go on using the ldxx_code. I guess if
> > > > we want to do that, a set of helpers would be appreciated to avoid
> > > > adding code like:
> > > > if (phys_pc == 0)
> > > >   opc = ldul_code(virt_pc)
> > > > else
> > > >   opc = ldul_raw(phys_pc)
> > > > everywhere... I could also add another check so this set of macro would
> > > > automatically use ldxx_code if we reach a page boundary, which would
> > > > then make easy to use this optimisation for CISC/VLE architectures too.
> > > >
> > > > I'm not sure of the proper solution to allow executing code from mmio
> > > > devices. But adding specific accessors to handle the CISC/VLE case is to
> > > > be done.
> > >
> > > [...]
> > >
> > > I did update my patch following this way and it's now able to run x86
> > > and PowerPC targets.
> > > PowerPC is the easy case, x86 is maybe the worst... Well, I'm not really
> > > sure of what I've done for Sparc, but other targets should be safe.
> >
> > It broke Sparc, delay slot handling makes things complicated. The
> > updated patch passes my tests.
>
> OK. I will take a look of how you solved this issue.
>
> > For extra performance, I bypassed the ldl_code_p. On Sparc,
> > instructions can't be split between two pages. Isn't translation
> > always contained to the same page for all targets like Sparc?
>
> Yes, for RISC targets running 32 bits mode, we always stop translation
> when we reach the end of a code page. The problem comes with CISC
> architectures, like x86 or m68k, or RISC architecture running 16/32 bits
> code, like ARM in thumb mode or PowerPC in VLE mode. In all those case,
> there can be instructions spanning on 2 pages, then we need the
> ldx_code_p functions.

I see.

> My idea of always using the ldx_code_p function is that we may have the
> occasion to make it more cleaver and make the slow case handle code
> execution in mmio areas, when it will be possible.

The fast path could be provided for the RISC targets conditional to, for example
#define TARGET_CODE_ALIGNED
or something.

Re: [Qemu-devel] Kqemu on x86_64 host with x86_64 guest

[Bruno Cornec]

On Fri, Oct 12, 2007 at 08:04:16AM +0200, Bruno Cornec wrote:
> I Can say the same of Mandriva 2007.1 as host, and SuSE 10.3,Debian 4.0,
> RHEL 5 ... as guests.
> 
> > Unsupported return value: 0x
> 
> Exactly the same.

However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same
host.

Bruno.
-- 
Des infos sur la musique ancienne  -- http://www.musique-ancienne.org
Des infos sur les logiciels libres -- http://www.HyPer-Linux.org
Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, 
Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)

Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]

[Blue Swirl]

On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 11:57 +0200, J. Mayer wrote:
> > On Sat, 2007-10-13 at 10:11 +0300, Blue Swirl wrote:
> > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > >  Forwarded Message 
> > > > > From: Jocelyn Mayer <[EMAIL PROTECTED]>
> > > > > Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
> > > > > To: qemu-devel@nongnu.org
> > > > > Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
> > > > > Date: Fri, 12 Oct 2007 20:24:44 +0200
> > > > >
> > > > > On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
> > > > > > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > > > Here's a small patch that allow an optimisation for code fetch, 
> > > > > > > at least
> > > > > > > for RISC CPU targets, as suggested by Fabrice Bellard.
> > > > > > > The main idea is that a translated block is never to span over a 
> > > > > > > page
> > > > > > > boundary. As the tb_find_slow routine already gets the physical 
> > > > > > > address
> > > > > > > of the page of code to be translated, the code translator could 
> > > > > > > then
> > > > > > > fetch the code using raw host memory accesses instead of doing it
> > > > > > > through the softmmu routines.
> > > > > > > This patch could also be adapted to RISC CPU targets, with care 
> > > > > > > for the
> > > > > > > last instruction of a page. For now, I did implement it for 
> > > > > > > alpha, arm,
> > > > > > > mips, PowerPC and SH4.
> > > > > > > I don't actually know if the optimsation would bring a sensible 
> > > > > > > speed
> > > > > > > gain or if it will be absolutelly marginal.
> > > > > > >
> > > > > > > Please comment.
> > > > > >
> > > > > > This will not work correctly for execution of MMIO registers, but
> > > > > > maybe that won't work on real hardware either. Who cares.
> > > > >
> > > > > I wonder if this is important or not... But maybe, when retrieving the
> > > > > physical address we could check if it is inside ROM/RAM or an I/O area
> > > > > and in the last case do not give the phys_addr information to the
> > > > > translator. In that case, it would go on using the ldxx_code. I guess 
> > > > > if
> > > > > we want to do that, a set of helpers would be appreciated to avoid
> > > > > adding code like:
> > > > > if (phys_pc == 0)
> > > > >   opc = ldul_code(virt_pc)
> > > > > else
> > > > >   opc = ldul_raw(phys_pc)
> > > > > everywhere... I could also add another check so this set of macro 
> > > > > would
> > > > > automatically use ldxx_code if we reach a page boundary, which would
> > > > > then make easy to use this optimisation for CISC/VLE architectures 
> > > > > too.
> > > > >
> > > > > I'm not sure of the proper solution to allow executing code from mmio
> > > > > devices. But adding specific accessors to handle the CISC/VLE case is 
> > > > > to
> > > > > be done.
> > > >
> > > > [...]
> > > >
> > > > I did update my patch following this way and it's now able to run x86
> > > > and PowerPC targets.
> > > > PowerPC is the easy case, x86 is maybe the worst... Well, I'm not really
> > > > sure of what I've done for Sparc, but other targets should be safe.
> > >
> > > It broke Sparc, delay slot handling makes things complicated. The
> > > updated patch passes my tests.
> >
> > OK. I will take a look of how you solved this issue.
> >
> > > For extra performance, I bypassed the ldl_code_p. On Sparc,
> > > instructions can't be split between two pages. Isn't translation
> > > always contained to the same page for all targets like Sparc?
> >
> > Yes, for RISC targets running 32 bits mode, we always stop translation
> > when we reach the end of a code page. The problem comes with CISC
> > architectures, like x86 or m68k, or RISC architecture running 16/32 bits
> > code, like ARM in thumb mode or PowerPC in VLE mode. In all those case,
> > there can be instructions spanning on 2 pages, then we need the
> > ldx_code_p functions.
> > My idea of always using the ldx_code_p function is that we may have the
> > occasion to make it more cleaver and make the slow case handle code
> > execution in mmio areas, when it will be possible.
>
> Here's an updated patch. I added a definition TARGET_HAS_VLE_INSNS which
> is defined is the cris, i386, m68k and ppcemb cases. Arm already has an
> explicit support for 32 bits thumb instructions spanning 2 pages, so it
> should not need this define. When this define is not set, the
> ldxxx_code_p function just does ldxxx_raw(phys_pc) in the softmmu case
> and ldxxx_raw(pc) in the user-mode only case. This is optimal for pure
> RISC architectures and does not need the #ifdef CONFIG_USER_ONLY you
> added for Sparc in your patch version. I also added a provision for a
> TARGET_MMIO_CODE define which may be used later when this will really be
> supported by Qemu.
> I also took your fixes for Sparc phys_pc computation, but reversed your
> patch to use ldl_raw as it should not be needed anymore.
> I did test PowerPC in user-mode only

Re: [Qemu-devel] Kqemu on x86_64 host with x86_64 guest

[Bruno Cornec]

On Sat, Oct 13, 2007 at 01:53:37PM +0200, Bruno Cornec wrote:
> However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same
> host.

I stand corrected. It also crashed but later during the install process,
where the other were at the start. Back to -no-kqemu.

Bruno.
-- 
Des infos sur la musique ancienne  -- http://www.musique-ancienne.org
Des infos sur les logiciels libres -- http://www.HyPer-Linux.org
Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, 
Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)

Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

[Thiemo Seufer]

Blue Swirl wrote:
> On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > The problem:
> > some CPU architectures, namely PowerPC and maybe others, offers
> > facilities to access the memory or I/O in the reverse endianness, ie
> > little-endian instead of big-endian for PowerPC, or provide instruction
> > to make memory accesses in the "reverse-endian". This is implemented as
> > a global flag on some CPU. This case is already handled by the PowerPC
> > emulation but is is far from being optimal. Some other implementations
> > allow the OS to store an "reverse-endian" flag in the TLB or the segment
> > descriptors, thus providing per-page or per-segment endianness control.
> > This is mostly used to ease driver migration from a PC platform to
> > PowerPC without taking any care of the device endianness in the driver
> > code (yes, this is bad...).
> 
> Nice, this may be useful for Sparc64. It has a global CPU flag for
> endianness, individual pages can be marked as reverse endian, and
> finally there are instructions that access memory in reverse endian.
> The end result is a XOR of all these reverses. Though I don't know if
> any of these features are used at all.

Likewise for the MIPS reverse endianness global flag.

> Other memory access functions could be merged too. Is the 32 bit load
> with sign extension to 64 bits used in other architectures?

Yes for MIPS.


Thiemo

Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

[Blue Swirl]

On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 13:47 +0300, Blue Swirl wrote:
> > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > The problem:
> > > some CPU architectures, namely PowerPC and maybe others, offers
> > > facilities to access the memory or I/O in the reverse endianness, ie
> > > little-endian instead of big-endian for PowerPC, or provide instruction
> > > to make memory accesses in the "reverse-endian". This is implemented as
> > > a global flag on some CPU. This case is already handled by the PowerPC
> > > emulation but is is far from being optimal. Some other implementations
> > > allow the OS to store an "reverse-endian" flag in the TLB or the segment
> > > descriptors, thus providing per-page or per-segment endianness control.
> > > This is mostly used to ease driver migration from a PC platform to
> > > PowerPC without taking any care of the device endianness in the driver
> > > code (yes, this is bad...).
> >
> > Nice, this may be useful for Sparc64. It has a global CPU flag for
> > endianness, individual pages can be marked as reverse endian, and
> > finally there are instructions that access memory in reverse endian.
> > The end result is a XOR of all these reverses. Though I don't know if
> > any of these features are used at all.
>
> I realized that I/O accesses for reverse-endian pages were not correct
> in the softmmu_template.h header. This new version fixes this. It also
> remove duplicated code in the case of unaligned accesses in a
> reverse-endian page.

I think 64 bit access case is not handled correctly, but to solve that
it would be nice to extend the current IO access system to 64 bits.

[Qemu-devel] qemu/hw mips_r4k.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/13 14:00:23

Modified files:
hw : mips_r4k.c 

Log message:
Static-ify function.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.48&r2=1.49

Re: [Qemu-devel] Kqemu on x86_64 host with x86_64 guest

[Werner Dittmann]

Bruno Cornec wrote:
> On Sat, Oct 13, 2007 at 01:53:37PM +0200, Bruno Cornec wrote:
>> However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same
>> host.
> 
> I stand corrected. It also crashed but later during the install process,
> where the other were at the start. Back to -no-kqemu.
> 
> Bruno.
Even when using -no-kqemu it somehow fails/hangs during setup of Grub
when I try to install a openSuse 10.2 or 10.3 . These problems are know
for quite some time - but no solution yet.

Werner

Re: [Qemu-devel] Kqemu on x86_64 host with x86_64 guest

[Bruno Cornec]

On Sat, Oct 13, 2007 at 04:24:45PM +0200, Werner Dittmann wrote:
> Even when using -no-kqemu it somehow fails/hangs during setup of Grub
> when I try to install a openSuse 10.2 or 10.3 . These problems are know
> for quite some time - but no solution yet.

Agreed, but is it only linked to qemu for that grub problem or to grub,
as changing to lilo for x86_64 VMs solves generally the issue.

Bruno.
-- 
Des infos sur la musique ancienne  -- http://www.musique-ancienne.org
Des infos sur les logiciels libres -- http://www.HyPer-Linux.org
Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, 
Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)

[Qemu-devel] [PATCH] add 'downscript' parameter for -net tap

[Wolfram Gloger]

Hi,

For symmetry, there should be a script called before a tap device is
brought down IMHO.  Please consider the appended patch.

Regards,
Wolfram.

--- vl.c.orig   2007-07-29 19:57:25.0 +0200
+++ vl.c2007-10-13 16:04:51.0 +0200
@@ -107,6 +107,7 @@
 #include "exec-all.h"
 
 #define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
+#define DEFAULT_NETWORK_DOWN_SCRIPT "/etc/qemu-ifdown"
 #ifdef __sun__
 #define SMBD_COMMAND "/usr/sfw/sbin/smbd"
 #else
@@ -3412,6 +3413,7 @@
 typedef struct TAPState {
 VLANClientState *vc;
 int fd;
+char down_script[1024];
 } TAPState;
 
 static void tap_receive(void *opaque, const uint8_t *buf, int size)
@@ -3647,27 +3649,13 @@
 }
 #endif
 
-static int net_tap_init(VLANState *vlan, const char *ifname1,
-const char *setup_script)
+static int launch_script(const char *setup_script, const char *ifname, int fd)
 {
-TAPState *s;
-int pid, status, fd;
+int pid, status;
 char *args[3];
 char **parg;
-char ifname[128];
-
-if (ifname1 != NULL)
-pstrcpy(ifname, sizeof(ifname), ifname1);
-else
-ifname[0] = '\0';
-TFR(fd = tap_open(ifname, sizeof(ifname)));
-if (fd < 0)
-return -1;
 
-if (!setup_script || !strcmp(setup_script, "no"))
-setup_script = "";
-if (setup_script[0] != '\0') {
-/* try to launch network init script */
+/* try to launch network script */
 pid = fork();
 if (pid >= 0) {
 if (pid == 0) {
@@ -3681,7 +3669,7 @@
 
 parg = args;
 *parg++ = (char *)setup_script;
-*parg++ = ifname;
+*parg++ = (char *)ifname;
 *parg++ = NULL;
 execv(setup_script, args);
 _exit(1);
@@ -3694,12 +3682,37 @@
 return -1;
 }
 }
+   return 0;
+}
+
+static int net_tap_init(VLANState *vlan, const char *ifname1,
+const char *setup_script, const char *down_script)
+{
+TAPState *s;
+int fd;
+char ifname[128];
+
+if (ifname1 != NULL)
+pstrcpy(ifname, sizeof(ifname), ifname1);
+else
+ifname[0] = '\0';
+TFR(fd = tap_open(ifname, sizeof(ifname)));
+if (fd < 0)
+return -1;
+
+if (!setup_script || !strcmp(setup_script, "no"))
+setup_script = "";
+if (setup_script[0] != '\0') {
+   if (launch_script(setup_script, ifname, fd))
+   return -1;
 }
 s = net_tap_fd_init(vlan, fd);
 if (!s)
 return -1;
 snprintf(s->vc->info_str, sizeof(s->vc->info_str), 
  "tap: ifname=%s setup_script=%s", ifname, setup_script);
+if (down_script && strcmp(down_script, "no"))
+   snprintf(s->down_script, sizeof(s->down_script), "%s", down_script);
 return 0;
 }
 
@@ -4243,7 +4256,7 @@
 #else
 if (!strcmp(device, "tap")) {
 char ifname[64];
-char setup_script[1024];
+char setup_script[1024], down_script[1024];
 int fd;
 vlan->nb_host_devs++;
 if (get_param_value(buf, sizeof(buf), "fd", p) > 0) {
@@ -4258,7 +4271,10 @@
 if (get_param_value(setup_script, sizeof(setup_script), "script", 
p) == 0) {
 pstrcpy(setup_script, sizeof(setup_script), 
DEFAULT_NETWORK_SCRIPT);
 }
-ret = net_tap_init(vlan, ifname, setup_script);
+if (get_param_value(down_script, sizeof(down_script), 
"downscript", p) == 0) {
+pstrcpy(down_script, sizeof(down_script), 
DEFAULT_NETWORK_DOWN_SCRIPT);
+}
+ret = net_tap_init(vlan, ifname, setup_script, down_script);
 }
 } else
 #endif
@@ -6646,10 +6662,11 @@
"-net tap[,vlan=n],ifname=name\n"
"connect the host TAP network interface to VLAN 
'n'\n"
 #else
-   "-net tap[,vlan=n][,fd=h][,ifname=name][,script=file]\n"
-   "connect the host TAP network interface to VLAN 'n' 
and use\n"
-   "the network script 'file' (default=%s);\n"
-   "use 'script=no' to disable script execution;\n"
+   "-net 
tap[,vlan=n][,fd=h][,ifname=name][,script=file][,downscript=dfile]\n"
+   "connect the host TAP network interface to VLAN 'n' 
and use the\n"
+   "network scripts 'file' (default=%s)\n"
+   "and 'dfile' (default=%s);\n"
+   "use '[down]script=no' to disable script 
execution;\n"
"use 'fd=h' to connect to an already opened TAP 
interface\n"
 #endif
"-net 
socket[,vlan=n][,fd=h][,listen=[host]:port][,connect=host:port]\n"
@@ -6720,6 +6737,7 @@
DEFAULT_RAM_SIZE,
 #ifndef _WIN32
DEFAULT_NETWORK_SCRIPT,
+   DEFAULT_NETWORK_DOWN_SCRIPT,
 #endif
DEFAULT_GDBSTUB_PORT,
"/tmp/qemu.log");
@@ -80

Re: [Qemu-devel] Kqemu on x86_64 host with x86_64 guest

[Julian Seward]

On Saturday 13 October 2007 16:24, Werner Dittmann wrote:
> Bruno Cornec wrote:
> > On Sat, Oct 13, 2007 at 01:53:37PM +0200, Bruno Cornec wrote:
> >> However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same
> >> host.
> >
> > I stand corrected. It also crashed but later during the install process,
> > where the other were at the start. Back to -no-kqemu.
> >
> > Bruno.
>
> Even when using -no-kqemu it somehow fails/hangs during setup of Grub
> when I try to install a openSuse 10.2 or 10.3 . These problems are know
> for quite some time - but no solution yet.

Yes.  I also observed that with openSUSE 10.{1,2,3}.  After some
experimentation I successfully installed 10.1 by asking the installer
to use LILO instead of Grub.  However, even then, some user space
code does not work properly - running the YaST online update inside the
successfully-installed 10.1 fails.

I wondered if there is some problem in the x86_64 instruction set emulation.
I ran some tests from Valgrind, and it appears that some FP->int conversion
instructions do not take care of the rounding mode.  I did not detect
any other errors.  See
http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00233.html

I tried to build x86_64-softmmu using softfloat.c rather than
softfloat-native.c since it looks like softfloat.c emulates these
corner cases (rounding mode, etc) more completely.  So far I got 
a lot of compilation errors and did not make much progress.  I get
the impression x86_64-softmmu and i386-softmmu are intended only to
be built with softfloat-native.c.

It might be worth installing SuSE 10.1 and finding some small program
which fails to work properly.  Then we might have a hope of determining
what the problem is.

J

[Qemu-devel] qemu/target-mips helper.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/13 17:29:10

Modified files:
target-mips: helper.c 

Log message:
Fix off-by-one in address check.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.53&r2=1.54

[Qemu-devel] qemu/target-mips TODO

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/13 19:00:52

Modified files:
target-mips: TODO 

Log message:
Update TODO.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/TODO?cvsroot=qemu&r1=1.15&r2=1.16

Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]

[Thiemo Seufer]

J. Mayer wrote:
[snip]
> > My idea of always using the ldx_code_p function is that we may have the
> > occasion to make it more cleaver and make the slow case handle code
> > execution in mmio areas, when it will be possible.
> 
> Here's an updated patch. I added a definition TARGET_HAS_VLE_INSNS which
> is defined is the cris, i386, m68k and ppcemb cases. Arm already has an
> explicit support for 32 bits thumb instructions spanning 2 pages, so it
> should not need this define. When this define is not set, the
> ldxxx_code_p function just does ldxxx_raw(phys_pc) in the softmmu case
> and ldxxx_raw(pc) in the user-mode only case. This is optimal for pure
> RISC architectures and does not need the #ifdef CONFIG_USER_ONLY you
> added for Sparc in your patch version. I also added a provision for a
> TARGET_MMIO_CODE define which may be used later when this will really be
> supported by Qemu.
> I also took your fixes for Sparc phys_pc computation, but reversed your
> patch to use ldl_raw as it should not be needed anymore.
> I did test PowerPC in user-mode only and softmmu mode and i386 in
> softmmu successfully using this new version of the patch.

Works ok for MIPS. There's no obvious change in performance, I guess
the slow TLB emulation drowns out any possible improvement.


Thiemo

[Qemu-devel] [RFC] sparc32 MXCC support

[Robert Reif]

I'm trying to add SuperSparc II MXCC support and need some feedback.

Is there a better way to read and write physical memory in 64bit chunks?
I'm not sure what I'm doing is portable between 32/64 and big/little endian.
Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.55
diff -p -u -r1.55 sun4m.c
--- hw/sun4m.c  6 Oct 2007 11:28:21 -   1.55
+++ hw/sun4m.c  13 Oct 2007 20:35:48 -
@@ -327,7 +327,7 @@ static void *sun4m_hw_init(const struct 
 
 for(i = 0; i < smp_cpus; i++) {
 env = cpu_init();
-cpu_sparc_register(env, def);
+cpu_sparc_register(env, def, i);
 envs[i] = env;
 if (i == 0) {
 qemu_register_reset(main_cpu_reset, env);
Index: linux-user/main.c
===
RCS file: /sources/qemu/qemu/linux-user/main.c,v
retrieving revision 1.132
diff -p -u -r1.132 main.c
--- linux-user/main.c   12 Oct 2007 06:47:46 -  1.132
+++ linux-user/main.c   13 Oct 2007 20:35:49 -
@@ -2139,7 +2139,7 @@ int main(int argc, char **argv)
 fprintf(stderr, "Unable to find Sparc CPU definition\n");
 exit(1);
 }
-cpu_sparc_register(env, def);
+cpu_sparc_register(env, def, 0);
env->pc = regs->pc;
env->npc = regs->npc;
 env->y = regs->y;
Index: target-sparc/cpu.h
===
RCS file: /sources/qemu/qemu/target-sparc/cpu.h,v
retrieving revision 1.53
diff -p -u -r1.53 cpu.h
--- target-sparc/cpu.h  12 Oct 2007 06:47:46 -  1.53
+++ target-sparc/cpu.h  13 Oct 2007 20:35:49 -
@@ -210,6 +210,8 @@ typedef struct CPUSPARCState {
 uint64_t dtlb_tte[64];
 #else
 uint32_t mmuregs[16];
+uint64_t mxccdata[4];
+uint64_t mxccregs[8];
 #endif
 /* temporary float registers */
 float32 ft0, ft1;
@@ -266,7 +268,7 @@ int cpu_sparc_close(CPUSPARCState *s);
 int sparc_find_by_name (const unsigned char *name, const sparc_def_t **def);
 void sparc_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
  ...));
-int cpu_sparc_register (CPUSPARCState *env, const sparc_def_t *def);
+int cpu_sparc_register (CPUSPARCState *env, const sparc_def_t *def, int cpu);
 
 #define GET_PSR(env) (env->version | (env->psr & PSR_ICC) | \
   (env->psref? PSR_EF : 0) |\
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.41
diff -p -u -r1.41 op_helper.c
--- target-sparc/op_helper.c1 Oct 2007 17:07:58 -   1.41
+++ target-sparc/op_helper.c13 Oct 2007 20:35:51 -
@@ -2,6 +2,7 @@
 
 //#define DEBUG_PCALL
 //#define DEBUG_MMU
+#define DEBUG_MXCC
 //#define DEBUG_UNALIGNED
 //#define DEBUG_UNASSIGNED
 
@@ -139,12 +140,68 @@ GEN_FCMP(fcmped_fcc3, float64, DT0, DT1,
 
 #ifndef TARGET_SPARC64
 #ifndef CONFIG_USER_ONLY
+
+#ifdef DEBUG_MXCC
+void dump_mxcc(CPUState *env)
+{
+printf("mxccdata: %016llx %016llx %016llx %016llx\n",
+env->mxccdata[0], env->mxccdata[1], env->mxccdata[2], 
env->mxccdata[3]);
+printf("mxccregs: %016llx %016llx %016llx %016llx\n"
+   "  %016llx %016llx %016llx %016llx\n",
+env->mxccregs[0], env->mxccregs[1], env->mxccregs[2], env->mxccregs[3],
+env->mxccregs[4], env->mxccregs[5], env->mxccregs[6], 
env->mxccregs[7]);
+}
+#endif
+
 void helper_ld_asi(int asi, int size, int sign)
 {
 uint32_t ret = 0;
+#ifdef DEBUG_MXCC
+uint32_t last_T0 = T0;
+#endif
 
 switch (asi) {
 case 2: /* SuperSparc MXCC registers */
+switch (T0) {
+case 0x01c00a00: /* MXCC control register */
+if (size == 8) {
+ret = env->mxccregs[3];
+T0 = env->mxccregs[3] >> 32;
+}
+#ifdef DEBUG_MXCC
+else
+printf("ERROR: helper_ld_asi(asi = %d, size = %d, sign = %d) 
T0 = %08x: unsupported size\n", asi, size, sign, T0);
+#endif
+break;
+case 0x01c00a04: /* MXCC control register */
+if (size == 4)
+ret = env->mxccregs[3];
+#ifdef DEBUG_MXCC
+else
+printf("ERROR: helper_ld_asi(asi = %d, size = %d, sign = %d) 
T0 = %08x: unsupported size\n", asi, size, sign, T0);
+#endif
+break;
+case 0x01c00f00: /* MBus port address register */
+if (size == 8) {
+ret = env->mxccregs[7];
+T0 = env->mxccregs[7] >> 32;
+}
+#ifdef DEBUG_MXCC
+else
+printf("ERROR: helper_ld_asi(asi = %d, size = %d, sign = %d) 
T0 = %08x: unsupported size\n", asi, size, sign, T0);
+#endif
+break;
+default:
+#ifdef DEBUG_MXCC
+pri

Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]

[J. Mayer]

On Sat, 2007-10-13 at 20:07 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > My idea of always using the ldx_code_p function is that we may have the
> > > occasion to make it more cleaver and make the slow case handle code
> > > execution in mmio areas, when it will be possible.
> > 
> > Here's an updated patch. I added a definition TARGET_HAS_VLE_INSNS which
> > is defined is the cris, i386, m68k and ppcemb cases. Arm already has an
> > explicit support for 32 bits thumb instructions spanning 2 pages, so it
> > should not need this define. When this define is not set, the
> > ldxxx_code_p function just does ldxxx_raw(phys_pc) in the softmmu case
> > and ldxxx_raw(pc) in the user-mode only case. This is optimal for pure
> > RISC architectures and does not need the #ifdef CONFIG_USER_ONLY you
> > added for Sparc in your patch version. I also added a provision for a
> > TARGET_MMIO_CODE define which may be used later when this will really be
> > supported by Qemu.
> > I also took your fixes for Sparc phys_pc computation, but reversed your
> > patch to use ldl_raw as it should not be needed anymore.
> > I did test PowerPC in user-mode only and softmmu mode and i386 in
> > softmmu successfully using this new version of the patch.
> 
> Works ok for MIPS. There's no obvious change in performance, I guess
> the slow TLB emulation drowns out any possible improvement.

Great !
Yes, the optimisation we got here is more a 'don't waste our time doing
unneeded things' than a great performance boost. Running a long test
program in linux user mode seems to indicate it spend a little less time
in user-mode when the patch is applied, but this is not very significant
compared to the total time spent in execution. Maybe gprof would show us
if we really spend less time in the translation process...

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

Re: [Qemu-devel] RFC: cleanups: CPU_MEM_INDEX

[J. Mayer]

On Fri, 2007-10-12 at 09:01 +0200, J. Mayer wrote:
> On Thu, 2007-10-11 at 14:09 +0200, J. Mayer wrote:
> > On Wed, 2007-10-10 at 07:06 +0200, J. Mayer wrote:
> > > On Wed, 2007-10-10 at 01:12 +0100, Thiemo Seufer wrote:
> > > > J. Mayer wrote:
> > > > > Here's a proposal to add a int cpu_mem_index (CPUState *env) function 
> > > > > in
> > > > > targets cpu.h header.
> > > > > The idea of this patch is:
> > > > > - avoid many #ifdef TARGET_xxx in exec-all.h and  softmmu_header.h 
> > > > > then
> > > > > make the code more readable
> > > > > - avoid multiple implementation of the same code (3, in that 
> > > > > particular
> > > > > case) this to avoid potential conflicts if the definition has to be
> > > > > updated for any reason (ie support for new memory access modes,
> > > > > emulation optimisation...)
> > > > > 
> > > > > Please comment.
> > > > > 
> > > > > -- 
> > > > > J. Mayer <[EMAIL PROTECTED]>
> > > > > Never organized
> > > > 
> > 
> > [...]
> > 
> > Here's an updated version of the patch. My comments about it stay valid,
> > with two additions:
> > 1/ when is user is needed to maintain compatibility with existing code,
> > I now define it as:
> > int is_user = mmu_idx == MMU_USER_IDX;
> > instead of just is_user = mmu_idx.
> > This definition will then remain correct even if the definition of the
> > MMU modes are later changed for a specific target
> > 2/ I now precompute the mmu_idx on PowerPC platform as it can never
> > change inside a single TB. This may save a few instructions for every
> > memory access. I guess the same optimisation can be made for the other
> > targets, but not knowing exactly when it would have to be recomputed,
> > for most targets, I prefer not to do this optimisation myself.
> 
> Here's another update, taking care of the commit I just made (which
> changes some of the target-xxx/cpu.h files).
> It also fixes an issue in softmmu_header; this was missing:
> 
>  #if (DATA_SIZE <= 4) && (TARGET_LONG_BITS == 32) && defined(__i386__)
> && \
> -(ACCESS_TYPE <= 1) && defined(ASM_SOFTMMU)
> +(ACCESS_TYPE < NB_MMU_MODES) && defined(ASM_SOFTMMU)
>  
>  #define CPU_TLB_ENTRY_BITS 4
>  
> As this affects only the i386 target which is defined with 2 MMU modes,
> the miss had no run-time consequence but was still a bug.
>  
> > > > I presume cpu_mem_index is supposed to do more than checking for
> > > > usermode. In that case, is_user should get renamed, and the
> > > > cpu_mem_index implementation of some (most?) CPUs should have a
> > > > FIXME comment as reminder to implement the missing MMU modes.
> > > 
> > > You're right, calling this variable is_user is only valid because this
> > > code supposes it knows what cpu_mem_index means. For targets with more
> > > than 2 modes of execution, this is not correct.
> > > My first idea was to try not to change the code too much. After thinking
> > > more about the problem, it appears to me that:
> > > 1/ in the softmmu routines, we should do no assumption about the
> > > signification of the memory index
> > > 2/ then, softmmu routines should use an index and all exported
> > > interfaces (ie tlb_fill and handle_mmu_fault) should take an index
> > > instead of is_user as an argument.
> > > 3/ to maintain compatibility with the existing code, I choosed to add a
> > > is_user variable inside most handle_mmu_fault implementation,
> > > initialized with the value of the given index, which is then given to
> > > the target mmu translation routines.
> > > 4/ to ease implementation of targets with more than 2 execution modes, I
> > > choosed to define a per-target NB_MMU_MODES in each target_xxx/cpu.h
> > > (instead of the hack for PowerPC 64 and Alpha that did pre-exist) and
> > > add a local definition of the meaning of each mmu_index index. Then, for
> > > PowerPC, I choosed to use the same convention than I do in translate.c,
> > > which seems more logical to me, then: 0 => user, 1 => supervisor, 2 =>
> > > hypervisor.
> > > 5/ to avoid confusion between the memory index used in the translation
> > > context, which may contain more than the access mode information, and
> > > the one used by the softmmu routines, I choosed to name the one used in
> > > softmmu 'mmu_idx' (the one in target_xxx/translate.c is called mem_idx).
> > > 6/ I choosed to add a constant MMU_USER_IDX which is used in the
> > > user-mode handle_cpu_signal routine, then addressing your first remark.
> > > 
> > > This patch solves a problem I had no solution to until today: how to add
> > > new mmu modes (ie hypervisor for PowerPC 64, supervisor and executive
> > > for Alpha) for some specific targets.
> > > 
> > > The result is a much more invasive patch but the is supposed (!) to;
> > > 1/ do not change the behavior of the current targets implementations
> > > 2/ be less hardcoded, more flexible and extensible for any specific
> > > targets requirements.
> > > As this new version of the patch could deadly break the softmmu mode and
> > > I got no way to

[Qemu-devel] fat rw

[Ricardo Almeida]

Hi,

I've found the fat:rw:dir option for harddrives and want to use it :)
But when I run:

qemu-system-x86_64 -kernel-kqemu -m 256 -hda winxp.qcow -hdb
fat:rw:/media/lacie/

I get:

qemu: could not open hard disk image 'fat:rw:/media/lacie/'

I've seen in qemu forums
(http://qemu-forum.ipi.fi/viewtopic.php?p=12250) someone with a
similar problem and the following solution:

[QUOTE]
 I am not sure this the correct solution, and I have no idea of what I
am doing, but by changing the bdrv_create call in enable_write_target
to:


  Code: 

 if (bdrv_create(&bdrv_qcow,
   s->qcow_filename, s->sector_count, NULL, 0) < 0)


 This causes QEMU to start correctly and writes to the virtual disk
work correctly.
[/QUOTE]

I'm using Kubuntu Gutsy with QEmu 0.9.0 from repository package with
kqemu_1.3.0pre11, so "I can't" patch QEmu. I would like to know if
this is already fixed on CVS or what's the current status.

Regards,
Ricardo Almeida

Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

[Thiemo Seufer]

J. Mayer wrote:
> On Sat, 2007-10-13 at 16:17 +0200, J. Mayer wrote:
> > On Sat, 2007-10-13 at 16:07 +0300, Blue Swirl wrote:
> > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > On Sat, 2007-10-13 at 13:47 +0300, Blue Swirl wrote:
> > > > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > > The problem:
> > > > > > some CPU architectures, namely PowerPC and maybe others, offers
> > > > > > facilities to access the memory or I/O in the reverse endianness, ie
> > > > > > little-endian instead of big-endian for PowerPC, or provide 
> > > > > > instruction
> > > > > > to make memory accesses in the "reverse-endian". This is 
> > > > > > implemented as
> > > > > > a global flag on some CPU. This case is already handled by the 
> > > > > > PowerPC
> > > > > > emulation but is is far from being optimal. Some other 
> > > > > > implementations
> > > > > > allow the OS to store an "reverse-endian" flag in the TLB or the 
> > > > > > segment
> > > > > > descriptors, thus providing per-page or per-segment endianness 
> > > > > > control.
> > > > > > This is mostly used to ease driver migration from a PC platform to
> > > > > > PowerPC without taking any care of the device endianness in the 
> > > > > > driver
> > > > > > code (yes, this is bad...).
> > > > >
> > > > > Nice, this may be useful for Sparc64. It has a global CPU flag for
> > > > > endianness, individual pages can be marked as reverse endian, and
> > > > > finally there are instructions that access memory in reverse endian.
> > > > > The end result is a XOR of all these reverses. Though I don't know if
> > > > > any of these features are used at all.
> > > >
> > > > I realized that I/O accesses for reverse-endian pages were not correct
> > > > in the softmmu_template.h header. This new version fixes this. It also
> > > > remove duplicated code in the case of unaligned accesses in a
> > > > reverse-endian page.
> > > 
> > > I think 64 bit access case is not handled correctly, but to solve that
> > > it would be nice to extend the current IO access system to 64 bits.
> > 
> > I think that if it was previously correct, it should still be, but... I
> > don't know how much having 64 bits I/O accesses is interresting, as I
> > don't know if there are real hw buses that have 64 bits data path...
> > 
> > Here's another version taking care of your remark about ldl memory
> > accessors.
> > * I replaced all ldl occurences with ldul
> > * when TARGET_LONG_BITS == 64, I also added ldsl accessors. And I
> > started using it in the PowerPC memory access micro-ops.
> > Then the patch is really more invasive than the previous ones.
> > This still does not break PowerPC or i386 target, as it seems.
> 
> Here's a new version. The only change is that, for consistency, I did
> add the big-endian and little-endian accessors that were documented in
> cpu-all.h as unimplemented. The implementation is quite trivial, having
> native and reverse-endian accessors available, and changes functionnally
> nothing to the previous version.

The previous version works fine here, FWIW.


Thiemo

Re: [Qemu-devel] RFC: cleanups: CPU_MEM_INDEX

[Thiemo Seufer]

J. Mayer wrote:
[snip]
> > > > > Other than that it looks good to me (and reminds me to check what the
> > > > > supervisor mode on MIPS actually does now :-).
> > > > 
> > > > This updated patch gives the opportunity to define a per-target semantic
> > > > of the mmu_idx... Time to check what it means in actual CPU
> > > > implementation  ;-)
> > > > 
> > > > Thanks in advance for any comments or improvment suggestions
> 
> What about this proposal ?
> Any remarks, bugs, ... ?
> I'd really like to apply it and go on working on some other
> improvments...

Please commit.

> And I'd like to commit my provision code for hypervisor mode for PowerPC
> and the 4 running modes for Alpha, which depend on this one.
> (the patch is still the same than the last one I did post here).


Thiemo

Re: [Qemu-devel] QEMU keyboard issue with Gujin-2.2

[WaxDragon]

On 10/11/07, Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>  Hello,
>
>  I did more search on the keyboard problem, just posted on the forum
> but here seems to be a better place:
>

  This may not be the same issue, but I've seen strange behaviour
also.  ReactOS has a built in kernel debugger that seems to have a
problem with the mouse input.  If the mouse is "grabbed" by the QEMU
SDL window, and you are in the kernel debugger, moving the mouse will
generate "garbage" charaters, usually rendering the debugger useless.
Real hardware, VMWare, and QEMU *without* the mouse grabbed do not
exhibit this behaviour.
  QEMU has acted this way for quite some time, seems forever.  I've
mentioned it on #qemu to little interest, but since it's not a huge
issue for me, I've not looked into a great deal. Thought I would
mention it.

WaxDragon

-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!