Am 07.01.2011 17:53, Gleb Natapov wrote:
> On Fri, Jan 07, 2011 at 04:57:31PM +0100, Jan Kiszka wrote:
>> Hi,
>>
>> does anyone immediately know if this hunk from vl.c
>>
>> @@ -1278,6 +1197,10 @@ void qemu_system_reset_request(void)
>> } else {
>> reset_requested = 1;
>> }
>> + if (cpu_single_env) {
>> + cpu_single_env->stopped = 1;
>> + cpu_exit(cpu_single_env);
>> + }
>> qemu_notify_event();
>> }
>>
>> is (semantically) relevant for upstream as well? IIUC, it ensures that
>> the kvm cpu loop is not continued if an IO access called into
>> qemu_system_reset_request.
>>
> I don't know TCG enough to tell. If TCG can continue vcpu execution
> after io without checking reset_requested then it is relevant for
> upstream too.
I was first of all thinking about kvm upstream, but their handling
differ much less upstream than in current qemu-kvm. Anyway, need to dig
into the details.
>
>> If yes, then it would be a good time to push a patch: these bits will
>> fall to dust on next merge from upstream (vl.c no longer has access to
>> the cpu state).
>>
> On a next merge cpu state will have to be exposed to vl.c then. This
> code cannot be dropped in qemu-kvm.
I think a cleaner approach, even if it's only temporarily required, is
to move that code to cpus.c. That's likely also the way when we need it
upstream. If upstream does not need it, we have to understand why and
maybe adopt its pattern (the ultimate goal is unification anyway).
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
