[Qemu-devel] [PATCH] mixed types in target_mremap() return incorrect value

[Thayne Harbaugh]

There are mixed types (long vs target_ulong) in
linux-user/mmap.c:target_mremap() and consequently the wrong value is
returned (automatic type casting fails) when the host long is larger
than the guest long and -1 is returned for an error condition.

Consider the initial lines of target_mremap() where a failure is tested:

long target_mremap(target_ulong old_addr, target_ulong old_size,
   target_ulong new_size, unsigned long flags,
   target_ulong new_addr)
{
int prot;

/* XXX: use 5 args syscall */
new_addr = (long)mremap(g2h(old_addr), old_size, new_size, flags);
if (new_addr == -1)
return new_addr;

Note that signed long is the return type for target_mremap() while
target_ulong is used for new_addr and the return value of mremap().
When the host long is larger than the target long the following can
happen on mremap() failure: -1 is stored in new_addr which is unsigned.
The test for new_addr == -1 is true because the -1 is cast to
target_ulong.  When new_addr is returned, however, new_addr is cast to
long, which is larger than target_ulong for the case of i386 target on
x86_64 guest and the -1 is now a positive number that can be fully
represented as a positive number even though the return value is signed.

This patch is one way to ensure that -1 is always returned for an error
condition:

Index: qemu/linux-user/mmap.c
===
--- qemu.orig/linux-user/mmap.c 2007-10-02 00:27:36.0 -0600
+++ qemu/linux-user/mmap.c  2007-10-02 00:31:41.0 -0600
@@ -395,7 +395,7 @@
 /* XXX: use 5 args syscall */
 new_addr = (long)mremap(g2h(old_addr), old_size, new_size, flags);
 if (new_addr == -1)
-return new_addr;
+return -1;
 new_addr = h2g(new_addr);
 prot = page_get_flags(old_addr);
 page_set_flags(old_addr, old_addr + old_size, 0);

Re: [Qemu-devel] [PATCH] getpriority() shouldn't use libc wrapper

[Thayne Harbaugh]

On Wed, 2007-09-26 at 14:06 -0600, Thayne Harbaugh wrote:
> The linux-user getpriority() syscall goes through the libc wrapper.
> This causes a problem because the libc wrapper remaps the return value
> from the kernel.  This patch calls the kernel getpriority syscall
> directly.

I didn't see any discussion about this nor did I see it committed.  Were
there any concerns or objections?  It fixes several failures in the LTP
test suite.

The bug is that the kernel returns -1 on error and 1-40 on success - the
libc wrapper remaps this to -1 or error and -20 - 19 on succes (errno
must be cleared and checked for the -1 case to determine if there was an
error).  If qemu uses the libc wrapper then the return value is aleady
remapped to negative numbers - which appear to be errors.

[Qemu-devel] sparc32 CVS broken

[Robert Reif]

Sparc32 CVS exits after illegal instruction trap.

Nvram id QEMU_BIOS, version 1, machine id 0x80
CPUs: 1
Welcome to OpenBIOS v1.0RC1 built on Aug 11 2007 08:00
  Type 'help' for detailed information

[sparc] Kernel already loaded
qemu: fatal: Trap 0x02 while interrupts disabled, Error state
pc: ffd0108c  npc: ffd01090
General Registers:
%g0:    %g1: 0002   %g2: 04401fc2   %g3: ffd7f018   
%g4: 0028   %g5:    %g6:    %g7:    
Current Register Window:
%o0: 000a   %o1: 0022d570   %o2: ffd3b8a6   %o3: ffdd2ce0   
%o4: ffd08568   %o5: ffd08578   %o6: ffdd2a30   %o7: ffd0100c   
%l0: ffd7f15c   %l1: 4000   %l2: 4004   %l3: ffd3c000   
%l4: ffd7f000   %l5: ffd7f000   %l6: ffd80c00   %l7: ffd0   
%i0: ffd7f15c   %i1:    %i2:    %i3:    
%i4:    %i5:    %i6: ffdd2c98   %i7: ffd06310   

Floating Point Registers:
%f00: 0.00 0.00 0.00 0.00
%f04: 0.00 0.00 0.00 0.00
%f08: 0.00 0.00 0.00 0.00
%f12: 0.00 0.00 0.00 0.00
%f16: 0.00 0.00 0.00 0.00
%f20: 0.00 0.00 0.00 0.00
%f24: 0.00 0.00 0.00 0.00
%f28: 0.00 0.00 0.00 0.00
psr: 0x04401fc2 -> Z--- SP- wim: 0x0010
fsr: 0x0008
./qemu-nog: line 4:  5400 Aborted qemu-system-sparc -kernel 
vmlinux-2.6.11+tcx -initrd linux.img -append "root=/dev/ram console=ttyS0 
video=tcxfb:off" -nographic

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Thiemo Seufer]

Blue Swirl wrote:
[snip]
> > > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > > There are no caches or cycle counters and hardware devices run
> > > unrealistically fast from CPU standpoint. Emulating performance
> > > counters or the errata the most CPUs have would be extremely
> > > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > > BIOSes.
> >
> > I am working on making the Malta emulation boot a unaltered YAMON
> > image. I don't see why a PC BIOS would be harder to accomodate.
> 
> Emulating microcode, or firmware blobs loaded to misc devices. Think
> writing a BIOS for Transmeta,

Writing the emulation for a transmeta is IMHO more challenging than
writing the "BIOS". Btw, if you are interested in the x86 mode, you can
handle the transmeta just as a x86 variant (with a much more standard BIOS).

> Alpha or a SoC.

Writing "Firmware for a SoC" is part of my dayjob.

> > > Real BIOSes are also closed source, proprietary binary blobs.
> >
> > At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> > license which - I hope - will change.
> >
> > > Making open source BIOSes a viable alternative is in my opinion a much
> > > more important goal.
> >
> > The one doesn't exclude the other. That said, I regard the ability to
> > boot unaltered real-world firmare as an important test of the quality
> > of a system emulation.
> 
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?

Improve the emulation to handle at least one probing path.


Thiemo

[Qemu-devel] qemu/target-ppc op.c

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/01 21:51:40

Modified files:
target-ppc : op.c 

Log message:
Fix nasty sign-extensions when running 32 bits CPU in the 64 bits 
emulator
on 32 bits hosts.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.52&r2=1.53

[Qemu-devel] qemu/target-ppc cpu.h helper.c op.c

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/01 21:49:57

Modified files:
target-ppc : cpu.h helper.c op.c 

Log message:
Fix reproductible crash: call cpu_loop_exit from micro-op, not from 
helper.c

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.68&r2=1.69
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.63&r2=1.64
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.51&r2=1.52

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Laurent Desnogues]

Aurelien Jarno a écrit :

Maybe. The CPU probes for cacheline size, checks for errata #42 vs
#45, reads debug registers, attempts to identify the bus speed by
comparing I/O access times, tries to verify the system using a TPM and
fails all cases. What can you do?


Emulate a simpler architecture like mips or arm? ;-)


I don't think ARM qualifies as a simple architecture, it certainly
isn't in the same league as MIPS, at least not ARMv6 and ARMv7 :)


Laurent

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Aurelien Jarno]

Blue Swirl a écrit :
> On 10/1/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
>> Blue Swirl wrote:

>> The one doesn't exclude the other. That said, I regard the ability to
>> boot unaltered real-world firmare as an important test of the quality
>> of a system emulation.
> 
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?

Emulate a simpler architecture like mips or arm? ;-)

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Fabrice Bellard]

Blue Swirl wrote:

On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:

On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:

On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:

Am 01.10.2007 um 09:12 schrieb Bob Deblier:


Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
working on this?

I had looked into this recently but it turned out that PearPC and
others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
incompatible with QEMU, expecting some raw image. I have no idea how
to go about this; the (working) sparc version uses some "weird"
assembler initializations. ;-)

You can use:
objcopy -O binary in.elf out.bin

Alternatively, Qemu could be enhanced to try loading ELF first and
binary if that fails.

This is even not an option. With "normal" full system emulation, Qemu
boots like real hardware does. I don't know any CPU able to load ELF
images. As the goal is to emulate real hardware, what is to be given is
a ROM image, able to boot a real machine.


The effect is exactly the same from the emulated CPU perspective. With
ELF image we gain symbols in the out_asm dump.


You can try to ehance the -kernel option to do weird hacks if you like
but the CPU state at the start of a normal boot process should be as
near as possible as a real CPU after a hard reset. Any other behavior is
a bug to fix asap.
Imho Qemu can be a very great development tool (and I already used it
for this purpose), not just a geek toy, then hacks that do not reflect
what real hardware does have to be avoided any time it's possible. Then,
adding an ELF loader in the CPU initialisation code seems to be a
nonsense. The goal to achieve, imho, is to be able to run real ROM
images extracted from real machine, not to "extend" the CPU features
with stuffs that has no reality (and are even not useful as long as no
machine would never accept to boot on this "firmware").


Qemu is not limited to just hardware emulation. Please consider for
example snapshot load/save support, built-in gdbstub and monitor. No
real hardware has any of these, or perhaps you could do similar things
with ICE or JTAG.

Qemu is not also aimed for 100% accurate emulation of the hardware.
There are no caches or cycle counters and hardware devices run
unrealistically fast from CPU standpoint. Emulating performance
counters or the errata the most CPUs have would be extremely
difficult. I doubt Qemu CPU emulation can ever pass POST of real
BIOSes. Real BIOSes are also closed source, proprietary binary blobs.
Making open source BIOSes a viable alternative is in my opinion a much
more important goal.


I know at least one real PC BIOS which "almost" work in QEMU. "almost" 
because a few fixes are needed in the PIIX3 bridge and I never found the 
time to publish them. Another point was the timing accuracy which made 
the BIOS hang sometimes, but it can also be solved.



[...]


Fabrice.

[Qemu-devel] [Patch] Fix compiler warnings

[Stefan Weil]

Hello,

this patch fixes some compiler warnings in two QEMU source files:

* missing include unistd.h for syscall

* comparision of unsigned value with -1
  (mmap returns pointer with error value MAP_FAILED)

I also replaced leading tabs in mmap.c by blanks.

Please add this patch to CVS head.

Regards
Stefan

Index: linux-user/mmap.c
===
RCS file: /sources/qemu/qemu/linux-user/mmap.c,v
retrieving revision 1.16
diff -u -b -B -w -u -r1.16 mmap.c
--- linux-user/mmap.c	30 Sep 2007 14:32:45 -	1.16
+++ linux-user/mmap.c	1 Oct 2007 20:15:22 -
@@ -100,7 +100,7 @@
  target_ulong start, target_ulong end,
  int prot, int flags, int fd, target_ulong offset)
 {
-target_ulong real_end, ret, addr;
+target_ulong real_end, addr;
 void *host_start;
 int prot1, prot_new;
 
@@ -116,10 +116,10 @@
 
 if (prot1 == 0) {
 /* no page was there, so we allocate one */
-ret = (long)mmap(host_start, qemu_host_page_size, prot,
+void *p = mmap(host_start, qemu_host_page_size, prot,
  flags | MAP_ANONYMOUS, -1, 0);
-if (ret == -1)
-return ret;
+if (p == MAP_FAILED)
+return -1;
 prot1 = prot;
 }
 prot1 &= PAGE_BITS;
@@ -230,16 +230,16 @@
  */
 target_ulong host_end;
 unsigned long host_aligned_start;
+void *p;
 
 host_len = HOST_PAGE_ALIGN(host_len + qemu_host_page_size
- qemu_real_host_page_size);
-host_start = (unsigned long) mmap(real_start ?
-	  g2h(real_start) : NULL,
-	  host_len, prot, flags,
-	  fd, host_offset);
-if (host_start == -1)
+p = mmap(real_start ? g2h(real_start) : NULL,
+ host_len, prot, flags, fd, host_offset);
+if (p == MAP_FAILED)
 return -1;
 
+host_start = (unsigned long)p;
 host_end = host_start + host_len;
 
 /* Find start and end, aligned to the targets pagesize with-in the
@@ -260,11 +260,12 @@
 goto the_end1;
 } else {
 /* if not fixed, no need to do anything */
-host_start = (long)mmap(real_start ? g2h(real_start) : NULL,
+void *p = mmap(real_start ? g2h(real_start) : NULL,
 host_len, prot, flags, fd, host_offset);
-if (host_start == -1)
+if (p == MAP_FAILED)
 return -1;
 /* update start so that it points to the file position at 'offset' */
+host_start = (unsigned long)p;
 if (!(flags & MAP_ANONYMOUS))
 host_start += offset - host_offset;
 start = h2g(host_start);
@@ -333,14 +334,15 @@
 
 /* map the middle (easier) */
 if (real_start < real_end) {
+void *p;
 unsigned long offset1;
 	if (flags & MAP_ANONYMOUS)
 	  offset1 = 0;
 	else
 	  offset1 = offset + real_start - start;
-ret = (long)mmap(g2h(real_start), real_end - real_start,
+p = mmap(g2h(real_start), real_end - real_start,
  prot, flags, fd, offset1);
-if (ret == -1)
+if (p == MAP_FAILED)
 return -1;
 }
  the_end1:
Index: target-i386/helper2.c
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.52
diff -u -b -B -w -u -r1.52 helper2.c
--- target-i386/helper2.c	23 Sep 2007 15:28:04 -	1.52
+++ target-i386/helper2.c	1 Oct 2007 20:15:22 -
@@ -32,6 +32,7 @@
 //#define DEBUG_MMU
 
 #ifdef USE_CODE_COPY
+#include 
 #include 
 #include 
 #include 

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[J. Mayer]

On Mon, 2007-10-01 at 22:31 +0300, Blue Swirl wrote:
> On 10/1/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> > Blue Swirl wrote:
> > > On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > > > On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > > > >
> > > > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is 
> > > > > > > anyone
> > > > > > > working on this?
> > > > > >
> > > > > > I had looked into this recently but it turned out that PearPC and
> > > > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > > > to go about this; the (working) sparc version uses some "weird"
> > > > > > assembler initializations. ;-)
> > > > >
> > > > > You can use:
> > > > > objcopy -O binary in.elf out.bin
> > > > >
> > > > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > > > binary if that fails.
> > > >
> > > > This is even not an option. With "normal" full system emulation, Qemu
> > > > boots like real hardware does. I don't know any CPU able to load ELF
> > > > images. As the goal is to emulate real hardware, what is to be given is
> > > > a ROM image, able to boot a real machine.
> >
> > FWIW, I don't regard the on-disk format of the BIOS as essential, as
> > long as the emulated CPU sees the same bits as a real cpu does.
> >
> > Accepting ELF as a (possibly alternative) container for a BIOS image
> > is a matter of convenience.

If it would really bring extra features, why not. But what does booting
from ELF brings ? Debug symbols ? GDB is the right tool to use them and
does not need the boot to be from an ELF file. Symbols in qemu.log are
not so useful as, at least for me, it is an great help to debug qemu
itself, but not very useful to debug the running code, excluding maybe
for the starter code, for which you can easily follow the asm code.

> > > The effect is exactly the same from the emulated CPU perspective. With
> > > ELF image we gain symbols in the out_asm dump.
> > >
> > > > You can try to ehance the -kernel option to do weird hacks if you like
> > > > but the CPU state at the start of a normal boot process should be as
> > > > near as possible as a real CPU after a hard reset. Any other behavior is
> > > > a bug to fix asap.
> > > > Imho Qemu can be a very great development tool (and I already used it
> > > > for this purpose), not just a geek toy, then hacks that do not reflect
> > > > what real hardware does have to be avoided any time it's possible. Then,
> > > > adding an ELF loader in the CPU initialisation code seems to be a
> > > > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > > > images extracted from real machine, not to "extend" the CPU features
> > > > with stuffs that has no reality (and are even not useful as long as no
> > > > machine would never accept to boot on this "firmware").
> > >
> > > Qemu is not limited to just hardware emulation. Please consider for
> > > example snapshot load/save support, built-in gdbstub and monitor. No
> > > real hardware has any of these, or perhaps you could do similar things
> > > with ICE or JTAG.
> > >
> > > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > > There are no caches or cycle counters and hardware devices run
> > > unrealistically fast from CPU standpoint. Emulating performance
> > > counters or the errata the most CPUs have would be extremely
> > > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > > BIOSes.
> >
> > I am working on making the Malta emulation boot a unaltered YAMON
> > image. I don't see why a PC BIOS would be harder to accomodate.
> 
> Emulating microcode, or firmware blobs loaded to misc devices. Think
> writing a BIOS for Transmeta, Alpha or a SoC.

Being thinking of this for Alpha for a long time (and even started...).
Hope someday I (or someone else) will have the motivation to really do
it ! But Alpha is quite easy as it's quite well documented... I admit it
may be quite impossible for Transmeta...

> > > Real BIOSes are also closed source, proprietary binary blobs.
> >
> > At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> > license which - I hope - will change.
> >
> > > Making open source BIOSes a viable alternative is in my opinion a much
> > > more important goal.
> >
> > The one doesn't exclude the other. That said, I regard the ability to
> > boot unaltered real-world firmare as an important test of the quality
> > of a system emulation.
> 
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?

Most of the actual issues are in the chipset and it seems 

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/1/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> Blue Swirl wrote:
> > On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > > On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > > >
> > > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > > working on this?
> > > > >
> > > > > I had looked into this recently but it turned out that PearPC and
> > > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > > to go about this; the (working) sparc version uses some "weird"
> > > > > assembler initializations. ;-)
> > > >
> > > > You can use:
> > > > objcopy -O binary in.elf out.bin
> > > >
> > > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > > binary if that fails.
> > >
> > > This is even not an option. With "normal" full system emulation, Qemu
> > > boots like real hardware does. I don't know any CPU able to load ELF
> > > images. As the goal is to emulate real hardware, what is to be given is
> > > a ROM image, able to boot a real machine.
>
> FWIW, I don't regard the on-disk format of the BIOS as essential, as
> long as the emulated CPU sees the same bits as a real cpu does.
>
> Accepting ELF as a (possibly alternative) container for a BIOS image
> is a matter of convenience.
>
> > The effect is exactly the same from the emulated CPU perspective. With
> > ELF image we gain symbols in the out_asm dump.
> >
> > > You can try to ehance the -kernel option to do weird hacks if you like
> > > but the CPU state at the start of a normal boot process should be as
> > > near as possible as a real CPU after a hard reset. Any other behavior is
> > > a bug to fix asap.
> > > Imho Qemu can be a very great development tool (and I already used it
> > > for this purpose), not just a geek toy, then hacks that do not reflect
> > > what real hardware does have to be avoided any time it's possible. Then,
> > > adding an ELF loader in the CPU initialisation code seems to be a
> > > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > > images extracted from real machine, not to "extend" the CPU features
> > > with stuffs that has no reality (and are even not useful as long as no
> > > machine would never accept to boot on this "firmware").
> >
> > Qemu is not limited to just hardware emulation. Please consider for
> > example snapshot load/save support, built-in gdbstub and monitor. No
> > real hardware has any of these, or perhaps you could do similar things
> > with ICE or JTAG.
> >
> > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > There are no caches or cycle counters and hardware devices run
> > unrealistically fast from CPU standpoint. Emulating performance
> > counters or the errata the most CPUs have would be extremely
> > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > BIOSes.
>
> I am working on making the Malta emulation boot a unaltered YAMON
> image. I don't see why a PC BIOS would be harder to accomodate.

Emulating microcode, or firmware blobs loaded to misc devices. Think
writing a BIOS for Transmeta, Alpha or a SoC.

> > Real BIOSes are also closed source, proprietary binary blobs.
>
> At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> license which - I hope - will change.
>
> > Making open source BIOSes a viable alternative is in my opinion a much
> > more important goal.
>
> The one doesn't exclude the other. That said, I regard the ability to
> boot unaltered real-world firmare as an important test of the quality
> of a system emulation.

Maybe. The CPU probes for cacheline size, checks for errata #42 vs
#45, reads debug registers, attempts to identify the bus speed by
comparing I/O access times, tries to verify the system using a TPM and
fails all cases. What can you do?

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Thiemo Seufer]

Blue Swirl wrote:
> On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > >
> > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > working on this?
> > > >
> > > > I had looked into this recently but it turned out that PearPC and
> > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > to go about this; the (working) sparc version uses some "weird"
> > > > assembler initializations. ;-)
> > >
> > > You can use:
> > > objcopy -O binary in.elf out.bin
> > >
> > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > binary if that fails.
> >
> > This is even not an option. With "normal" full system emulation, Qemu
> > boots like real hardware does. I don't know any CPU able to load ELF
> > images. As the goal is to emulate real hardware, what is to be given is
> > a ROM image, able to boot a real machine.

FWIW, I don't regard the on-disk format of the BIOS as essential, as
long as the emulated CPU sees the same bits as a real cpu does.

Accepting ELF as a (possibly alternative) container for a BIOS image
is a matter of convenience.

> The effect is exactly the same from the emulated CPU perspective. With
> ELF image we gain symbols in the out_asm dump.
> 
> > You can try to ehance the -kernel option to do weird hacks if you like
> > but the CPU state at the start of a normal boot process should be as
> > near as possible as a real CPU after a hard reset. Any other behavior is
> > a bug to fix asap.
> > Imho Qemu can be a very great development tool (and I already used it
> > for this purpose), not just a geek toy, then hacks that do not reflect
> > what real hardware does have to be avoided any time it's possible. Then,
> > adding an ELF loader in the CPU initialisation code seems to be a
> > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > images extracted from real machine, not to "extend" the CPU features
> > with stuffs that has no reality (and are even not useful as long as no
> > machine would never accept to boot on this "firmware").
> 
> Qemu is not limited to just hardware emulation. Please consider for
> example snapshot load/save support, built-in gdbstub and monitor. No
> real hardware has any of these, or perhaps you could do similar things
> with ICE or JTAG.
> 
> Qemu is not also aimed for 100% accurate emulation of the hardware.
> There are no caches or cycle counters and hardware devices run
> unrealistically fast from CPU standpoint. Emulating performance
> counters or the errata the most CPUs have would be extremely
> difficult. I doubt Qemu CPU emulation can ever pass POST of real
> BIOSes.

I am working on making the Malta emulation boot a unaltered YAMON
image. I don't see why a PC BIOS would be harder to accomodate.

> Real BIOSes are also closed source, proprietary binary blobs.

At least YAMON, CFE and PMON are not closed source. YAMON has a funny
license which - I hope - will change.

> Making open source BIOSes a viable alternative is in my opinion a much
> more important goal.

The one doesn't exclude the other. That said, I regard the ability to
boot unaltered real-world firmare as an important test of the quality
of a system emulation.


Thiemo

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[J. Mayer]

On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
> Jocelyn Mayer wrote:
> > CVSROOT:/sources/qemu
> > Module name:qemu
> > Changes by: Jocelyn Mayer  07/10/01 06:44:33
> >
> > Modified files:
> > pc-bios: ppc_rom.bin 
> >
> > Log message:
> > Quickly hack PowerPC BIOS able to boot on CDROM again.
> >
> > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
> >
> >
> >   
> 
> There really should be a pointer to the sources used to generate this. 
> Ideally the full sources.

To answer to this, I can say I did took the sources from the version 0.4.1
http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4.1.tar.bz2
and did a hacky mix with the patch from Fabrice, commited in Qemu (which
has good things but also breaks some features) and quick "minute" fixes.
The fact is that the online version of OHW is really outdated but my
working repository is not in a stable state and seems absolutelly not
usable as it is, then I'd prefer not to make it public for now...

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

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Jocelyn Mayer]

On Mon, 2007-10-01 at 19:36 +0300, Blue Swirl wrote:
> On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > >
> > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > working on this?
> > > >
> > > > I had looked into this recently but it turned out that PearPC and
> > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > to go about this; the (working) sparc version uses some "weird"
> > > > assembler initializations. ;-)
> > >
> > > You can use:
> > > objcopy -O binary in.elf out.bin
> > >
> > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > binary if that fails.
> >
> > This is even not an option. With "normal" full system emulation, Qemu
> > boots like real hardware does. I don't know any CPU able to load ELF
> > images. As the goal is to emulate real hardware, what is to be given is
> > a ROM image, able to boot a real machine.
> 
> The effect is exactly the same from the emulated CPU perspective. With
> ELF image we gain symbols in the out_asm dump.
> 
> > You can try to ehance the -kernel option to do weird hacks if you like
> > but the CPU state at the start of a normal boot process should be as
> > near as possible as a real CPU after a hard reset. Any other behavior is
> > a bug to fix asap.
> > Imho Qemu can be a very great development tool (and I already used it
> > for this purpose), not just a geek toy, then hacks that do not reflect
> > what real hardware does have to be avoided any time it's possible. Then,
> > adding an ELF loader in the CPU initialisation code seems to be a
> > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > images extracted from real machine, not to "extend" the CPU features
> > with stuffs that has no reality (and are even not useful as long as no
> > machine would never accept to boot on this "firmware").
> 
> Qemu is not limited to just hardware emulation. Please consider for
> example snapshot load/save support, built-in gdbstub and monitor. No
> real hardware has any of these, or perhaps you could do similar things
> with ICE or JTAG.

gdbstub and monitor like features are available with (usually)
proprietary debug tools on most hardwares I know. Most of the
development environment have many more features than Qemu currently
implements. It would be really great if Qemu would be able to become a
tool that could replace all those proprietary tools, but we are really
very far from this point.
I've never seen snapshot and load/store features on real hardware but it
seems to be doable with available debug tools. I did things quite like
that with JTAG scripts sometimes (CPU, RAM and a few simple devices
initialisation, cause I would have been to lazy to do more !).
But I also have to admit those are features I never use in Qemu...

> Qemu is not also aimed for 100% accurate emulation of the hardware.
> There are no caches or cycle counters and hardware devices run
> unrealistically fast from CPU standpoint. Emulating performance
> counters or the errata the most CPUs have would be extremely
> difficult.

I never said that it's a full accurate emulation. I just said 'the
closest as possible to the real machine'. Which means from the execution
context point of view it has to have the same behavior, not that we
emulate every internal hardware states. Having other behaviors that are
not present on the real hardware can be fun but it gives nothing in
terms of emulation.

>  I doubt Qemu CPU emulation can ever pass POST of real
> BIOSes.

This is an admission of failure...

>From my point of view, it's a requirement that Qemu would be able:
1/ to be used to develop new firmwares and systems
2/ to be as accurate as needed so a firmware developped under Qemu would
run without modification on real hardware (means, takes the binary
image, flash it and power on, it runs...)
3/ would be able to run proprietary firmware, especially when trying to
emulate some targets with non-documented "blackboxes" that cannot be
easily reimplemented in OSS firmwares due to a lack of documentation, or
to "discover" hardware on which it's not easy to find any available OSS
distribution.

As an example, my goal, while implementing PowerPC 4xx targets, is to
take raw binary proprietary flash images from misc vendors and (try to)
run them without modification. For now, I'm able to run one of those.
Each other one I would be able to run would proove the emulation is
getting more accurate and is going to become really usable for any
usage.
It's even almost the only way I have to do it because there are
currently not a single complete OSS environment which I can get from the
net and boot at once for validation.
But Qemu may also be a great chance t

[Qemu-devel] qemu/target-sparc op_helper.c

[Blue Swirl]

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/10/01 17:07:58

Modified files:
target-sparc   : op_helper.c 

Log message:
 Fix block load ASIs

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.40&r2=1.41

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
> > >
> > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > >
> > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > working on this?
> > >
> > > I had looked into this recently but it turned out that PearPC and
> > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > to go about this; the (working) sparc version uses some "weird"
> > > assembler initializations. ;-)
> >
> > You can use:
> > objcopy -O binary in.elf out.bin
> >
> > Alternatively, Qemu could be enhanced to try loading ELF first and
> > binary if that fails.
>
> This is even not an option. With "normal" full system emulation, Qemu
> boots like real hardware does. I don't know any CPU able to load ELF
> images. As the goal is to emulate real hardware, what is to be given is
> a ROM image, able to boot a real machine.

The effect is exactly the same from the emulated CPU perspective. With
ELF image we gain symbols in the out_asm dump.

> You can try to ehance the -kernel option to do weird hacks if you like
> but the CPU state at the start of a normal boot process should be as
> near as possible as a real CPU after a hard reset. Any other behavior is
> a bug to fix asap.
> Imho Qemu can be a very great development tool (and I already used it
> for this purpose), not just a geek toy, then hacks that do not reflect
> what real hardware does have to be avoided any time it's possible. Then,
> adding an ELF loader in the CPU initialisation code seems to be a
> nonsense. The goal to achieve, imho, is to be able to run real ROM
> images extracted from real machine, not to "extend" the CPU features
> with stuffs that has no reality (and are even not useful as long as no
> machine would never accept to boot on this "firmware").

Qemu is not limited to just hardware emulation. Please consider for
example snapshot load/save support, built-in gdbstub and monitor. No
real hardware has any of these, or perhaps you could do similar things
with ICE or JTAG.

Qemu is not also aimed for 100% accurate emulation of the hardware.
There are no caches or cycle counters and hardware devices run
unrealistically fast from CPU standpoint. Emulating performance
counters or the errata the most CPUs have would be extremely
difficult. I doubt Qemu CPU emulation can ever pass POST of real
BIOSes. Real BIOSes are also closed source, proprietary binary blobs.
Making open source BIOSes a viable alternative is in my opinion a much
more important goal.

Maybe there is some misunderstanding, the change amounts to this:

 bios_offset = ram_size + vga_ram_size;
 snprintf(buf, sizeof(buf), "%s/%s", bios_dir, BIOS_FILENAME);
-bios_size = load_image(buf, phys_ram_base + bios_offset);
+bios_size = load_elf(buf, 0, NULL, NULL, NULL);
+if (bios_size < 0)
+bios_size = load_image(buf, phys_ram_base + bios_offset);
 if (bios_size < 0 || bios_size > BIOS_SIZE) {
 cpu_abort(env, "qemu: could not load PPC PREP bios '%s'\n", buf);

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Jocelyn Mayer]

On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
> >
> > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> >
> > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > working on this?
> >
> > I had looked into this recently but it turned out that PearPC and
> > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > incompatible with QEMU, expecting some raw image. I have no idea how
> > to go about this; the (working) sparc version uses some "weird"
> > assembler initializations. ;-)
> 
> You can use:
> objcopy -O binary in.elf out.bin
> 
> Alternatively, Qemu could be enhanced to try loading ELF first and
> binary if that fails.

This is even not an option. With "normal" full system emulation, Qemu
boots like real hardware does. I don't know any CPU able to load ELF
images. As the goal is to emulate real hardware, what is to be given is
a ROM image, able to boot a real machine.
You can try to ehance the -kernel option to do weird hacks if you like
but the CPU state at the start of a normal boot process should be as
near as possible as a real CPU after a hard reset. Any other behavior is
a bug to fix asap.
Imho Qemu can be a very great development tool (and I already used it
for this purpose), not just a geek toy, then hacks that do not reflect
what real hardware does have to be avoided any time it's possible. Then,
adding an ELF loader in the CPU initialisation code seems to be a
nonsense. The goal to achieve, imho, is to be able to run real ROM
images extracted from real machine, not to "extend" the CPU features
with stuffs that has no reality (and are even not useful as long as no
machine would never accept to boot on this "firmware").

[Qemu-devel] typo in qemu_next_deadline()

[Dan Kenigsberg]

(int64_t)UINT64_MAX is -1 and should not be assigned to nearest_delta_us

Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.343
diff -u -p -r1.343 vl.c
--- vl.c29 Sep 2007 19:24:40 -  1.343
+++ vl.c1 Oct 2007 14:55:05 -
@@ -1181,7 +1179,7 @@ static void host_alarm_handler(int host_
 
 static uint64_t qemu_next_deadline(void)
 {
-int64_t nearest_delta_us = UINT64_MAX;
+int64_t nearest_delta_us = INT64_MAX;
 int64_t vmdelta_us;
 
 if (active_timers[QEMU_TIMER_REALTIME])

[Qemu-devel] redundant qemu_rearm_alarm_timer() in qemu_del_timer()

[Dan Kenigsberg]

There is no need to rearm the alarm timer when a qemu timer is deleted.
The current code contains a redundant rearm whenever qemu_del_timer() is used,
which is very often - in every qemu_mod_timer(). 
The rearm in qemu_mod_timer() is redundant because a currently-set timer
could not be brought forward due to delete - only postponed. And postponing the
timer is better done once in the end of qemu_run_timers().

Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.343
diff -u -p -r1.343 vl.c
--- vl.c29 Sep 2007 19:24:40 -  1.343
+++ vl.c1 Oct 2007 14:13:01 -
@@ -988,8 +988,6 @@ void qemu_del_timer(QEMUTimer *ts)
 }
 pt = &t->next;
 }
-
-qemu_rearm_alarm_timer(alarm_timer);
 }
 
 /* modify the current timer so that it will be fired when current_time

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
>
> Am 01.10.2007 um 09:12 schrieb Bob Deblier:
>
> > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > working on this?
>
> I had looked into this recently but it turned out that PearPC and
> others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> incompatible with QEMU, expecting some raw image. I have no idea how
> to go about this; the (working) sparc version uses some "weird"
> assembler initializations. ;-)

You can use:
objcopy -O binary in.elf out.bin

Alternatively, Qemu could be enhanced to try loading ELF first and
binary if that fails.

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Andreas Färber]

Am 01.10.2007 um 09:12 schrieb Bob Deblier:


Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
working on this?


I had looked into this recently but it turned out that PearPC and  
others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is  
incompatible with QEMU, expecting some raw image. I have no idea how  
to go about this; the (working) sparc version uses some "weird"  
assembler initializations. ;-)


Me too, I believe that OpenBIOS would be a better long-term solution.  
Maybe OHW can be merged into OpenBIOS for not having to start from zero?


Andreas

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Bob Deblier]

On Mon, 2007-10-01 at 13:40 +0200, Aurelien Jarno wrote:
> Bob Deblier a écrit :
> > On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
> >> Jocelyn Mayer wrote:
> >>> CVSROOT:  /sources/qemu
> >>> Module name:  qemu
> >>> Changes by:   Jocelyn Mayer  07/10/01 06:44:33
> >>>
> >>> Modified files:
> >>>   pc-bios: ppc_rom.bin 
> >>>
> >>> Log message:
> >>>   Quickly hack PowerPC BIOS able to boot on CDROM again.
> >>>
> >>> CVSWeb URLs:
> >>> http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
> >>>
> >>>
> >>>   
> >> There really should be a pointer to the sources used to generate this. 
> >> Ideally the full sources.
> > 
> > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > working on this?
> > 
> 
> I have given a quick look, enough to know that's it is not just a matter
> of compiling the current PowerPC code and feed it to QEMU. The way
> OpenBIOS, OpenHackware and PearPC are too different.
> 
> Unfortunately I won't have time to work further on this before roughly 2
> months.
> 
> Cheers,
> Aurelien

Okay - I'm perfectly willing to start and/or help working on this. My
question was just to avoid duplicating work.

Thanks,

Bob

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Aurelien Jarno]

Bob Deblier a écrit :
> On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
>> Jocelyn Mayer wrote:
>>> CVSROOT:/sources/qemu
>>> Module name:qemu
>>> Changes by: Jocelyn Mayer  07/10/01 06:44:33
>>>
>>> Modified files:
>>> pc-bios: ppc_rom.bin 
>>>
>>> Log message:
>>> Quickly hack PowerPC BIOS able to boot on CDROM again.
>>>
>>> CVSWeb URLs:
>>> http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
>>>
>>>
>>>   
>> There really should be a pointer to the sources used to generate this. 
>> Ideally the full sources.
> 
> Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> working on this?
> 

I have given a quick look, enough to know that's it is not just a matter
of compiling the current PowerPC code and feed it to QEMU. The way
OpenBIOS, OpenHackware and PearPC are too different.

Unfortunately I won't have time to work further on this before roughly 2
months.

Cheers,
Aurelien

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Bob Deblier]

On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
> Jocelyn Mayer wrote:
> > CVSROOT:/sources/qemu
> > Module name:qemu
> > Changes by: Jocelyn Mayer  07/10/01 06:44:33
> >
> > Modified files:
> > pc-bios: ppc_rom.bin 
> >
> > Log message:
> > Quickly hack PowerPC BIOS able to boot on CDROM again.
> >
> > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
> >
> >
> >   
> 
> There really should be a pointer to the sources used to generate this. 
> Ideally the full sources.

Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
working on this?

Sincerely,

Bob Deblier

Re: [Qemu-devel] qcow2 vs. image file format --> pci device

[Dor Laor]

Clemens Kolbitsch wrote:

Clemens Kolbitsch wrote:


hi everyone!
i have a strange problem (at least to me it seems strange :-)  ):

i have implemented a pci device (Network IC) and it works just fine when
using a standard image. however i now want to support snapshotting...

i started to convert my image into the qcow2 format and suddenly my code
does not work any more... even if i uncomment everything that has to do
with snapshotting in my code, it still blocks during qemu startup.

the thing that could cause this: i use 2 additional threads in my NIC
code ... each is working with semaphores that might cause problems.

is there something in particular i have to be careful of when using qcow2
file format?

thanks!!
  

Qcow2 uses async io which triggers io completion with SIGIO signal.
If you use threads you must mask this (and also SIGALARM, ..) so your
thread won't
take over the main threads handling.
Anyway, using threads is not the standard qemu guideline.



Hi,
Ok.. thanks! How do I tell Qemu that I use threads (in this case I don't see 
an easy way around using them... although there is one obviously ;-) )??


  
All other NIC emulation work without threads. They use select 
(qemu_set_fd_handler)

In what other HW example can I see how to use the SIGIO completion stuff?
  
Actually I had a mistake, qemu use SIGUSR2 for async io and SIGIO for 
timer management.

Clemens

  

Re: Re: [Qemu-devel] qcow2 vs. image file format --> pci device

[Clemens Kolbitsch]

> Clemens Kolbitsch wrote:
> > hi everyone!
> > i have a strange problem (at least to me it seems strange :-)  ):
> >
> > i have implemented a pci device (Network IC) and it works just fine when
> > using a standard image. however i now want to support snapshotting...
> >
> > i started to convert my image into the qcow2 format and suddenly my code
> > does not work any more... even if i uncomment everything that has to do
> > with snapshotting in my code, it still blocks during qemu startup.
> >
> > the thing that could cause this: i use 2 additional threads in my NIC
> > code ... each is working with semaphores that might cause problems.
> >
> > is there something in particular i have to be careful of when using qcow2
> > file format?
> >
> > thanks!!
>
> Qcow2 uses async io which triggers io completion with SIGIO signal.
> If you use threads you must mask this (and also SIGALARM, ..) so your
> thread won't
> take over the main threads handling.
> Anyway, using threads is not the standard qemu guideline.

Hi,
Ok.. thanks! How do I tell Qemu that I use threads (in this case I don't see 
an easy way around using them... although there is one obviously ;-) )??

In what other HW example can I see how to use the SIGIO completion stuff?
Clemens

RE: [Qemu-devel] EHCI emulation patch

[Per Åstrand]

Ok! I'll cross my fingers and hope they'll be finished soon then...

I saw that you too are working on a ehci emulation patch. How is that coming
along?

/Per

-Original Message-
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of
Arnon Gilboa
Sent: söndag den 30 september 2007 12:02
To: qemu-devel@nongnu.org
Subject: RE: [Qemu-devel] EHCI emulation patch

I was in contact with Mark about 2 month ago. He told me that the company he
has developed the ehci emulation for won't let him release to open source
until the project is finished, which looks to be end of 2007 at least.  If
that changes he'll post the patch to the list.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Per
?strand
Sent: Friday, September 28, 2007 11:00 AM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] EHCI emulation patch


Hi!

Has anyone seen the ehci emulation patch lately? I have tried to find it,
but so far no luck!

Help, anyone?

Mark, are you still there?

/Per


On 12/24/06, Mark B <
[EMAIL PROTECTED]  > wrote:
> Dear list,
>
> Just a quick note to let you know I have almost finished an
implementation
> of an EHCI host controller for USB (usb-ehci.c) for qemu. I am testing
with

> an XP guest and so far I have a mass storage flash key, a mouse and a
tablet
> working. I haven't yet implemented isochronous or split transactions
> though. It doesn't do companion controller hand-offs for low or full
speed

> devices either but Windows XP doesn't mind that I am attaching
low/full
> speed devices through EHCI (I believe Linux guests won't like this).
>
> I have asked the company I am working for to give me permission to GPL
the

> module and so far they are agreeable. So I am planning to clean up and
have
> an initial version for check in early in the new year. If anyone has
any
> inputs, please do let me know. I'm new to qemu development so am not
sure

> of checkin etiquette, etc. Pointers in that regard appreciated too.
>
> Cheers,
>
> Mark
>
>
>
>
> ___
> Qemu-devel mailing list

> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

[Qemu-devel] unubscribe

[Ronald]

unubscribe jjQ6hDYc [EMAIL PROTECTED]