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
