Re: [Qemu-devel] [PATCH 3/3] disk: don't read from disk until the guest starts

[Avi Kivity]

 On 09/12/2010 05:29 PM, Anthony Liguori wrote:
> On 09/12/2010 08:26 AM, Avi Kivity wrote:
> >  On 09/12/2010 03:08 PM, Anthony Liguori wrote:
> > > > This can cause a disk read, no?  Shouldn't it be made asynchronous?
> > >
> > >
> > > Yes, it should.  I'm not sure there's an easy way to make it 
> > > asynchronous though not because of the block layer but because of 
> > > how these functions are called.
> >
> > Sorry to harp on the subject, but that's the standard problem with 
> > state machines.  Every time you want to do a blocking operation in a 
> > function, you have to put all its locals in some structure, split the 
> > function into two, do some scheduling, etc.
>
> We can't block the VCPU thread for arbitrarily long periods of time.  
> If we get a PIO operation requesting information about geometry, we 
> can't wait for a disk read in order to satisfy that request.
>
> We need to kick off the I/O operations in the background such that the 
> data is available before the PIO operation happens.  This isn't SM vs. 
> threads at all, this is simply about the fact that we can't do block 
> I/O during a PIO operation.

Isn't this an identify command, where the guest can only read the data 
after the interface indicates it is ready (or posts an interrupt)?  I 
thought the guest interface was already async.

The code appears to support this:

        switch(val) {
        case WIN_IDENTIFY:
            if (s->bs && s->drive_kind != IDE_CD) {
                if (s->drive_kind != IDE_CFATA)
                    ide_identify(s);
                else
                    ide_cfata_identify(s);
                s->status = READY_STAT | SEEK_STAT;
                ide_transfer_start(s, s->io_buffer, 512, 
ide_transfer_stop);
            } else {
                if (s->drive_kind == IDE_CD) {
                    ide_set_signature(s);
                }
                ide_abort_command(s);
            }
            ide_set_irq(s->bus);
            break;

but I may be misinterpreting it.  If I'm right, all we need to do is 
push this whole block to a thread.

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