Re: [Qemu-devel] qemu/hw piix_pci.c

[Avi Kivity]

Thiemo Seufer wrote:

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer07/10/20 20:36:52

Modified files:
	hw : piix_pci.c 


Log message:
Enable ACPI interrupts, by Igor Lvovsky.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/piix_pci.c?cvsroot=qemu&r1=1.11&r2=1.12

  


IMO this is a bug.  The patch enables the ACPI PCI interrupt every time 
it is asserted.  If this is really needed, this implies that the guest 
OS detects some sort of inconsistency and keeps turning the ACPI 
interrupt off.


The bug should be addressed instead of worked-around in this way.


--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] qemu alpha?

[J. Mayer]

On Sat, 2007-10-20 at 13:49 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > 
> > On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> > > On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > > > On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> > > > > Hi list!
> > > >
> > > > Hi you !
> > > >
> > > > > Just wanted to know how far the progress on alpha target is? I would 
> > > > > be
> > > > > happy if I have some 'virtual alpha' to test new isos.
> > > > >
> > > > > If I can help some way (I have a few alphas around). Let me know.
> > > >
> > > > I'm happy to see someone interresting in improving Alpha support, which
> > > > is  very alpha for now !
> > > 
> > > I'm interested in testing Alpha too, but I haven't seem a 
> > > qemu-system-alpha 
> > > show up yet.  Alas, I have no hardware or specific expertise in this 
> > > platform, I'm just trying to build and boot Linux kernels (and 
> > > corresponding 
> > > root filesystems) on as many emulated target platforms as I can.
> > 
> > There are a lot of things missing for qemu-system-alpha to be available:
> > - the PALCode emulation is far from being complete or even usable
> > - there is no hardware machine emulation for Alpha in Qemu.
> > As I have no Alpha platform, I don't know much about the hardware to be
> > emulated.
> > But the first step about the Alpha target would be to properly debug the
> > linux-user-mode emulation, that would validate the core CPU INSNS
> > emulation part.
> > I guess my Alpha CPU and ABI knowledge is too restricted to find the
> > problem of most program crashing for now. It seems to me that the Unique
> > register is not initialized properly, but this is just a guess and I
> > have no idea of what's going wrong with this register and what should be
> > its value.
> 
> Could you record the limitations you know about in a STATUS file and
> commit that to the target-alpha directory?

You're right. I will commit a status file today.

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sat, 2007-10-20 at 23:49 +0200, Aurelien Jarno wrote:
> Aurelien Jarno a écrit :
> > Aurelien Jarno a écrit :
> >> Aurelien Jarno a écrit :
> >>
> >>> I have used QEMU CVS with a Debian Sid image. It basically works, I am
> >>> even able to login via SSH, but I have noticed two problems:
> >>>
> >>> - Some process hang, stay into "D" state and become unkillable. It seems
> >>>   it can happen to all processes, but it is always reproducible with
> >>>   uptime or top. I still don't know if it is a problem of the kernel or
> >>>   if it comes from the emulation.
> >> This problem arise when using floating point instructions. It can be
> >> easily triggered by running the following testcase:
> >>
> >> #include 
> >>
> >> int main()
> >> {
> >> double a = 1.34;
> >> printf("%.2f", a);
> >> return 0;
> >> }
> >>
> > 
> > This is actually not enough to trigger the bug. The testcase works if
> > the bug has already been trigger in another process before, for example
> > uptime.
> > 
> 
> I finally found a testcase that trigger the bug in any case:
> 
> #include 
> 
> int main()
> {
>   printf("%d %f\n", 7, 0.40);
>   return 0;
> }
> 
> The bug could also be trigger with sprintf(), so this is not directly
> related to I/O. It happens when printing an integer followed by a float,
> even when the two are printed in two different calls to printf().

OK, thanks. I'll do test with this program. It seems that floats are OK
when running 2.4 kernels, it maybe a difference in recent glibc. I'll
try to investigate more about it.

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

[Qemu-devel] qemu/target-alpha STATUS

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/21 09:46:04

Added files:
target-alpha   : STATUS 

Log message:
New status file for Alpha emulation target.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/STATUS?cvsroot=qemu&rev=1.1

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
> Sleep mode is currently implemented only for a few CPUs. I should add
> all the currently emulated cores. For this, I would have to emulate the
> HID registers, in most case, which is still not done.

Getting it to exit in response to a shut down attempt would be really nice 
too.  (It may already do so, but I have no idea how to trigger it and neither 
did Milton last I checked.)

> And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> switch.

I did that, but it -cpu ? gives output like:

  PowerPC 7448 PVR 80040201
  PowerPC 7448v1.0 PVR 80040100
  PowerPC 7448v1.1 PVR 80040101
  PowerPC 7448v2.0 PVR 80040200
  PowerPC 7448v2.1 PVR 80040201

I prefer the result of "-M ?" which makes it slightly clearer which field you 
need to feed qemu as an argument.  (For the record, -cpu seems to want filed 
$2 of the -cpu ? output.)  Also, that doesn't tell me what the differences 
between any of them are.

From earlier research, I know that if you configure a toolchain for "7xx" all 
major PowerPC variants except two will run that, it's more or less "-mcpu 
386" of the powerpc world.

The two that won't run it (Motorola's 8xx and IBM's 4xx) are both embedded 
subsets of powerpc that have had instructions removed, and thus need their 
own toolchains.  (Of course those two removed DIFFERENT instructions, 
sigh...)

My random and confused notes about various hardware platforms are 
at "http://landley.net/ols/ols2007/platforms.txt";, which has a largeish 
section on ppc that probably makes sense to nobody but me. :)

I don't actually have any _background_ in embedded hardware.  Busybox, uClibc, 
and qemu all dragged me into it, and I've been trying to pick things up as I 
go along...

Rob

P.S.  I removed you from the CC: list because your ISP is still bouncing my 
emails as spam, and I don't know if the list sends you a copy if you're cc'd.
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] qemu alpha?

[Rob Landley]

On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
> On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> > On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > > On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> > > > Hi list!
> > >
> > > Hi you !
> > >
> > > > Just wanted to know how far the progress on alpha target is? I would
> > > > be happy if I have some 'virtual alpha' to test new isos.
> > > >
> > > > If I can help some way (I have a few alphas around). Let me know.
> > >
> > > I'm happy to see someone interresting in improving Alpha support, which
> > > is  very alpha for now !
> >
> > I'm interested in testing Alpha too, but I haven't seem a
> > qemu-system-alpha show up yet.  Alas, I have no hardware or specific
> > expertise in this platform, I'm just trying to build and boot Linux
> > kernels (and corresponding root filesystems) on as many emulated target
> > platforms as I can.
>
> There are a lot of things missing for qemu-system-alpha to be available:
> - the PALCode emulation is far from being complete or even usable

I have no idea what that is.

> - there is no hardware machine emulation for Alpha in Qemu.
> As I have no Alpha platform, I don't know much about the hardware to be
> emulated.

I do know that the ev6 bus is the same as the Athlon used.

When Compaq bought the corpse of DEC back in the mid-90's, they weren't 
interested in their chip designers, so AMD scooped up most of the Alpha 
design team.  AMD then asked them "ok, if you guys were going to design an 
x86 compatible processor, what would it look like?"  The result was the 
Athlon back around 1997.  You could actually stick one in an Alpha 
motherboard, and the only reason it wouldn't boot is the bios was alpha 
machine language instead of x86 code.  Everything else was the same, because 
it's what the designers were familiar with.

So if you slap an Alpha in a virtual x86-64 PC motherboard, you're not too far 
off.

Here's one spec:
http://web.archive.org/web/19990913123756/http://www.unix-ag.org/Linux-Alpha/Architectures/LX164.html

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] qemu alpha?

[Paul Brook]

> > - there is no hardware machine emulation for Alpha in Qemu.
> > As I have no Alpha platform, I don't know much about the hardware to be
> > emulated.
>
> I do know that the ev6 bus is the same as the Athlon used.

The CPU bus is pretty much irelevant. It's almost entirely transparent from a 
software/emulation PoV.

IIUC some of the alpha machines did use fairly standard PC-style peripherals 
though.

Paul

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sun, 2007-10-21 at 04:55 -0500, Rob Landley wrote:
> On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
> > Sleep mode is currently implemented only for a few CPUs. I should add
> > all the currently emulated cores. For this, I would have to emulate the
> > HID registers, in most case, which is still not done.
> 
> Getting it to exit in response to a shut down attempt would be really nice 
> too.  (It may already do so, but I have no idea how to trigger it and neither 
> did Milton last I checked.)

Well, if it does not exit, that means that there should be something
emulated in the chipset to do so and that the Linux kernel just enter an
infinite loop instead of shuting down / reseting the board.

> > And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> > switch.
> 
> I did that, but it -cpu ? gives output like:
> 
>   PowerPC 7448 PVR 80040201
>   PowerPC 7448v1.0 PVR 80040100
>   PowerPC 7448v1.1 PVR 80040101
>   PowerPC 7448v2.0 PVR 80040200
>   PowerPC 7448v2.1 PVR 80040201
> 
> I prefer the result of "-M ?" which makes it slightly clearer which field you 
> need to feed qemu as an argument.  (For the record, -cpu seems to want filed 
> $2 of the -cpu ? output.)  Also, that doesn't tell me what the differences 
> between any of them are.

The idea of showing the name of the model and the PVR (processor version
register) is that it can be useful to give Qemu a PVR instead of a name,
even if this possibility is not properly implemented in the commited
version. It's sometime more relevant to provide a PVR than a core name,
imho...
I will put a dump of the CPU features for all cores emulated by Qemu on
line soon.

> >From earlier research, I know that if you configure a toolchain for "7xx" 
> >all 
> major PowerPC variants except two will run that, it's more or less "-mcpu 
> 386" of the powerpc world.
>
> The two that won't run it (Motorola's 8xx and IBM's 4xx) are both embedded 
> subsets of powerpc that have had instructions removed, and thus need their 
> own toolchains.  (Of course those two removed DIFFERENT instructions, 
> sigh...)

Those two ones do not have any hardware floating point implemented and
lack the support of some optional instructions. If you want to compile
executables that would run on any PowerPC core, you have to use the
switch '-many' or '-mcom'. This is supposed to generate code that would
even run on the original RS/6000 architecture. The '-mppc' generates
code for 603/604 which should be a better PowerPC insns subset than the
750 one, for portability. If you want all programs to also run on
4xx/8xx/82xx, you may also add '-msoft-float' so no hardware floating
point instructions will be used.
But you may not care about those cores as they are used only in
microcontrollers so I need to implement at least a subset of their
internal devices to make them usable in the full-system emulation.

> My random and confused notes about various hardware platforms are 
> at "http://landley.net/ols/ols2007/platforms.txt";, which has a largeish 
> section on ppc that probably makes sense to nobody but me. :)
> 
> I don't actually have any _background_ in embedded hardware.  Busybox, 
> uClibc, 
> and qemu all dragged me into it, and I've been trying to pick things up as I 
> go along...
> 
> Rob
> 
> P.S.  I removed you from the CC: list because your ISP is still bouncing my 
> emails as spam, and I don't know if the list sends you a copy if you're cc'd.

Strange, my ISP does not tag your mails as spams, when I receive them.
But it's not a problem for me not to be CCed...

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

Re: [Qemu-devel] qemu alpha?

[J. Mayer]

On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote:
> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
> > On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> > > On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > > > On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> > > > > Hi list!
> > > >
> > > > Hi you !
> > > >
> > > > > Just wanted to know how far the progress on alpha target is? I would
> > > > > be happy if I have some 'virtual alpha' to test new isos.
> > > > >
> > > > > If I can help some way (I have a few alphas around). Let me know.
> > > >
> > > > I'm happy to see someone interresting in improving Alpha support, which
> > > > is  very alpha for now !
> > >
> > > I'm interested in testing Alpha too, but I haven't seem a
> > > qemu-system-alpha show up yet.  Alas, I have no hardware or specific
> > > expertise in this platform, I'm just trying to build and boot Linux
> > > kernels (and corresponding root filesystems) on as many emulated target
> > > platforms as I can.
> >
> > There are a lot of things missing for qemu-system-alpha to be available:
> > - the PALCode emulation is far from being complete or even usable
> 
> I have no idea what that is.

The PALCode is mainly equivalent to the microcode of most CPU
architectures. What is different to microcode is that is uses only
regular Alpha instructions, just adding 4 instructions to access special
"hardware registers" and access the memory with different priviledge
levels. Another main idea is that everyone can write its own PALCode
image and switch to it at run-time. Then, for example, the PALCode ABI
is not the same one if you run Linux or Windows NT. The PALCode handles
all complex operations. For example, the CPU provides only TLB and the
MMU tables search is actually implemented in software, in the PALCode.
This greatly simplifies the CPU design and allows a high level of
flexibility. And if your OS need a specific ABI for example to handle
CPU exception, you define your ABI, write the PALCode using Alpha insns
and use it ! The Alpha CPU also provide an instruction to do PALCode
calls from the OS or applications.
There are 3 (4 ?) "native" PALCode ABIs documented in the Alpha CPUs
specifications then those can be emulated at the host side in Qemu. It
is in fact needed to emulate a subset of the PALCode even to run
user-mode programs.

[...]

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sun, 2007-10-21 at 12:24 +0200, J. Mayer wrote:
> On Sun, 2007-10-21 at 04:55 -0500, Rob Landley wrote:
> > On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
[...]
> > > And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> > > switch.
> > 
> > I did that, but it -cpu ? gives output like:
> > 
> >   PowerPC 7448 PVR 80040201
> >   PowerPC 7448v1.0 PVR 80040100
> >   PowerPC 7448v1.1 PVR 80040101
> >   PowerPC 7448v2.0 PVR 80040200
> >   PowerPC 7448v2.1 PVR 80040201
> > 
> > I prefer the result of "-M ?" which makes it slightly clearer which field 
> > you 
> > need to feed qemu as an argument.  (For the record, -cpu seems to want 
> > filed 
> > $2 of the -cpu ? output.)  Also, that doesn't tell me what the differences 
> > between any of them are.
> 
> The idea of showing the name of the model and the PVR (processor version
> register) is that it can be useful to give Qemu a PVR instead of a name,
> even if this possibility is not properly implemented in the commited
> version. It's sometime more relevant to provide a PVR than a core name,
> imho...

Something I forgot to say is that this output is supposed to give a help
to the end-user. It seems to me that showing the CPU family (ie PowerPC)
can be useful when POWER and RS64 families will be emulated too, in
order to help the user choose which CPU to emulate.

> I will put a dump of the CPU features for all cores emulated by Qemu on
> line soon.

Here you'll find a reference for all PowerPC CPUs / cores /
microcontrollers available with the Qemu -cpu switch. Hope I did not
forget anything.

For each CPU, you get:
- its name, as provided with the Qemu -cpu switch
- its PVR (processor version register)
- the bits defined in the MSR (machine state register)
- its MMU model and the TLB model when relevant
- its exception handling model
- its input bus model
- the specific features provided by the MSR
- its complete instructions set (only one insn is dumped when 2
instructions share the same opcode)
- the complete list of SPRs (special purpose registers) with access
rights in supervisor and user mode

[...]

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

[Qemu-devel] qemu/hw ppc_prep.c

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/21 12:29:36

Modified files:
hw : ppc_prep.c 

Log message:
Allow use of PCI NICs on PowerPC PreP platform.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.45&r2=1.46

[Qemu-devel] qemu/hw ppc_prep.c

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/21 15:53:01

Modified files:
hw : ppc_prep.c 

Log message:
Bugfix: now PCI NICs really work on PowerPC PreP platform.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.46&r2=1.47

Re: [Qemu-devel] qemu/hw piix_pci.c

[Thiemo Seufer]

Avi Kivity wrote:
>> Modified files:
>>  hw : piix_pci.c 
>> Log message:
>>  Enable ACPI interrupts, by Igor Lvovsky.
>>
>> CVSWeb URLs:
>> http://cvs.savannah.gnu.org/viewcvs/qemu/hw/piix_pci.c?cvsroot=qemu&r1=1.11&r2=1.12
>>
>>   
>
> IMO this is a bug.  The patch enables the ACPI PCI interrupt every time it 
> is asserted.  If this is really needed, this implies that the guest OS 
> detects some sort of inconsistency and keeps turning the ACPI interrupt 
> off.
>
> The bug should be addressed instead of worked-around in this way.

Igor, could you clarify what happens there?


Thiemo

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

On Sunday 21 October 2007 5:24:34 am J. Mayer wrote:
> > P.S.  I removed you from the CC: list because your ISP is still bouncing
> > my emails as spam, and I don't know if the list sends you a copy if
> > you're cc'd.
>
> Strange, my ISP does not tag your mails as spams, when I receive them.

If you receive them, they're not tagged as spam.  They _bounce_ as spam, 
before you ever see them.  (See attachment.)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
Return-Path: <>
X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on 
dell.linuxdev.us.dell.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_RELAYS 
autolearn=ham version=3.1.7-deb
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: by grelber.thyrsus.com (Postfix)
id A220973947; Sun, 21 Oct 2007 09:29:32 -0400 (EDT)
Date: Sun, 21 Oct 2007 09:29:32 -0400 (EDT)
From: [EMAIL PROTECTED] (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: [EMAIL PROTECTED]
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report;
  report-type=delivery-status;
  boundary="3554073945.1192973372/grelber.thyrsus.com"
Content-Transfer-Encoding: 8bit
Message-Id: <[EMAIL PROTECTED]>

This is a MIME-encapsulated message.

--3554073945.1192973372/grelber.thyrsus.com
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

This is the mail system at host grelber.thyrsus.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

<[EMAIL PROTECTED]>: host mxs.magic.fr[62.210.158.52] said: 550 5.0.0 SPAM! (in
reply to MAIL FROM command)

--3554073945.1192973372/grelber.thyrsus.com
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; grelber.thyrsus.com
X-Postfix-Queue-ID: 3554073945
X-Postfix-Sender: rfc822; [EMAIL PROTECTED]
Arrival-Date: Sun, 21 Oct 2007 09:29:31 -0400 (EDT)

Final-Recipient: rfc822; [EMAIL PROTECTED]
Original-Recipient: rfc822;[EMAIL PROTECTED]
Action: failed
Status: 5.0.0
Remote-MTA: dns; mxs.magic.fr
Diagnostic-Code: smtp; 550 5.0.0 SPAM!

--3554073945.1192973372/grelber.thyrsus.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Received: from landley.net (localhost [127.0.0.1])
by grelber.thyrsus.com (Postfix) with ESMTP id 3554073945
for <[EMAIL PROTECTED]>; Sun, 21 Oct 2007 09:29:31 -0400 (EDT)
From: Rob Landley <[EMAIL PROTECTED]>
Organization: Boundaries Unlimited
To: "J. Mayer" <[EMAIL PROTECTED]>
Subject: Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !
Date: Sun, 21 Oct 2007 08:26:36 -0500
User-Agent: KMail/1.9.6
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[EMAIL PROTECTED]>

On Sunday 21 October 2007 5:24:34 am you wrote:
> Strange, my ISP does not tag your mails as spams, when I receive them.
> But it's not a problem for me not to be CCed...

Huh, did that get fixed recently?

Testing...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

--3554073945.1192973372/grelber.thyrsus.com--

[Qemu-devel] qemu vl.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/21 23:20:46

Modified files:
.  : vl.c 

Log message:
Support tap down script, by Wolfram Gloger.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.349&r2=1.350

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

[Thiemo Seufer]

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.

Leads to an instant segfault for the i386 usermode emulation.


Thiemo