[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 07/16] apic: Open-code timer save/restore
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH v5 07/16] apic: Open-code timer save/restore |
Date: |
Tue, 20 Dec 2011 02:24:40 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-12-20 01:53, Anthony Liguori wrote:
> On 12/19/2011 06:34 PM, Jan Kiszka wrote:
>> On 2011-12-20 01:31, Anthony Liguori wrote:
>>> On 12/19/2011 05:45 PM, Jan Kiszka wrote:
>>>> On 2011-12-19 23:21, Anthony Liguori wrote:
>>>>> On 12/15/2011 06:33 AM, Jan Kiszka wrote:
>>>>>> To enable migration between accelerated and non-accelerated APIC
>>>>>> models,
>>>>>> we will need to handle the timer saving and restoring specially
>>>>>> and can
>>>>>> no longer rely on the automatics of VMSTATE_TIMER. Specifically,
>>>>>> accelerated model will not start any QEMUTimer.
>>>>>>
>>>>>> This patch therefore factors out the generic bits into
>>>>>> apic_next_timer
>>>>>> and introduces a post-load callback that can be implemented
>>>>>> differently
>>>>>> by both models.
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka<address@hidden>
>>>>>
>>>>> So you basically want the timer to be a dummy field for the in-kernel
>>>>> apic?
>>>>>
>>>>> Can you fix this up in a pre-save routine (put QEMUTimer into a state
>>>>> where there isn't an event pending)?
>>>>
>>>> It is not a dummy field, it contains the proper state in both cases. We
>>>> just need to convert it to an open-coded state to avoid the QEMUTimer
>>>> restoration magic in the in-kernel case (where there must be no
>>>> QEMUTimer).
>>>
>>> So the state gets fed into the kernel instead of userspace?
>>
>> Nope. It's kept for eventual use by a user space model.
>
> I think you misunderstood my comments.
>
> When you are using the in-kernel APIC, the is no implementation for the
> post_load hook. As far as I can tell, the state isn't used.
Correct, it's just kept up to date.
>
> I know it's used by the user space model but from what I can tell, the
> value is essentially sync with the in-kernel APIC almost immediately as
> it happens during KVM_RUN.
>
> So it's a QEMUTimer in the userspace model, but it's just an integer
> when used in the in-kernel APIC as the timer never fires. It is just
> saved/restored from and to the kernel.
>
> Is this correct?
Almost. timer_expiry is calculated on get_apic_state based on the APIC
registers. And it is initialized on reset. But it is never saved into
the kernel nor does it otherwise affect the in-kernel model. It is
really just a compatibility field for potential user space apic usage.
Jan
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH v5 11/16] kvm: Introduce core services for in-kernel irqchip support, (continued)
- [Qemu-devel] [PATCH v5 11/16] kvm: Introduce core services for in-kernel irqchip support, Jan Kiszka, 2011/12/15
- [Qemu-devel] [PATCH v5 03/16] apic: Stop timer on reset, Jan Kiszka, 2011/12/15
- [Qemu-devel] [PATCH v5 05/16] apic: Introduce apic_report_irq_delivered, Jan Kiszka, 2011/12/15
- [Qemu-devel] [PATCH v5 15/16] kvm: x86: Add user space part for in-kernel IOAPIC, Jan Kiszka, 2011/12/15
- [Qemu-devel] [PATCH v5 07/16] apic: Open-code timer save/restore, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 10/16] memory: Introduce memory_region_init_reservation, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 16/16] kvm: Arm in-kernel irqchip support, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 08/16] i8259: Introduce backend/frontend infrastructure for KVM reuse, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 12/16] kvm: x86: Establish IRQ0 override control, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 01/16] msi: Generalize msix_supported to msi_supported, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 14/16] kvm: x86: Add user space part for in-kernel i8259, Jan Kiszka, 2011/12/15
[Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse, Jan Kiszka, 2011/12/15