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.
Or just move it to just before the guest starts?
We don't really have a notion of "guest starts" today although maybe
we should.
Wasn't there some qdev callback that represents this? Faint memory
from the reset thread.
Yes, realize(). I guess that's a reasonable approach.
Regards,
Anthony Liguori
