Am 07.01.2011 19:24, Jan Kiszka wrote:
> Am 07.01.2011 18:53, Gleb Natapov wrote:
>> On Fri, Jan 07, 2011 at 06:30:57PM +0100, Jan Kiszka wrote:
>>> Am 07.01.2011 18:16, Gleb Natapov wrote:
>>>> On Fri, Jan 07, 2011 at 05:59:34PM +0100, Jan Kiszka wrote:
>>>>> 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.
>>>> It doesn't matter where the code resides as long as it is called on
>>>> reset.
>>>
>>> It technically matters for the build process (vl.c is built once these
>>> days, cpus.c is built per target).
>>>
>> Yes, I understand the build requirement. Runtime behaviour should not
>> change.
>
> Yep, for sure.
>
> BTW, the self-IPI on pending exit request is there for a reason I but.
> In order to complete half-done string-io or something like that? Would
> be the next patch for upstream then.
>
Yeah, it is, just found the confirming commit. It was just not pushed
upstream as well.
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
