Paul Brook | 1 Nov 2006 01:01
Gravatar

Re: qemu vs gcc4

> Where's the shift?  I think the above code means you generate an immediate
> value (the 2), add it to R2 with the result going in a spill register, and
> then add the spill register to R1, with the result going to R0.  Should
> that middle line be some kind of gen_op_lshift32() instead of
> gen_op_add32()?

Yes.

> Do qregs ever get freed?  (I'm guessing gen_new_qreg() lasts until the end
> of the translated block, and then the next block has its own set of qregs?)

Correct.

Paul
Rob Landley | 1 Nov 2006 01:00

Re: qemu vs gcc4

On Tuesday 31 October 2006 5:08 pm, Paul Brook wrote:
> On Tuesday 31 October 2006 20:41, Rob Landley wrote:
> > Welcome to Stupid Question Theatre!  With your host, Paul Brook.  Today's
> > contestant is: Rob Landley.  How dumb will it get?

Bonus round!

> > I thought what you were doing was replacing the pregenerated blocks with
> > hand-coded assembly statements, but your description here seems to be 
about
> > changing the disassembly routines that figure out which qops to string
> > together in part 2.
> 
> Replacing the pregenerated blocks with hand written assembly isn't feasible. 
> Each target has its own set of ops, and each host would need its own
> assembly implementation of those ops. Multiply 11 targets by 11 hosts and
> you get a unmaintainable mess :-)

Actually it sounds additive rather than multiplicative.  Does each target have 
an entirely unrelated set of ops, or is there a shared set of primitive ops 
plus some oddballs?

But backing up and just accepting that for a moment, in theory what you need 
is some way to compile a C function to machine code, and then unwrap that 
function into a .raw file containing just the machine code.  So the only 
per-compiler thing would be this unwrapper thingy.  But I already know that 
doesn't work because it doesn't explain the "unable to find spill register" 
problem.  Presumably, just beating the right .raw contents out of the 
compiler is nontrivial, let alone unwrapping it...

(Continue reading)

Paul Brook | 1 Nov 2006 01:29
Gravatar

Re: qemu vs gcc4

> Actually it sounds additive rather than multiplicative.  Does each target
> have an entirely unrelated set of ops, or is there a shared set of
> primitive ops plus some oddballs?

The shared set of primitive ops is basically qops :-)
You probably could figure out a single common qet of qops, then write assembly 
and glue them together like we do with dyngen. However once you've done that 
you've implemented most of what's needed for fully dynamic qops, so it 
doesn't really seem worth it.

> But backing up and just accepting that for a moment, in theory what you
> need is some way to compile a C function to machine code, and then unwrap
> that function into a .raw file containing just the machine code.  So the
> only per-compiler thing would be this unwrapper thingy.  

Right.

> But I already know 
> that doesn't work because it doesn't explain the "unable to find spill
> register" problem. 

That a separate gcc bug. It gets stuck when you tell it not to use half the 
registers, then ask it to do 64-bit math. This is one of the reasons 
eliminating the fixed registers is a good idea.

> > It corresponds to "T0" in dyngen. In addition to the actual CPU state,
> > dyngen
> > uses 3 fixed register as scratch workspace. for qop purposes these are
> > part of the guest CPU state. They're only there to aid conversion of the
> > translation code, they'll go away eventually.
(Continue reading)

Paul Brook | 1 Nov 2006 02:44
Gravatar

qemu vl.c

CVSROOT:	/sources/qemu
Module name:	qemu
Changes by:	Paul Brook <pbrook>	06/11/01 01:44:16

Modified files:
	.              : vl.c 

Log message:
	Remove FD on close.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.217&r2=1.218
Rob Landley | 1 Nov 2006 02:51

Re: qemu vs gcc4

On Tuesday 31 October 2006 7:29 pm, Paul Brook wrote:
> > Actually it sounds additive rather than multiplicative.  Does each target
> > have an entirely unrelated set of ops, or is there a shared set of
> > primitive ops plus some oddballs?
> 
> The shared set of primitive ops is basically qops :-)
> You probably could figure out a single common qet of qops, then write 
assembly 
> and glue them together like we do with dyngen. However once you've done that 
> you've implemented most of what's needed for fully dynamic qops, so it 
> doesn't really seem worth it.

I missed a curve.  What's "fully dynamic qops"?  (There's no translation 
cache?)

> > But I already know 
> > that doesn't work because it doesn't explain the "unable to find spill
> > register" problem. 
> 
> That a separate gcc bug. It gets stuck when you tell it not to use half the 
> registers, then ask it to do 64-bit math. This is one of the reasons 
> eliminating the fixed registers is a good idea.

Sigh.  The problems motivating me to learn the code are highly esoteric 
breakage, yet I'm still not quite up to the task of understanding what's 
going on when all this works _right_.  Grumble... 

> > > It corresponds to "T0" in dyngen. In addition to the actual CPU state,
> > > dyngen
> > > uses 3 fixed register as scratch workspace. for qop purposes these are
(Continue reading)

Paul Brook | 1 Nov 2006 04:22
Gravatar

Re: qemu vs gcc4

On Wednesday 01 November 2006 01:51, Rob Landley wrote:
> On Tuesday 31 October 2006 7:29 pm, Paul Brook wrote:
> > > Actually it sounds additive rather than multiplicative.  Does each
> > > target have an entirely unrelated set of ops, or is there a shared set
> > > of primitive ops plus some oddballs?
> >
> > The shared set of primitive ops is basically qops :-)
> > You probably could figure out a single common qet of qops, then write
>
> assembly
>
> > and glue them together like we do with dyngen. However once you've done
> > that you've implemented most of what's needed for fully dynamic qops, so
> > it doesn't really seem worth it.
>
> I missed a curve.  What's "fully dynamic qops"?  (There's no translation
> cache?)

I mean all the qop stuff I've implemented.

> > > > It corresponds to "T0" in dyngen. In addition to the actual CPU
> > > > state, dyngen
> > > > uses 3 fixed register as scratch workspace. for qop purposes these
> > > > are part of the guest CPU state. They're only there to aid conversion
> > > > of the translation code, they'll go away eventually.
> > >
> > > Presumably the m68k target is pure qop, and hasn't got this sort of
> > > thing?
> >
> > Correct.
(Continue reading)

Alessandro Corradi | 1 Nov 2006 10:19
Picon

Fwd: Interrupt request info



---------- Forwarded message ----------
From: Alessandro Corradi <ale.corradi <at> gmail.com>
Date: 31-ott-2006 10.25
Subject: Re: [Qemu-devel] Interrupt request info
To: Rob Landley <rob <at> landley.net>

I already read this, but give no usefull information... and I searched everywhere in the web...
For example, I wrote a module of a simple memory without implementing IRQ... I think it is  an error but it works fine... are IRQ raise in any case???
I look at other code source of implemented hw but for each device there is a differeny way to raise an interrupt (i see).
Is there a standard way to do this?
The following is an excerpt of my simple memory, please can you describe me fastly how can I manage this?

Thank you


struct scmemState {
    uint32_t data;
    uint32_t addr;
    uint32_t control;
    uint32_t comm;

    int irq;
    int irq_pending;
};

scmemState *scmem_init(int base, int irq){
    scmemState *s;

    s=qemu_mallocz(sizeof(scmemState));
    s->irq = irq;
    s->data = 0;
    s->addr = 0;
    s->control = 0;
    ...
}
static void scmem_ioport_write(void *opaque, uint32_t addr, uint32_t val) {
    scmemState *s = opaque;
    addr &= 7;
    switch(addr) {
    case 0:
        cosim(1,DATA,val);
        s->data = val;
        #ifdef SCDEBUG
        printf("Writing at 0x738 (data reg) value= %d\n",val);
        #endif
        break;
    case 1:
        cosim(1,ADDR,val);
        s->addr = val;
        #ifdef SCDEBUG   
        printf("Writing at 0x739 (addr reg) value= %d\n",val);
        #endif
        break;
    case 2:
        cosim(1,CONTROL,val);
        s->control = val;
        #ifdef SCDEBUG   
        printf("Writing at 0x74a (control reg) value= %d\n",val);
        #endif
        break;
    case 3:
        if (val == 0x0003) { //SC socket connection restore
            scmem_restore();
        } else {
            cosim(1,COMM,val);
            s->comm = val;
            #ifdef SCDEBUG   
            printf("Writing at 0x74b (comm reg) value= %d\n",val);
            #endif
        }
        break;
    }
}


2006/10/28, Rob Landley < rob <at> landley.net >:
On Saturday 28 October 2006 5:36 am, Alessandro Corradi wrote:
> Hello,
> Can someone give me detailed information (or a link where it is described)
> how qemu manage hw interrupts?
> I can't find any usefull info about it in QEMU doc.

http://www.qemu.org/qemu-tech.html#SEC18

> ps: Obviously, if these information are already present I apologize me in
> advance, I try to search but nothing was found  :)

The documentation is a bit sparse in places.

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

_______________________________________________
Qemu-devel mailing list
Qemu-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Sylvain Petreolle | 1 Nov 2006 12:53
Picon
Favicon

RE : [PATCH] USB network interface

Hi Thomas,

--- Thomas Sailer <sailer <at> sailer.dynip.lugs.ch> a écrit :

> This patch contains an initial version of an USB network interface
> (RNDIS / CDC Ethernet) emulator. It has been tested with Linux (Fedora
> Core 6). It uses the same vendor and product ID's as the linux gadget
> network device driver, therefore the "linux.inf" file from
> Documentation/usb of a linux-2.6 kernel source archive can be used under
> windows.
> 
> Usage:
> -net user -net nic,model=usb -usbdevicenet:0
> gives you the default setup (i.e. without any -net option), but with the
> USB adapter instead of the default PCI adapter.
> 
> Problems:
> I couldn't so far get it to work under Windows, neither on W2K SP1 nor
> SP2. Although on SP2 it gets a lot farther. Both versions start
> accessing the device, and then sometime an interrupt in terminates with
> USBD_STATUS_INTERNAL_HC_ERROR and then the device more or less hangs. So
> it looks to me like a USB host controller emulation bug or a bug in the
> host controller driver... Maybe someone has an idea...
> 
> 
> Tom

It works beautifully here with Windows XP SP1 if you configure it with static IP and user
redirector.
It works with -net tap too.

Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Run your favorite Windows apps with free ReactOS : http://www.reactos.org
Listen to non-DRMised Music: http://www.jamendo.com
Mihamina Rakotomandimby | 1 Nov 2006 13:42
Picon

some qemu images

Hi,
I put some qemu images online.
http://qemu-image.asso-polyvalente.fr/

Real work is in progress, but I am open to suggestion.
Thanks in advance.
Joseph Miller | 1 Nov 2006 16:29

Mac OS X Guest Support

According to the roadmap,
http://fabrice.bellard.free.fr/qemu/roadmap.html, Mac OS X will be
supported as a guest OS.  May I ask, what is the status of this?

-Joseph

Gmane