Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

2011-04-21 Thread Brian Wheeler 
On Thu, 2011-04-21 at 15:43 +0200, Tristan Gingold wrote:
> On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote:
> 
> > On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote:
> >> On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote:
> >> 
> >>> On 04/20/2011 08:46 AM, Tristan Gingold wrote:
> >>>> Right, but you could create an ev67 machine with a single PCI
> >>>> controller (or put all the devices on the same PCI controller).
> >>> 
> >>> Even the lowly ds10 has two hoses.
> >>> 
> >>> I'll admit I hadn't considered engineering the second hose to
> >>> be "present" but always appear empty.  It's something to consider.
> >>> 
> >>>> Ah, ok I understand.  I fear that if you implement your own ISR, you 
> >>>> will only be able to boot linux...
> >>>> which I suppose is your primary target.  OTOH, it will be much faster 
> >>>> than a native ISR.
> >>> 
> >>> Yes, Linux is the primary goal.
> >>> 
> >>> But I suspect that if I implemented enough of CALL_PAL CSERVE,
> >>> you could boot Tru64, or at least one of the BSDs.
> >> 
> >> BSD should be doable, but I doubt for Tru64.  Do you have technical doc 
> >> about the SRM ?
> >> IIRC, the SRM uses its own palcode and SRM specific pal calls.
> >> 
> > 
> > The palcode with milo was a subset of the tru64 palcode, I think.
> > Looking at the arch reference manual and assuming that the calls take
> > the same parameters, the only difference is that tru64 has "urti -
> > return from user mode trap" and linux doesn't.
> 
> Yes, Linux runs on Tru64 palcode.  But the issue is booting the Tru64 kernel.
> 
> Tristan.
> 

Ah, gotcha.  It almost seems like the console could actually be
implemented in qemu itself, rather than a guest side thing, as long as
it looks like part III of the ARM :)  It might simplify things quite a
bit:  the console callbacks look like they can be translated into qemu
calls and the bootstrapping looks like its a read block zero of selected
device + other blocks specified, setup hwrpb and start emulation.  It
looks like its standard across all OSes, with the possible exception of
NT.

*shrug* I'm just an innocent bystander, though.

Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

2011-04-21 Thread Brian Wheeler 
On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote:
> On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote:
> 
> > On 04/20/2011 08:46 AM, Tristan Gingold wrote:
> >> Right, but you could create an ev67 machine with a single PCI
> >> controller (or put all the devices on the same PCI controller).
> > 
> > Even the lowly ds10 has two hoses.
> > 
> > I'll admit I hadn't considered engineering the second hose to
> > be "present" but always appear empty.  It's something to consider.
> > 
> >> Ah, ok I understand.  I fear that if you implement your own ISR, you will 
> >> only be able to boot linux...
> >> which I suppose is your primary target.  OTOH, it will be much faster than 
> >> a native ISR.
> > 
> > Yes, Linux is the primary goal.
> > 
> > But I suspect that if I implemented enough of CALL_PAL CSERVE,
> > you could boot Tru64, or at least one of the BSDs.
> 
> BSD should be doable, but I doubt for Tru64.  Do you have technical doc about 
> the SRM ?
> IIRC, the SRM uses its own palcode and SRM specific pal calls.
> 

The palcode with milo was a subset of the tru64 palcode, I think.
Looking at the arch reference manual and assuming that the calls take
the same parameters, the only difference is that tru64 has "urti -
return from user mode trap" and linux doesn't.

Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

2011-04-20 Thread Brian Wheeler 
I'd like to second Tristan in saying that I'm glad someone is working on
alpha system emulation -- its long overdue!  

Brian

On Wed, 2011-04-20 at 11:06 +0200, Tristan Gingold wrote:
> On Apr 19, 2011, at 5:04 PM, Richard Henderson wrote:
> 
> > Changes from v1 to v2:
> >  - Split patch 5 up into little pieces.  These pieces were compile
> >tested by applying patch 23 (Enable alpha-softmmu) out of sequence
> >so that both softmmu and linux-user targets were built.  But in
> >the end I chickened out and re-ordered the enable patch to last.
> > 
> >  - The TB->FLAGS patch is more comprehensive.  In doing the split I
> >noticed that we were doing funny things with AMASK that really
> >ought to have belonged in the TB in the first place.
> > 
> >  - The patch for unassigned addresses is more comprehensive.  I had
> >previously failed to do the if-deffing dance in the generic part
> >of QEMU.
> > 
> >  - The PALcode source is added as a submodule.
> 
> Richard,
> 
> it looks like I miss the v1.  Anyway, some random comments:
> 
> * thank you for working on that!
> 
> * sx164 is ev56 based, isn't it ?  It would be nice if cpu version specific 
> code is clearly marked.
>   In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to 
> ev5.  Don't know about ev7.
>   It would be nice if we could easily support both ev5 and ev6.
> 
> * Yes, executive and supervisor are used only by VMS (well AFAIK).  I'd like 
> to support it.
>   Did you try to also support the windows mmu mode ?
> 
> * Again, thank you for working on that.
> 
> Tristan.
> 
> 
>

Re: [Qemu-devel] Questions about chardev (and ps/2 mouse)

2011-04-05 Thread Brian Wheeler 
On Tue, 2011-04-05 at 14:55 -0400, Brian Wheeler wrote:
> I'm trying to disable the ps/2 mouse in favor of the serial mouse
> provided by -chardev msmouse since the ps/2 mouse has had lots of
> problems with older OSes (OpenStep, OS/2, Win 3.1, etc).  I've got a
> couple of questions:
> 
> 1) If I change a VMState something by appending a field (i.e.
> "unplugged"), do I have to update version_id?  How do the
> minimum_version_id{,_old} fields fit in?
> 
> 2) I've had to hardcode the unplugged value in ps2_mouse_reset since the
> call is pretty deep in the call stack, 8042->pckbd->ps2.  Ideally, I'd
> like to set (*PS2MouseState)->unplugged from qemu_chr_open_msmouse() so
> that if the serial mouse is set up the ps/2 mouse would be disabled.
> 
> 3) When I enable the msmouse (via -chardev msmouse,id=mouse) qemu
> segfaults.  I've traced it back to the CharDriverSTate for msmouse not
> having a valid handler_opaque (it is null).  How would I connect that to
> the serial port (any of them, but ideally the 2nd one)
> 

Ignore the last question.  I realized I had to use:

-chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse

to connect them :)



> Thanks for any hints!
> Brian
> 
>

[Qemu-devel] Questions about chardev (and ps/2 mouse)

2011-04-05 Thread Brian Wheeler 
I'm trying to disable the ps/2 mouse in favor of the serial mouse
provided by -chardev msmouse since the ps/2 mouse has had lots of
problems with older OSes (OpenStep, OS/2, Win 3.1, etc).  I've got a
couple of questions:

1) If I change a VMState something by appending a field (i.e.
"unplugged"), do I have to update version_id?  How do the
minimum_version_id{,_old} fields fit in?

2) I've had to hardcode the unplugged value in ps2_mouse_reset since the
call is pretty deep in the call stack, 8042->pckbd->ps2.  Ideally, I'd
like to set (*PS2MouseState)->unplugged from qemu_chr_open_msmouse() so
that if the serial mouse is set up the ps/2 mouse would be disabled.

3) When I enable the msmouse (via -chardev msmouse,id=mouse) qemu
segfaults.  I've traced it back to the CharDriverSTate for msmouse not
having a valid handler_opaque (it is null).  How would I connect that to
the serial port (any of them, but ideally the 2nd one)

Thanks for any hints!
Brian

Re: [Qemu-devel] Help Debugging AIX boot on qemu-system-ppc (it reads bootfile.exe now)

2011-04-04 Thread Brian Wheeler 
Booting AIX 5.2 gives me 

---
Welcome to AIX.
   boot image timestamp: 70:80 15/C0
 The current time and date: 20:40:45 04/04/2011
number of processors: 1size of memory: 2047Mb
boot device: cd:\ppc\chrp\bootfile.exe
Validation failed: the "/rtas" device node does not exist.
EXIT


So at least for earlier versions of AIX there are still missing firmware
bits.

Brian


On Mon, 2011-04-04 at 13:28 -0700, Kenneth Salerno wrote:
> --- On Mon, 04 Apr 2011 08:59:37 -0400, Brian Wheeler wrote:
> 
> > Out of curiosity, what command line did you use for this?
> 
> ./qemu/ppc-softmmu/qemu-system-ppc \
>   -net none \
>   -m 2047 \
>   -nographic \
>   -bios ./qemu/pc-bios/openbios-ppc \
>   -hda aix.img \
>   -cdrom ibmvios.iso \
>   -boot d \
>   -rtc base=localtime,clock=host \
>   -uuid xx...
>   -monitor tcp:127.0.0.1:9979,server,nowait \
>   -serial tcp:127.0.0.1:9980,server,nowait \
>   -d in_asm,out_asm,op,op_opt
> 
>

Re: [Qemu-devel] Help Debugging AIX boot on qemu-system-ppc (it reads bootfile.exe now)

2011-04-04 Thread Brian Wheeler 
Out of curiosity, what command line did you use for this?

On Sat, 2011-04-02 at 20:09 -0700, Kenneth Salerno wrote:
> Hi,
> 
> I have been using QEMU for a few years and periodically tested AIX V6.1 with 
> qemu-system-ppc and read the various threads in the mailing list knowing not 
> to expect it to work just yet. However, with OpenBIOS v1.0 I was surprised to 
> find how far it gets now. Please see below and I would appreciate any advice 
> on how to debug further:
> 
> >> =
> >> OpenBIOS 1.0 [Jan 30 2011 08:46]
> >> Configuration device id QEMU version 1 machine id 2
> >> CPUs: 1
> >> Memory: 2047M
> >> UUID: 17202d0a-45f8-4159-a8e1-78b866f50aa7
> >> CPU type PowerPC,750
> Welcome to OpenBIOS v1.0 built on Jan 30 2011 08:46
> Trying cd:,\\:tbxi...
> Trying cd:,\ppc\bootinfo.txt...
> 
> 
> 
> ---
>  Welcome to AIX.
>boot image timestamp: 00:39 35/2D
>  The current time and date: 23:00:50 04/02/2011
> processor count: 1;  memory size: 2047MB;  kernel size: 2293829
> boot device: cd:\ppc\chrp\bootfile.exe
> 
> qemu>
> info cpus
> * CPU #0: nip=0xfff0fcdc thread_id=2527
> 
> info registers
> NIP fff0fcec   LR fff0fcc4 CTR fff11558 XER 2000
> MSR 3032 HID0   HF 2000 idx 1
> TB  1542797983 DECR 2752169338
> GPR00 7fb9f0d0 7fcf7790  7fba29e4
> GPR04 fffb403c 00044200 fff02464 00044200
> GPR08  7fba29e4 000c 0820
> GPR12 88ac  fff305f5 fff30dac
> GPR16 fff2f14e 0400 fffb36c4 fffb3ec4
> GPR20 30ec fff2ef4a fff2ef38 fff2eeb8
> GPR24 fff2ef40 fffb3628 00044204 fff8
> GPR28 0036 fffb fffb 7fb9f0d8
> CR 4884  [ G  L  -  -  -  -  L  G  ] RES 
> FPR00    
> FPR04    
> FPR08    
> FPR12    
> FPR16    
> FPR20    
> FPR24    
> FPR28    
> FPSCR 
> SRR0 42c0 SRR1 3032 SDR1 7fd0
> 
> x/20i $pc-10
> 0xfff0fcd2:  fnmadd. f31,f24,f4,f18
> 0xfff0fcd6:  .long 0xfff84800
> 0xfff0fcda:  .long 0x87d23
> 0xfff0fcde:  bla 0xff788120
> 0xfff0fce2:  .long 0x2f89
> 0xfff0fce6:  .long 0x419e
> 0xfff0fcea:  .long 0x148149
> 0xfff0fcee:  .long 0x4817f
> 0xfff0fcf2:  .long 0xfffc7f8a
> 0xfff0fcf6:  rlmir0,r2,r8,6,14
> 0xfff0fcfa:  fnmadd. f31,f4,f4,f18
> 0xfff0fcfe:  .long 0xfff89003
> 0xfff0fd02:  .long 0x3961
> 0xfff0fd06:  .long 0x104801
> 0xfff0fd0a:  ori r24,r11,37921
> 0xfff0fd0e:  .long 0xffe07c08
> 0xfff0fd12:  .long 0x2a6bfa1
> 0xfff0fd16:  .long 0x147c7e
> 0xfff0fd1a:  .long 0x1b799001
> 0xfff0fd1e:  .long 0x247c9d
> 
> last entry from out_asm:
> OUT: [size=256]
> 0x4157ae90:  mov0x100(%r14),%ebp
> 0x4157ae97:  mov0x4(%r14),%ebx
> 0x4157ae9b:  lea-0x10(%rbx),%r12d
> 0x4157ae9f:  mov%ebp,(%r14)
> 0x4157aea2:  mov$0x20,%ebp
> 0x4157aea7:  mov%ebp,0x260(%r14)
> 0x4157aeae:  mov%r12d,%esi
> 0x4157aeb1:  mov%r12d,%edi
> 0x4157aeb4:  shr$0x7,%esi
> 0x4157aeb7:  and$0xf003,%edi
> 0x4157aebd:  and$0x1fe0,%esi
> 0x4157aec3:  lea0x228c(%r14,%rsi,1),%rsi
> 0x4157aecb:  cmp(%rsi),%edi
> 0x4157aecd:  mov%r12d,%edi
> 0x4157aed0:  jne0x4157aede
> 0x4157aed2:  add0xc(%rsi),%rdi
> 0x4157aed6:  mov%ebx,%esi
> 0x4157aed8:  bswap  %esi
> 0x4157aeda:  mov%esi,(%rdi)
> 0x4157aedc:  jmp0x4157aeea
> 0x4157aede:  mov%ebx,%esi
> 0x4157aee0:  mov$0x1,%edx
> 0x4157aee5:  callq  0x57f0f5
> 0x4157aeea:  lea0x14(%r12),%ebp
> 0x4157aeef:  mov(%r14),%ebx
> 0x4157aef2:  mov%r12d,0x4(%r14)
> 0x4157aef6:  mov%ebp,%esi
> 0x4157aef8:  mov%ebp,%edi
> 0x4157aefa:  shr$0x7,%esi
> 0x4157aefd:  and$0xf003,%edi
> 0x4157af03:  and$0x1fe0,%esi
> 0x4157af09:  lea0x228c(%r14,%rsi,1),%rsi
> 0x4157af11:  cmp(%rsi),%edi
> 0x4157af13:  mov%ebp,%edi
> 0x4157af15:  jne0x4157af23
> 0x4157af17:  add0xc(%rsi),%rdi
> 0x4157af1b:  mov%ebx,%esi
> 0x4157af1d:  bswap  %esi
> 0x4157af1f:  mov%esi,(%rdi)
> 0x4157af21:  jmp0x4157af2f
> 0x4157af23:  mov%ebx,%esi
> 0x4157af25:  mov$0x1,%edx
> 0x4157af2a

[Qemu-devel] [PATCH v5] PING: Fix ATA SMART and CHECK POWER MODE

2011-03-01 Thread Brian Wheeler 
This patch fixes two things:
 
 1) CHECK POWER MODE
 
The error return value wasn't always zero, so it would show up as
offline.  Error is now explicitly set to zero.
 
 2) SMART
 
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output.  The data has been fixed up and raw value support
was added.  Tools like skdump and palimpsest work as expected.

v5 changes:  rebase
v4 changes:  incorporate changes from Ryan Harper
v3 changes:  don't reformat code I didn't change
v2 changes:  use single structure instead of one for thresholds and one
for data.

Signed-off-by: bdwhe...@indiana.edu

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 9c91a49..1ffca56 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
 
 #include 
 
-static const int smart_attributes[][5] = {
-/* id,  flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were based on a Seagate ST3500418AS but have been modified
+   to make more sense in QEMU */
+static const int smart_attributes[][12] = {
+/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190,  0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
 };
 
 /* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
 break;
 case WIN_CHECKPOWERMODE1:
 case WIN_CHECKPOWERMODE2:
+s->error = 0;
 s->nsector = 0xff; /* device active or idle */
 s->status = READY_STAT | SEEK_STAT;
 ide_set_irq(s->bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+   s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n<511; n++) /* checksum */
s->io_buffer[511] += s->io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0) {
break;
-   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][1];
-   s->io_buffer[2+3+(n*12)] = smart_attributes[n][2];
-   s->io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+   }
+   int i;
+   for(i = 0; i < 11; i++) {
+   s->io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+   }
}
s->io_buffer[362] = 0x02 | (s->smart_autosave?0x80:0x00);
if (s->smart_selftest_count == 0) {

[Qemu-devel] [PATCH v5] Fix ATA SMART and CHECK POWER MODE

2011-02-21 Thread Brian Wheeler 
This patch fixes two things:
 
 1) CHECK POWER MODE
 
The error return value wasn't always zero, so it would show up as
offline.  Error is now explicitly set to zero.
 
 2) SMART
 
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output.  The data has been fixed up and raw value support
was added.  Tools like skdump and palimpsest work as expected.

v5 changes:  rebase
v4 changes:  incorporate changes from Ryan Harper
v3 changes:  don't reformat code I didn't change
v2 changes:  use single structure instead of one for thresholds and one
for data.

Signed-off-by: bdwhe...@indiana.edu

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 9c91a49..1ffca56 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
 
 #include 
 
-static const int smart_attributes[][5] = {
-/* id,  flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were based on a Seagate ST3500418AS but have been modified
+   to make more sense in QEMU */
+static const int smart_attributes[][12] = {
+/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190,  0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
 };
 
 /* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
 break;
 case WIN_CHECKPOWERMODE1:
 case WIN_CHECKPOWERMODE2:
+s->error = 0;
 s->nsector = 0xff; /* device active or idle */
 s->status = READY_STAT | SEEK_STAT;
 ide_set_irq(s->bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+   s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n<511; n++) /* checksum */
s->io_buffer[511] += s->io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0) {
break;
-   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][1];
-   s->io_buffer[2+3+(n*12)] = smart_attributes[n][2];
-   s->io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+   }
+   int i;
+   for(i = 0; i < 11; i++) {
+   s->io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+   }
}
s->io_buffer[362] = 0x02 | (s->smart_autosave?0x80:0x00);
if (s->smart_selftest_count == 0) {

[Qemu-devel] [PATCH v4] Fix ATA SMART and CHECK POWER MODE

2011-02-10 Thread Brian Wheeler 
This patch fixes two things:
 
 1) CHECK POWER MODE
 
The error return value wasn't always zero, so it would show up as
offline.  Error is now explicitly set to zero.
 
 2) SMART
 
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output.  The data has been fixed up and raw value support
was added.  Tools like skdump and palimpsest work as expected.

v4 changes:  incorporate changes from Ryan Harper
v3 changes:  don't reformat code I didn't change
v2 changes:  use single structure instead of one for thresholds and one
for data.

Signed-off-by: bdwhe...@indiana.edu

diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..c806f31 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
 
 #include 
 
-static const int smart_attributes[][5] = {
-/* id,  flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were based on a Seagate ST3500418AS but have been modified
+   to make more sense in QEMU */
+static const int smart_attributes[][12] = {
+/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190,  0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
 };
 
 /* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
 break;
 case WIN_CHECKPOWERMODE1:
 case WIN_CHECKPOWERMODE2:
+s->error = 0;
 s->nsector = 0xff; /* device active or idle */
 s->status = READY_STAT | SEEK_STAT;
 ide_set_irq(s->bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+   s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n<511; n++) /* checksum */
s->io_buffer[511] += s->io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0) {
break;
-   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][1];
-   s->io_buffer[2+3+(n*12)] = smart_attributes[n][2];
-   s->io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+   }
+   int i;
+   for(i = 0; i < 11; i++) {
+   s->io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+   }
}
s->io_buffer[362] = 0x02 | (s->smart_autosave?0x80:0x00);
if (s->smart_selftest_count == 0) {

Re: [Qemu-devel] [PATCH v3] Fix ATA SMART and CHECK POWER MODE

2011-02-10 Thread Brian Wheeler 
On Wed, 2011-02-09 at 17:22 -0600, Ryan Harper wrote:
> * Brian Wheeler  [2011-02-09 16:13]:
> > This patch fixes two things:
> > 
> >  1) CHECK POWER MODE
> > 
> > The error return value wasn't always zero, so it would show up as
> > offline.  Error is now explicitly set to zero.
> > 
> >  2) SMART
> > 
> > The smart values that were returned were invalid and tools like skdump
> > would not recognize that the smart data was actually valid and would
> > dump weird output.  The data has been fixed up and raw value support
> > was added.  Tools like skdump and palimpsest work as expected.
> > 
> > v3 changes:  don't reformat code I didn't change
> > v2 changes:  use single structure instead of one for thresholds and one
> > for data.
> > 
> > Signed-off-by: bdwhe...@indiana.edu
> > 
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index dd63664..b0b0b35 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -34,13 +34,26 @@
> > 
> >  #include 
> > 
> > -static const int smart_attributes[][5] = {
> > -/* id,  flags, val, wrst, thrsh */
> > -{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
> > -{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
> > -{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
> > -{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
> > -{ 0x00, 0x00, 0x00, 0x00, 0x00}
> > +/* These values were taking from a running system, specifically a
> > +   Seagate ST3500418AS */
> 
> 
> These values ought to have meaning for your hardware, but won't for either the
> virtual disk, nor the underlying storage that the virtual disk is
> running on.  Since we're not attempting to pass any of that info, nor
> keep it in-sync, it probably doesn't matter that much that we're just
> copying device specific data.  I'm open to discussion on how much we
> care about the attribute values[1].
> 
> 1. 
> https://secure.wikimedia.org/wikipedia/en/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
> 
> 

The main reason for this patch was to make sure the disk tools and
smartd on linux were happy and returned reasonable values.  At some
point I may add on the ability to trigger a smart failure (by jumping
the sectors remapped or something) but for now its read only and not
really meaningful.

> > +static const int smart_attributes[][12] = {
> > +/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
> > +/* raw read error rate*/
> > +{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d, 0x00, 0x00, 
> > 0x06},
> 
> probably fine, but this is vendor hardware specific.  I can't think of a
> better number other than 0.
> 

I've set it to zero.

> > +/* spin up */
> > +{ 0x03, 0x03, 0x00, 0x61, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
> > 0x00},
> 
> default is probably fine as well, though it's dependent upon the
> hardware as well.  Could be zero as well.
> 

I've set it to 16ms so skdump returns something other than 'n/a'


> > +/* start stop count */
> > +{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 
> > 0x14},
> 
> depends on hardware and power mgmt, any count is probably fine.
> 
> > +/* remapped sectors */
> > +{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
> > 0x24},
> 
> Probably should be zero.
> 

When dumping it via skdump or smartctl out it reads as 0 sectors
remapped (as indicated by the raw value).  The value looks like its a
countdown of sectors remaining, so setting it to the 'worst' value is
equivalent to no sectors remapped.


> > +/* power on hours */
> > +{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a, 0x00, 0x00, 0x00, 0x00, 
> > 0x00},
> 
> Zero.
> 

I'm going to set it to 1 (hour) so skdump returns something other than
'n/a'

> > +/* power cycle count */
> > +{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 
> > 0x00},
> 
> Zero

I've set it to zero.

> 
> > +/* airflow-temperature-celsius */
> > +{ 190,  0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22, 0x00, 0x00, 
> > 0x32},
> 
> Something resonably ambient 20-30C, current value is probably fine.
> 

it reads at 31.0C.  I've set the value (and worst)so it matches the raw
value.  (100C - 31C = 69C (0x45)).  I've also adjusted the raw value so
it shows the Min/Max is 31C


> > +/* end of list */
> > +{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
> > 0x00}

[Qemu-devel] [PATCH v3] Fix ATA SMART and CHECK POWER MODE

2011-02-09 Thread Brian Wheeler 
This patch fixes two things:
 
 1) CHECK POWER MODE
 
The error return value wasn't always zero, so it would show up as
offline.  Error is now explicitly set to zero.
 
 2) SMART
 
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output.  The data has been fixed up and raw value support
was added.  Tools like skdump and palimpsest work as expected.

v3 changes:  don't reformat code I didn't change
v2 changes:  use single structure instead of one for thresholds and one
for data.

Signed-off-by: bdwhe...@indiana.edu

diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..b0b0b35 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
 
 #include 
 
-static const int smart_attributes[][5] = {
-/* id,  flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system, specifically a
+   Seagate ST3500418AS */
+static const int smart_attributes[][12] = {
+/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190,  0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
 };
 
 /* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
 break;
 case WIN_CHECKPOWERMODE1:
 case WIN_CHECKPOWERMODE2:
+s->error = 0;
 s->nsector = 0xff; /* device active or idle */
 s->status = READY_STAT | SEEK_STAT;
 ide_set_irq(s->bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+   s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n<511; n++) /* checksum */
s->io_buffer[511] += s->io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0) {
break;
-   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][1];
-   s->io_buffer[2+3+(n*12)] = smart_attributes[n][2];
-   s->io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+   }
+   int i;
+   for(i = 0; i < 11; i++) {
+   s->io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+   }
}
s->io_buffer[362] = 0x02 | (s->smart_autosave?0x80:0x00);
if (s->smart_selftest_count == 0) {

[Qemu-devel] [PATCH v2] Fix ATA SMART and CHECK POWER MODE

2011-02-09 Thread Brian Wheeler 
This patch fixes two things:

1) CHECK POWER MODE

The error return value wasn't always zero, so it would show up as
offline.  Error is now explicitly set to zero.

2) SMART

The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output.  The data has been fixed up and raw value support was
added.  Tools like skdump and palimpsest work as expected.

Changes from v1:
* combined the thresholds and attributes into a single structure.


Signed-of-by: Brian Wheeler 

diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..3a9793b 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,15 +34,29 @@
 
 #include 
 
-static const int smart_attributes[][5] = {
-/* id,  flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system. */
+static const int smart_attributes[][12] = {
+/* id,  flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190,  0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
 };
 
+
+
 /* XXX: DVDs that could fit on a CD will be reported as a CD */
 static inline int media_present(IDEState *s)
 {
@@ -1843,6 +1857,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
 break;
 case WIN_CHECKPOWERMODE1:
 case WIN_CHECKPOWERMODE2:
+s->error = 0;
 s->nsector = 0xff; /* device active or idle */
 s->status = READY_STAT | SEEK_STAT;
 ide_set_irq(s->bus);
@@ -2068,24 +2083,24 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
case SMART_ATTR_AUTOSAVE:
switch (s->sector) {
case 0x00:
-   s->smart_autosave = 0;
-   break;
+   s->smart_autosave = 0;
+   break;
case 0xf1:
-   s->smart_autosave = 1;
-   break;
+   s->smart_autosave = 1;
+   break;
default:
-   goto abort_cmd;
+   goto abort_cmd;
}
s->status = READY_STAT | SEEK_STAT;
ide_set_irq(s->bus);
break;
case SMART_STATUS:
if (!s->smart_errors) {
-   s->hcyl = 0xc2;
-   s->lcyl = 0x4f;
+   s->hcyl = 0xc2;
+   s->lcyl = 0x4f;
} else {
-   s->hcyl = 0x2c;
-   s->lcyl = 0xf4;
+   s->hcyl = 0x2c;
+   s->lcyl = 0xf4;
}
s->status = READY_STAT | SEEK_STAT;
ide_set_irq(s->bus);
@@ -2094,13 +2109,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0)
break;
-   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
+   s->io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n<511; n++) /* checksum */
-   s->io_buffer[511] += s->io_buffer[n];
+   s->io_buffer[511] += s->io_buffer[n];
s->io_buffer[511] = 0x100 - s->io_buffer[511];
s->status = READY_STAT | SEEK_STAT;
ide_transfer_start(s, s->io_buffer, 0x200, ide_transfer_stop);
@@ -2110,21 +2125,22 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart str

[Qemu-devel] [PATCH] Fix ATA SMART and CHECK POWER MODE

2011-02-07 Thread Brian Wheeler 
This patch fixes two things:

1) CHECK POWER MODE

The error return value wasn't always zero, so it would show up as
offline.  Error is now explicitly set to zero.

2) SMART

The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output.  The data has been fixed up and raw value support was
added.  Tools like skdump and palimpsest work as expected.

Signed-of-by: Brian Wheeler 
---
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..4d4ccfa 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,15 +34,37 @@
 
 #include 
 
-static const int smart_attributes[][5] = {
-/* id,  flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system. */
+static const int smart_attributes[][12] = {
+/* id,  flags, hflags, val, wrst, raw (up to 6 bytes) */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32},
+/* airflow-temperature-celsius */
+{ 190,  0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22},
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
 };
 
+static const int smart_thresholds[][2] = {
+{ 0x01, 0x06},
+{ 0x03, 0x00},
+{ 0x04, 0x14},
+{ 0x05, 0x24},
+{ 0x09, 0x00},
+{ 190,  0x32},
+{ 0x00, 0x00}
+};
+
+
 /* XXX: DVDs that could fit on a CD will be reported as a CD */
 static inline int media_present(IDEState *s)
 {
@@ -1843,6 +1865,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
 break;
 case WIN_CHECKPOWERMODE1:
 case WIN_CHECKPOWERMODE2:
+s->error = 0;
 s->nsector = 0xff; /* device active or idle */
 s->status = READY_STAT | SEEK_STAT;
 ide_set_irq(s->bus);
@@ -2068,24 +2091,24 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
case SMART_ATTR_AUTOSAVE:
switch (s->sector) {
case 0x00:
-   s->smart_autosave = 0;
-   break;
+   s->smart_autosave = 0;
+   break;
case 0xf1:
-   s->smart_autosave = 1;
-   break;
+   s->smart_autosave = 1;
+   break;
default:
-   goto abort_cmd;
+   goto abort_cmd;
}
s->status = READY_STAT | SEEK_STAT;
ide_set_irq(s->bus);
break;
case SMART_STATUS:
if (!s->smart_errors) {
-   s->hcyl = 0xc2;
-   s->lcyl = 0x4f;
+   s->hcyl = 0xc2;
+   s->lcyl = 0x4f;
} else {
-   s->hcyl = 0x2c;
-   s->lcyl = 0xf4;
+   s->hcyl = 0x2c;
+   s->lcyl = 0xf4;
}
s->status = READY_STAT | SEEK_STAT;
ide_set_irq(s->bus);
@@ -2094,13 +2117,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0)
break;
-   s->io_buffer[2+0+(n*12)] = smart_attributes[n][0];
-   s->io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+   s->io_buffer[2+0+(n*12)] = smart_thresholds[n][0];
+   s->io_buffer[2+1+(n*12)] = smart_thresholds[n][1];
}
for (n=0; n<511; n++) /* checksum */
-   s->io_buffer[511] += s->io_buffer[n];
+   s->io_buffer[511] += s->io_buffer[n];
s->io_buffer[511] = 0x100 - s->io_buffer[511];
s->status = READY_STAT | SEEK_STAT;
ide_transfer_start(s, s->io_buffer, 0x200, ide_transfer_stop);
@@ -2110,21 +2133,22 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s->io_buffer, 0, 0x200);
s->io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n<30; n++) {
-   if (smart_attributes[n][0] == 0)
+   if (smart_attributes[n][0] == 0)

Re: [Qemu-devel] PS2 Mouse/Kbd do not work with qemu-0.13.0

2010-11-16 Thread Brian Wheeler 
On Tue, 2010-11-16 at 13:52 -0800, Adhyas Avasthi wrote:
> I have issues with both PS2 Mouse and Keyboard working out of the box
> with virgin qemu-0.13.0 code base. The host is Ubuntu 10.04 x86_64 and
> I am making a 64-bit build for x86_64-softmmu
> 
> Sometimes (for some guest environments, e.g. Ubuntu 10.10. x86_64) the
> mouse does not work within the guest, while the keyboard does. In some
> other environments, the keyboard does not work as well. Has anyone
> else witnessed the same issue? Are there any known workarounds I can
> use to move ahead?
> 
> USB keyboard/mouse do work, but I cannot use that workaround for the
> work I am doing as I don't have USB drivers in my BIOS yet.
> I will appreciate any responses that can help me get unblocked.
> 

I don't have any helpful advice, but the PS/2 Mouse has been broken for
ages for OpenStep and some other older OSes.  I tried to track it down
but I never could quite pinpoint what was going on.

Brian


> Thanks,
> Adhyas
> 
> Two types have compatible type if their types are the same.
> — ANSI C Standard, 3.1.2.6.
> 
>

[Qemu-devel] Can't compile ISA device...

2010-10-20 Thread Brian Wheeler 
I'm trying to write a busmouse driver and I can't get it to compile.  It
seems like there's a header issue of some sort that I can't work out.

Of course, if someone has a working busmouse driver for qemu, that would
be great:  OpenStep won't work with the ps/2 emulation and even after
pounding on it for a few days I can't seem to narrow down why it OS
stops paying attention to it.  The consensus in 2006 was "fix the ps/2
emulation" but apparently nobody has been able to figure out how its
broken and this seems like a reasonable solution. 

My code is based on the pc98 busmouse driver by TAKEDA, toshiya and the
busmouse patches that floated around the list over the last few years.

Anyway, it seems like a typedef is wrong.  Did I miss something obvious?

Thanks
Brian

I'm getting:
==
In file included from /home/bdwheele/Projects/qemu/hw/pc.h:7,
 from /home/bdwheele/Projects/qemu/hw/busmouse.c:30:
/home/bdwheele/Projects/qemu/hw/isa.h:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ 
or ‘__attribute__’ before ‘isa_mem_base’
/home/bdwheele/Projects/qemu/hw/isa.h:35: error: expected ‘)’ before ‘base’
In file included from /home/bdwheele/Projects/qemu/hw/pc.h:8,
 from /home/bdwheele/Projects/qemu/hw/busmouse.c:30:
/home/bdwheele/Projects/qemu/hw/fdc.h:11: error: expected declaration 
specifiers or ‘...’ before ‘target_phys_addr_t’
/home/bdwheele/Projects/qemu/hw/fdc.h:12: error: expected declaration 
specifiers or ‘...’ before ‘target_phys_addr_t’
In file included from /home/bdwheele/Projects/qemu/hw/busmouse.c:30:
/home/bdwheele/Projects/qemu/hw/pc.h:15: error: expected ‘)’ before ‘base’
/home/bdwheele/Projects/qemu/hw/pc.h:26: error: expected ‘)’ before ‘base’
/home/bdwheele/Projects/qemu/hw/pc.h:78: error: expected declaration specifiers 
or ‘...’ before ‘target_phys_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:78: error: expected declaration specifiers 
or ‘...’ before ‘ram_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:79: error: expected declaration specifiers 
or ‘...’ before ‘target_phys_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:91: error: expected ‘)’ before ‘ram_size’
/home/bdwheele/Projects/qemu/hw/pc.h:106: error: expected ‘)’ before ‘ram_size’
/home/bdwheele/Projects/qemu/hw/pc.h:141: error: expected declaration 
specifiers or ‘...’ before ‘ram_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:159: error: expected ‘)’ before ‘vram_base’
=

I've added it to Makefile.objs:
=
diff --git a/Makefile.objs b/Makefile.objs
index 816194a..908c21f 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -81,7 +81,7 @@ common-obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o 
bt-hci.o bt-hid.o u
 common-obj-y += bt-hci-csr.o
 common-obj-y += buffered_file.o migration.o migration-tcp.o qemu-sockets.o
 common-obj-y += qemu-char.o savevm.o #aio.o
-common-obj-y += msmouse.o ps2.o
+common-obj-y += msmouse.o ps2.o busmouse.o
 common-obj-y += qdev.o qdev-properties.o
 common-obj-y += block-migration.o
 common-obj-y += pflib.o
==

and here's the source:
=
#include "hw.h"
#include "pc.h"
#include "isa.h"
#include "qdev.h"
#include "console.h"

struct mouse_t {
int button;
int dx, dy;
uint8_t index;
qemu_irq irq;
int irq_pending;
};

typedef struct mouse_isabus_t {
ISADevice busdev;
struct mouse_t state;
} mouse_isabus_t;

typedef struct mouse_t mouse_t;

/* mouse */

static void mouse_event_handler(void *opaque,
int dx, int dy, int dz, int buttons_state)
{
mouse_t *s = opaque;
s->button = buttons_state;
s->dx += dx;
s->dy += dy;
s->irq_pending = 1;
}


static void busmouse_update_irq(mouse_t *s)
{
if (s->irq_pending) {
qemu_set_irq(s->irq, 1);
} else {
qemu_set_irq(s->irq, 0);
}
}


/* pio */

static void busmouse_pio_write(void *opaque, uint32_t addr, uint32_t val)
{
mouse_t *s = opaque;
switch(addr) {
case 0:  //data
break;
case 1: // signature
break;
case 2: // control
s->index = val;
break;
case 3: // config
break;
}


}

static uint32_t busmouse_pio_read(void *opaque, uint32_t addr)
{
mouse_t *s = opaque;
uint32_t val = 0;
static int interrupt_val = 0x01;
s->irq_pending = 0;
switch(addr) {
case 0: // data
s->irq_pending = 0;
val |= (s->button & 1)? 0x80 : 0x00;
val |= (s->button & 2)? 0x40 : 0x00;
val |= (s->button & 4)? 0x20 : 0x00;
val |= ((s->index & 0x40? s->dy : s->dx) >> (s->index & 0x20? 4 : 0)) & 
0x0f;
busmouse_update_irq(s);
break;
case 1: // signature
val = 0xa5; 
busmouse_update_irq(s);
break;
case 2: // control
val = interrupt_val;
interrupt_val = (interrupt_val << 1) && 0xff;
if (interrupt_v

[Qemu-devel] weird mouse troubles in latest git

2010-10-15 Thread Brian Wheeler 
I'm trying to run openstep 2.4 on the latest git and the mouse hangs
after a few seconds of running.  I turned on debugging some debugging
flags:
ps2.c:  DEBUG_MOUSE
pckbd.c: DEBUG_KEYBOARD
i8259.c: DEBUG_PIC

I'm still not sure where the problem is, but here's what I've
discovered:  If I filter out all messages except ones with irq=12 I get
this sequence (when using the sdl ui):

* a bunch of set_irq level=1 followed immediately by a level=0 which is
what I'd expect.
* when the mouse hangs, it hangs with a level=1
* hitting ctrl-alt to release focus gives me a bunch of level=1/level=0
pairs along with a bunch of pic_interrupts for irq 12


When I use the vnc ui, I get 2 pairs of "set_irq irq=12 level=1/0"
followed by a pic: pic_interrupt: irq=12.  When I move the mouse into
the vnc window I get the set_irq level = 1 and the mouse is done.

So, is the guest not picking up the interrupts correctly or is there
some problem with the UI not sending mouse requests through if the guest
hasn't handled them?

There are mouse troubles with OS/2 4.0 as well which may be related (the
button stops working but the mouse would still move.

Its not terribly important, but I thought someone should know.

Re: [Qemu-devel] qemu alpha?

2007-10-23 Thread Brian Wheeler 
On Tue, 2007-10-23 at 00:38 +0200, J. Mayer wrote:
> On Mon, 2007-10-22 at 09:43 +0200, Oliver Falk wrote:
> > On 10/21/2007 01:06 PM, J. Mayer wrote:
> > > 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.
> > 
> > Pretty good explained! Thanks!
> > 
> > 
> > 
> > However, what do you need to make the alpha emulation work? Does ssh to
> > an Alpha help you? I'm quite sure I can offer you access to some ev5
> > machine very soon and I might give access to some ds10 (ev67 machine).
> > There's also some ds10 (ev6 'only') machine in Australia, that actually
> > works as a builder for the AlphaCore project - but it's not mine and I
> > would need to ask if I can give access to someone else...
> 
> I actually do not have a lot of time to spend of Alpha emulation, that's
> why it would be great if some could test and compare the execution of
> simple programs (then later more complicated one) in order to find the
> most obvious emulation bugs, with the linux-user mode emulation.
> For this, an access to any Alpha machine could help a lot.
> For the full system emulation, a lot of work is to be done, mostly the
> PALCode emulation and putting together all elements of an actual
> hardware machine. Note that the PALCode emulation could be avoided if
> the emulator is able to run native PALCode image but I don't know if
> those images are easily available...
> 

A couple of notes/questions on Alpha emulators:

* there is an open source alpha emulator, but it seems to have stalled.
It is at:

http://www.camicom.com/index.php?option=com_content&task=blogcategory&id=8&Itemid=14

* The palcode is downloadable in one form or another from the old
digital site:

ftp://ftp.digital.com/pub/digital/Alpha/firmware

If the palcode could be emulated directly, it would make the emulation
much faster, however during OS boot, most OSes will override the palcode
settings.


* full-system hardware
All of the mid-to-late models used isa/pci, and usually used
off-the-shelf hardware.  I know the scsi controller that was supported
by default was qlogic-based (isp1020), and many systems had bog-standard
IDE controllers (cmd 646).  Some of the video cards supported directly
were generic VGA, matrox millenium, s3 trio, plus several proprietary
ones.  Ethernet tended to be Digital's 21142/21143 family.

Is there a howto for creating new devices and plugging them into an
existing system emulation?  Since all of these devices are pc
compatible, it seems like they could be written and debugged from the PC
emulation and

Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images

2007-08-09 Thread Brian Wheeler 
On Thu, 2007-08-09 at 23:16 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> >>
> >> I think it is a bad idea from a security POV to automatically extract 
> >> & use command line args from  a disk image like this without the 
> >> admin explicitly requesting this capability.
> >> eg If I grabbed a demo disk image from a vendors' or community 
> >> website I would
> >> certainly not trust whatever args may happen to be embedded in the 
> >> disk image
> >> and thus do not want QEMU to be automatically running using them.
> >>
> >> I'd recommend having some command line flag to turn this capability 
> >> on. For
> >> example a '--args PATH-TO-DISK' flag,
> >>
> >>   qemu --args $HOME/fedora.qcow
> >>   
> >
> > That's pretty nasty.  How do you specify which disk this is then?  I 
> > do agree with you that allowing arbitrary command line arguments in an 
> > image file is probably a bad idea.  I think the general idea of being 
> > able to launch a single image is useful but I suspect this is not the 
> > right way to do it.
> >
> > What are some people thinking would want to be stored in the file?  
> > Most of the command line options are more host specific than guest 
> > specific I think.  Maybe we can store a pseudo-config instead that 
> > only contains a subset of parameters (and therefore, wouldn't pose a 
> > security risk)? 
> 
> Memory size, -hdb and -cdrom, processor count, networking setup.  The 
> sort of things people push into ad-hoc scripts.
> 
> I expect this to be the low-end solution; with high end management 
> applications storing configuration options in a database.
> 
> 

Why not just save the options to a file and have qemu parse it?  That
way all of the security issues are taken care of, and it can be cross
platform (no need for a shell script and/or batch file) so it'd be
portable.

If the format was one flag per line (as if the command line got broken
up in pairs) as in "-hdb myfile.img" being on one line and "-fda
boot.img" on another line, then its easy to edit programically as well.

All of my shell scripts to start qemu tend to look like this:

qemu -hda disk0.img -net nic -net user -m 512 -localtime   $*

so I can pass one-time parameters as necessary (that's the $* at the
end) by specifying args when I invoke the script.  If qemu had a default
configuration file it looked for, and then you could specify one-or-more
configuration files to read in addition (later values overriding earlier
ones), then it seems like it'd work out for most if not all situations.



Brian

Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images

2007-08-09 Thread Brian Wheeler 
On Thu, 2007-08-09 at 15:32 -0500, Anthony Liguori wrote:
> Avi Kivity wrote:
> > Anthony Liguori wrote:
> >>
> >> If you're looking for a low-end solution, another possibility would 
> >> be having a "new" file format which consisted of:
> >>
> >> #!/path/to/qemu [ ...] 
> >> 
> >>
> >> And then make the appropriate changes to QEMU such that it can skip 
> >> the first line in a disk image file.  This has a few nice side 
> >> effects.  The disk image is directly executable and it makes it very 
> >> clear to the user that they have to trust the disk image.  The other 
> >> nice thing is that it would work with file formats other than qcow2.
> >
> > Well, it would be nice to align the disk image to a sector boundary 
> > (or, better, a page boundary).  But yes, a very good idea.
> 
> That has the very nice side effect of allowing you to edit the command 
> line with a text editor provided you don't cross the sector boundary.  
> Filling with spaces would be pretty nice.
> 


Its a bad idea.  Either have a line terminated file, or a pure binary
file, but don't mix them.  Besides firing up an editor to modify it
being a royal pain, mystery breakages will occur when someone has their
editor set to "insert mode" (which is the default) vs "overwrite mode"
and doesn't notice those extra spaces moving beyond the 512-byte mark.

Brian

> Regards,
> 
> Anthony Liguori
> 
> 
>

Re: [Qemu-devel] IBM makes AIX 6 beta available for download for everyone

2007-07-18 Thread Brian Wheeler 
On Wed, 2007-07-18 at 09:15 +0100, Natalia Portillo wrote:
> Hi,
> 
> AIX was already tested in QEMU and is not that it does not understand
> the AIX boot format (it does!), just there is another problem that
> prevents OHW from working (some say there is a regression in the IDE
> controller code).
> 
> http://www.claunia.com/qemu/
> 
> Regards
> Natalia Portillo
> 


AIX 4.3.3 starts to boot (well, further than 5.1 & 5.2 do)

The serial console has:
-
Probe filesystem on unknown PREP partition 'PREP boot' (bootable) 5834080
Fix bootfile
Partition is bootable (1)
bd_set_boot_part: part 5834080 (0) 1
Boot partition: 5834080 582e400 582e400 0
ERROR: Found boot partition : 5834080 582e400
ERROR: Not a MACH-O file
ERROR: Not an Apple CHRP boot file !
dest 10 entry 0230 => 100230
Load raw file into memory at 10 3307448 (003277b8) 0 ()
Boot: 3004 b8773200 00024149 5820234
Bootinfos at : 50

Now boot it... (0)
stack: 5bfff80 malloc_base: 0 0x5800 0x0600
PREP boot... 100230 10


The graphic console has some messages (which I assume are the ones above) and 
then it goes blank.
It may still be doing something, I'll just wait for a while and see.

Both 5.1 and 5.2 complain about the return code from the ide controller 
ERROR: ATAPI READ12 : status 41 != 0x48

(ready | error ) != ( ready | drq)


It looks like open hack'ware is pretty much stalled, so its hard telling
what progress will be made futurewise.

Brian








> El mié, 18-07-2007 a las 03:32 +0200, Martin escribió:
> > IBM opened up a little bit and makes the beta of AIX 6 available to anyone.
> > Maybe this is an opportunity to get AIX running on QEMU.
> > 
> > At the moment QEMU does not yet understand the AIX cd boot format.
> > I tried to boot it using the -kernel option b
> > I tried to boot it in the following ways, but that doesn't work yet (as 
> > expected)
> > qemu-system-ppc -m prep -cdrom cd.AIX_6_OpenBeta.0723C1.V1.ISO -boot d
> > 
> > sudo mount -o loop cd.AIX_6_OpenBeta.0723C1.V1.ISO /mnt/loop
> > qemu-system-ppc -M prep  -kernel /mnt/loop/ppc/chrp/bootfile.exe
> > 
> > The -kernel option is meant for linux kernels but I hoped it would take an 
> > AIX kernel too.
> > 
> > You can download the AIX 6 beta from:
> > http://www-03.ibm.com/servers/aix/6/beta.html
> > (free registration required)
> > 
> > > Open beta now available
> > > 
> > > The open beta for AIX® 6 is now available. 
> > > Go to 
> > > https://www14.software.ibm.com/iwm/web/cc/earlyprograms/ibm/aix6beta/
> > > for more information and to download the beta code.
> > > 
> > > Overview
> > > 
> > > Openness, such as compliance with open standards, has always been an 
> > > integral part of the AIX operating system (OS). The next release of AIX, 
> > > Version 6.1, extends this openness to the product release process with 
> > > the first ever AIX open beta. The open beta will allow a broad set of IBM 
> > > clients to download and gain experience with AIX 6 before it becomes 
> > > generally available.
> > > 
> > > An "open" beta for the next AIX release differs from the traditional beta 
> > > in three key areas:
> > > 
> > > * Almost anyone who is interested will be able to download and 
> > > install a pre-release version of AIX 6. By contrast, only a few clients 
> > > would have the opportunity to test a new AIX release in a traditional 
> > > beta.
> > > * Participants in the open beta will not receive traditional support 
> > > from IBM. Instead, you access a Web forum to discuss questions and issues.
> > > * The only legal document required for participation in the open beta 
> > > is a "click to accept" license agreement that clearly states all program 
> > > conditions.
> > 
> > 
> > 
> 
> 
>

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

2007-03-29 Thread Brian Wheeler 
For a somewhat complete alpha emulator, there's es40 on sourceforge.  It
doesn't actually boot an OS yet, but its getting closer.  The firmware
comes up and but it hangs on OS initialization.


http://sourceforge.net/projects/es40/

Brian




On Thu, 2007-03-29 at 21:57 +0200, J. Mayer wrote:
> On Thu, 2007-03-29 at 17:08 +0100, Stuart Brady wrote:
> > On Thu, Mar 29, 2007 at 05:25:47PM +0200, Sunil Amitkumar Janki wrote:
> > 
> > > About the Alphas, it would be great to run Tru64 on them or for the
> > > occasional OpenVMS session. I'm looking forward to implementing an
> > > Alpha target even though I've never seen or used them. You must be
> > > very lucky to have them at your disposal.
> > 
> > I've been thinking about Alpha emulation for a while.  I'd be happy to
> > help in any way that I can.
> 
> If you are interressed to this target, you may like this:
> I did, for fun, a preliminary version of the alpha CPU emulation.
> For now, it implements most of the CPU instructions and should be able
> to achieve user mode emulation after a debugging pass. For now, only a
> few static programs start and run. The problem is I have too few free
> time to debug it correctly and no alpha hardware or specific knowledge
> to help me.
> So, if someone is interrested to debug and develop this target, I could
> add the code I have to the Qemu repository as a start and let any
> motivated one go on developping the target.
> 
> [...]
>

Re: [Qemu-devel] qemu-system-sparc question?

2006-10-11 Thread Brian Wheeler 
On Wed, 2006-10-11 at 19:32 +0200, Marco Matthies wrote:
> Blue Swirl wrote:
> > BTW, we could easily design and implement an ideal CPU just for Qemu 
> > purposes. It could be unlike any existing hardware, for example with 
> > zero or thousands of registers. The problem would be making a compiler 
> > for the CPU, also porting some OS to it. Any GCC and Linux guru 
> > volunteers? CS research projects?
> 
> How about MMIX?
> http://en.wikipedia.org/wiki/MMIX
> 
> There is already a simulator/assembler here:
> http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html
> 
> Marco
> 

It might not be a bad idea, especially since MMIX is well documented and
fairly simple.  

However, since it doesn't have real devices (Just traps to do OS-like
things), it'd probably be good to have a simple CPU with some simple
devices so newcomers can copy it as a starting point for other projects.


Brian



> 
> ___
> 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] AXP guest?

2006-08-30 Thread Brian Wheeler 
Has anyone looked at doing an Alpha guest?  The instruction set seems
fairly straightforward and the machine as a whole seems to be an alpha
chip + pci, which shouldn't be all that different from the x86 machine
setup, from a full system point of view.

I've been looking through the qemu documentation and I'm not even sure
where one would begin to add this.  My C is pretty rusty, but I'd start
giving it a shot if someone could give me some pointers on how to get
started.  At the very least I could contribute some grudge work writing
op routines...

[I'm curious to know if a qemu-axp on my athlon 64 3200+ would outpace
my alpha 1000a/233!  I suspect it would give it a run for its money.]

Brian




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

[Qemu-devel] [ot?] Vista Networking

2006-06-22 Thread Brian Wheeler 
Has anyone gotten this to work?  I'm probably missing something obvious.
Here's the command line I'm using (on linux with a CVS from today):

qemu -hda disk0.img -net nic,model=rtl8139 -net user -m 512 -soundhw
sb16 

Vista is installed and I manually set the IP to 10.0.2.15 and the
gateway to 10.0.2.2.  I set the DNS to 10.0.2.3.  I can't get any
response from the DNS or anything beyond the firewall.

Did I mess up something or is there a bug in user-space networking?

Thanks!
Brian



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

Re: [Qemu-devel] Windows Vista

2006-06-09 Thread Brian Wheeler 
On Fri, 2006-06-09 at 14:25 +0200, René Korthaus wrote:
> Am 09.06.2006 um 14:08 schrieb Brian Wheeler:
> 
> > On Fri, 2006-06-09 at 10:20 +0200, René Korthaus wrote:
> >> Edit:
> >>
> >> I think it has something to do with the harddisk image. Error is
> >> "STOP: d144 Unknown Hard Error".
> >>
> >> Somebody having an idea?
> >>
> >>
> >
> > I set the windows 2000 install fix flag (-win2k-hack) and it installed
> > for me.   Upon install, it didn't find the ethernet card, but it did
> > run.
> 
> I passed that error by simply upgrading to latest CVS from today. But  
> now I am at the "Install is being finished" - step and it takes a lot  
> of time. Just trying with -win2k-hack enabled... Let's see. How long  
> did the overall install take for you?
> 
> 

I was updated CVS as well yesterday, so that may have done it on its
own.  

The install took ages.  So far I'm not terribly impressed being a Linux
guy, but then, it is a beta in an emulator and networking isn't working.

Brian 



> >
> > Brian
> >
> >
> >
> >> Am 09.06.2006 um 09:55 schrieb René Korthaus:
> >>
> >>> With CVS from May 28 Vista install boots.
> >>>
> >>> But now i got another problem: During extraction of files install
> >>> stops with an unknown hardware error.
> >>> Is there a size limit for -cdrom files? The install DVD is about
> >>> 3,3GB.
> >>>
> >>>
> >>>
> >>> Am 09.06.2006 um 02:11 schrieb Nigel J. Terry:
> >>>
> >>>> Christian MICHON wrote:
> >>>>> don't you need special acpi features inside qemu/bios, otherwise
> >>>>> the iso
> >>>>> would not boot ?
> >>>>>
> >>>>> On 6/8/06, Hetz Ben Hamo <[EMAIL PROTECTED]> wrote:
> >>>>>> Hi people,
> >>>>>>
> >>>>>> Microsoft has released a free download ISO of Windows Vista  
> >>>>>> Beta 2.
> >>>>>> This Beta will expire at July 1st 2007.
> >>>>>>
> >>>>>> Anyone who want to download it (3.3 GB for 32 bit version, 4.4
> >>>>>> GB for
> >>>>>> 64 bit version) can go to:
> >>>>>> http://www.microsoft.com/windowsvista/getready/preview.mspx
> >>>>>>
> >>>>>> It might be fun to test it :)
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Hetz
> >>>>>> -- 
> >>>>>> Visit my blog (hebrew) for things that (sometimes) matter:
> >>>>>>  http://wp.dad-answers.com
> >>>>>>
> >>>>>>
> >>>>>> ___
> >>>>>> Qemu-devel mailing list
> >>>>>> Qemu-devel@nongnu.org
> >>>>>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >>>>>>
> >>>>>
> >>>>>
> >>>> Yes you do need ACPI to get the .iso to boot. I tried it and it
> >>>> failed. You also need 512M of ram and the ability to accept that
> >>>> your PC will BSOD often :-)
> >>>>
> >>>> I'll stick with FC5
> >>>>
> >>>> Nigel
> >>>>
> >>>>
> >>>> ___
> >>>> 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
> >
> >
> >
> > ___
> > 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] Windows Vista

2006-06-09 Thread Brian Wheeler 
On Fri, 2006-06-09 at 10:20 +0200, René Korthaus wrote:
> Edit:
> 
> I think it has something to do with the harddisk image. Error is  
> "STOP: d144 Unknown Hard Error".
> 
> Somebody having an idea?
> 
> 

I set the windows 2000 install fix flag (-win2k-hack) and it installed
for me.   Upon install, it didn't find the ethernet card, but it did
run.

Brian



> Am 09.06.2006 um 09:55 schrieb René Korthaus:
> 
> > With CVS from May 28 Vista install boots.
> >
> > But now i got another problem: During extraction of files install  
> > stops with an unknown hardware error.
> > Is there a size limit for -cdrom files? The install DVD is about  
> > 3,3GB.
> >
> >
> >
> > Am 09.06.2006 um 02:11 schrieb Nigel J. Terry:
> >
> >> Christian MICHON wrote:
> >>> don't you need special acpi features inside qemu/bios, otherwise  
> >>> the iso
> >>> would not boot ?
> >>>
> >>> On 6/8/06, Hetz Ben Hamo <[EMAIL PROTECTED]> wrote:
>  Hi people,
> 
>  Microsoft has released a free download ISO of Windows Vista Beta 2.
>  This Beta will expire at July 1st 2007.
> 
>  Anyone who want to download it (3.3 GB for 32 bit version, 4.4  
>  GB for
>  64 bit version) can go to:
>  http://www.microsoft.com/windowsvista/getready/preview.mspx
> 
>  It might be fun to test it :)
> 
>  Thanks,
>  Hetz
>  -- 
>  Visit my blog (hebrew) for things that (sometimes) matter:
>   http://wp.dad-answers.com
> 
> 
>  ___
>  Qemu-devel mailing list
>  Qemu-devel@nongnu.org
>  http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> >>>
> >>>
> >> Yes you do need ACPI to get the .iso to boot. I tried it and it  
> >> failed. You also need 512M of ram and the ability to accept that  
> >> your PC will BSOD often :-)
> >>
> >> I'll stick with FC5
> >>
> >> Nigel
> >>
> >>
> >> ___
> >> 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



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

Re: [Qemu-devel] Printing bogus values in ne2000_asic_ioport_read()/ ne2000_receive()

2006-03-03 Thread Brian Wheeler 
On Sun, 2006-02-26 at 10:01 -0800, Umamaheswararao Karyampudi wrote:
> Hi,
> I am using QEMU in one of my research projects. I
> landed in a problem where I see bogus numbers being
> printed when I printed the packet/each word that is
> received from ne2000.
> 
> In ne2000_receive(), I copied the packet received to a
> static char [] and printed the packet using
>  static void print_packet(char *s, int len)
> {
>   int i,j;
>   for (i=0;i   if (i%20 == 0)
>   printf("\n");
>   printf("%02x ", s[i]);
>   }
>   printf("\n");
> }
> And some bytes it prints as f
> instead of just the last byte.
> For eg:
> 52 54 00 12 34 56 00  4f 0a 46 05 08 00 45 00
> 00 ff80 00 00
> 40 00 40 01 ffbc 2b ffc0 ffa8 fffe
> fffe ffc0 ffa8 ff
> 

Just guessing, but is it a signed/unsigned thing?  All of the ffxx
values are above 0x7f...

Brian





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

Re: [Qemu-devel] Open Hack'Ware question

2005-07-21 Thread Brian Wheeler 
After checking strings it looks like bootfile.exe is a bootloader that
pounds openfirmware rather extensively.

Hmm.  Is there a way to load a real ibm firmware into qemu?  Since I
have access to machines it might be an interesting experiment.

Brian

On Thu, 2005-07-21 at 09:30 -0500, Brian Wheeler wrote:
> On Wed, 2005-07-20 at 22:49 +0200, J. Mayer wrote:
> > On Thu, 2005-07-14 at 10:32 -0500, Brian Wheeler wrote:
> > > All of the websites that are referred to in the docs and source are
> > > missing.  Is there another place to get it?  I'm tinkering with the idea
> > > to try to boot aix on qemu.
> > 
> > There was a broken link.
> > I just fixed it.
> > 
> 
> Thanks.
> 
> > But, for your information, AIX boot has been tested and does not boot.
> > The reason is it use a specific boot file format (with AIXM magic at
> > start) and I did not spent any time to discover where is stored the code
> > offset (but I know what the offset value is).
> > As reported in OHW README, I did test AIX 4.3.3 & 5.1.
> > 
> 
> Would booting the bootfile.exe from the CD directly via -kernel be a
> future option to work around the AIXM magic?  The exe looks to be a
> standard ELF file for powerpc.  It might be interesting to see what that
> file actually does (i.e. if its the kernel or a boot loader)
> 
> Brian
> 
> 
> 
> ___
> 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] Open Hack'Ware question

2005-07-21 Thread Brian Wheeler 
On Wed, 2005-07-20 at 22:49 +0200, J. Mayer wrote:
> On Thu, 2005-07-14 at 10:32 -0500, Brian Wheeler wrote:
> > All of the websites that are referred to in the docs and source are
> > missing.  Is there another place to get it?  I'm tinkering with the idea
> > to try to boot aix on qemu.
> 
> There was a broken link.
> I just fixed it.
> 

Thanks.

> But, for your information, AIX boot has been tested and does not boot.
> The reason is it use a specific boot file format (with AIXM magic at
> start) and I did not spent any time to discover where is stored the code
> offset (but I know what the offset value is).
> As reported in OHW README, I did test AIX 4.3.3 & 5.1.
> 

Would booting the bootfile.exe from the CD directly via -kernel be a
future option to work around the AIXM magic?  The exe looks to be a
standard ELF file for powerpc.  It might be interesting to see what that
file actually does (i.e. if its the kernel or a boot loader)

Brian



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

Re: [Qemu-devel] Open Hack'Ware question

2005-07-15 Thread Brian Wheeler 
That's why I was hoping to find the source so I could tinker with it a
bit and see if I could make any progress :)

It looks like the test was against AIX 5.2.  I've got 4.1 -> 5.2 so I
can test a bunch of different versions to see if there's a difference in
behavior.

Brian


On Thu, 2005-07-14 at 23:41 +0100, Natalia Portillo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> AIX won't work, it is tested, check http://www.claunia.com/qemu/, and  
> if you have a correct CD with the correct PReP partition OHW will  
> simply try to boot it with -M prep and -boot d options.
> 
> Regards,
> Natalia Portillo
> 
> El 14/07/2005, a las 17:33, Brian Wheeler escribió:
> 
> > On Thu, 2005-07-14 at 17:52 +0200, Karel Gardas wrote:
> >
> >> On Thu, 14 Jul 2005, Brian Wheeler wrote:
> >>
> >>
> >>> All of the websites that are referred to in the docs and source are
> >>> missing.  Is there another place to get it?  I'm tinkering with  
> >>> the idea
> >>> to try to boot aix on qemu.
> >>>
> >>
> >> The same here! But for RTEMS and Mesquite cPCI (MCP750) BSP.
> >>
> >> Any idea how to get such code booting? IMHO the best would be to use
> >> Qemu's -kernel option, but I don't know what are precise  
> >> requirement for
> >> it and for image booting in this scenario.
> >>
> >>
> >
> > I think for AIX it is a matter of seeing what the PREP specification
> > says and seeing what OHW does -- and then trying it on something like
> > AIX 4.3.3 and seeing where it fails.
> >
> > For your application, I'm not sure what you'd need to do...but the
> > kernel option does sound like the best bet.
> >
> > Brian
> >
> >
> >
> >> Thanks,
> >> Karel
> >> --
> >> Karel Gardas  [EMAIL PROTECTED]
> >> ObjectSecurity Ltd.   http://www.objectsecurity.com
> >>
> >>
> >> ___
> >> 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
> >
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (Darwin)
> 
> iD8DBQFC1uowSOHwOb87puQRAjziAKCSUVJx1KJdBwPWptYFjXWvz0wQDACfWmks
> j7uut0iMmgMr5aw7agpzZcE=
> =Kdp/
> -END PGP SIGNATURE-
> 
> 
> ___
> 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] Open Hack'Ware question

2005-07-14 Thread Brian Wheeler 
On Thu, 2005-07-14 at 17:52 +0200, Karel Gardas wrote:
> On Thu, 14 Jul 2005, Brian Wheeler wrote:
> 
> > All of the websites that are referred to in the docs and source are
> > missing.  Is there another place to get it?  I'm tinkering with the idea
> > to try to boot aix on qemu.
> 
> The same here! But for RTEMS and Mesquite cPCI (MCP750) BSP.
> 
> Any idea how to get such code booting? IMHO the best would be to use 
> Qemu's -kernel option, but I don't know what are precise requirement for 
> it and for image booting in this scenario.
> 

I think for AIX it is a matter of seeing what the PREP specification
says and seeing what OHW does -- and then trying it on something like
AIX 4.3.3 and seeing where it fails.

For your application, I'm not sure what you'd need to do...but the
kernel option does sound like the best bet.

Brian


> Thanks,
> Karel
> --
> Karel Gardas  [EMAIL PROTECTED]
> ObjectSecurity Ltd.   http://www.objectsecurity.com
> 
> 
> ___
> 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] Open Hack'Ware question

2005-07-14 Thread Brian Wheeler 
All of the websites that are referred to in the docs and source are
missing.  Is there another place to get it?  I'm tinkering with the idea
to try to boot aix on qemu.

Thanks!
Brian Wheeler
[EMAIL PROTECTED]



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