Avi Kivity wrote:
>>
>> It can in theory, but do we have the real usage for
>> qemu_system_reset which is the only caller of
>> KERNEL RESET.
>>
>>
>
> Well, if the guest resets itself, then reset is called from the vcpu
> thread. If we reset from the qemu monitor, it can be called from a
> no
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
N+1, for me is that synchronous device emulation (like pio and mmio)
happens in in the vcpu thread and asynchronous device emulation
(handling signals in qemu, performing dma, and injecting interrupts)
hap
Avi Kivity wrote:
> Dong, Eddie wrote:
>>> N+1, for me is that synchronous device emulation (like pio and mmio)
>>> happens in in the vcpu thread and asynchronous device emulation
>>> (handling signals in qemu, performing dma, and injecting interrupts)
>>> happens in the device thread. This minimi
Dong, Eddie wrote:
>> N+1, for me is that synchronous device emulation (like pio and mmio)
>> happens in in the vcpu thread and asynchronous device emulation
>> (handling signals in qemu, performing dma, and injecting interrupts)
>> happens in the device thread. This minimizes context switching an
>N+1, for me is that synchronous device emulation (like pio and mmio)
>happens in in the vcpu thread and asynchronous device emulation
>(handling signals in qemu, performing dma, and injecting interrupts)
>happens in the device thread. This minimizes context switching and
>heavyweight exits.
>
If
Dong, Eddie wrote:
>> I'll try writing a patch that does what I mean and post it.
>> Either I'll
>> convince you that in-kernel is simpler, or I'll convince myself that
>> it is harder.
>>
>>
> OK, let us see which one is simple.
>
> BTW, you have swapped to N+1 SMP model in this discussion w
> I'll try writing a patch that does what I mean and post it.
> Either I'll
> convince you that in-kernel is simpler, or I'll convince myself that
> it is harder.
>
OK, let us see which one is simple.
BTW, you have swapped to N+1 SMP model in this discussion which
is not there yet. And this is
Dong, Eddie wrote:
>>> Current VP wake up logic thru INIT/SIPI doesn't support this when
>>> irqchip in kernel.
>>>
>>>
>>>
>> Doesn't this code imply that waiting for SIPI is supported?
>>
>
> It is supported to wake up VCPU in kernel, but can't wake up the VCPU
> in user level since
>>
>> Current VP wake up logic thru INIT/SIPI doesn't support this when
>> irqchip in kernel.
>>
>>
>
> Doesn't this code imply that waiting for SIPI is supported?
It is supported to wake up VCPU in kernel, but can't wake up the VCPU
in user level since irqchip_in_kernel is TRUE here. vcpu->m
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>
>
>
>> It's just like the guest kernel executing hlt. Why is there a
>> difference?
>>
>
> Current VP wake up logic thru INIT/SIPI doesn't support this when
> irqchip in kernel.
This one can force qemu to execute reset ops in BSP only.
As addition to previous user level patch.
But if BSP is halted and executing some code without backing
to user level, then we have trouble. But I won't worry about this
right now, since it is also impact device model performance
if KVM does
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>>
>
> It's just like the guest kernel executing hlt. Why is there a
> difference?
Current VP wake up logic thru INIT/SIPI doesn't support this when
irqchip in kernel.
>
>>
>> Yes, halt all APs and let BSP do reset ops in user le
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>
But, for an ungraceful reset, nothing prevents an AP from
issuing a reset?
>>> Mmm, Yes, but I think current architecture can't handle this.
>>> The thread whe
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>>
>>> But, for an ungraceful reset, nothing prevents an AP from
>>> issuing a reset?
>>>
>>
>> Mmm, Yes, but I think current architecture can't handle this.
>> The thread where AP issues "RESET" will continue run, which
>> means it bec
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>>> If BSP mp_state becomes VCPU_MP_STATE_UNINITIALIZED, current code
>>> can't wakeup it. We need additional code that I am not aware of now.
>>>
>>> Current VCPU must be BSP, otherwise the code executing in Qemu will
>>> have problem too.
>>>
>>>
Avi Kivity wrote:
>>
>> If BSP mp_state becomes VCPU_MP_STATE_UNINITIALIZED, current code
>> can't wakeup it. We need additional code that I am not aware of now.
>>
>> Current VCPU must be BSP, otherwise the code executing in Qemu will
>> have problem too.
>>
>
> But, for an ungraceful reset,
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>>> In native, RESET signal force every processor enter "RESET" status,
>>> and then immediately after RESET signal is removed, all CPUs will
>>> compete for BSP role, the winner continue execution, and failor will
>>> be blocked till INIT/SIPI/SIPI.
>>>
Avi Kivity wrote:
>> In native, RESET signal force every processor enter "RESET" status,
>> and then immediately after RESET signal is removed, all CPUs will
>> compete for BSP role, the winner continue execution, and failor will
>> be blocked till INIT/SIPI/SIPI.
>>
>
> I meant, you could set b
Avi Kivity wrote:
>>>
>>>
>> For a graceful reboot, this one is not needed since every APs are
>> already brought to HALT status before BSP issue RESET signal. But in
>> case of non-graceful reboot, it is possible the VCPUs are still
>> executing guest instruction, so we kick the VCPU a
Dong, Eddie wrote:
>>>
>>> +
>>> +/*
>>> + * Reset VM.
>>> + *
>>> + */
>>> +int kvm_vm_reset(struct kvm *kvm)
>>> +{
>>> + struct kvm_vcpu *vcpu;
>>> + int i;
>>> +
>>> + kvm_reset_devices(kvm);
>>> + for (i = 0; i < KVM_MAX_VCPUS; i++) {
>>> + vcpu = kvm->vcpus[i];
>>> +
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Kernel side patch to introduce a new API for kernel device reset and
>> force vcpu mp_state to UNINATIALIZED state if it is reset.
>> thx,eddie
>>
>>
>>
>> +
>> +/*
>> + * Reset VM.
>> + *
>> + */
>> +int kvm_vm_reset(struct kvm *kvm)
>> +{
>> +struc
Dong, Eddie wrote:
> Kernel side patch to introduce a new API for kernel device reset and
> force
> vcpu mp_state to UNINATIALIZED state if it is reset.
> thx,eddie
>
> +
> +/*
> + * Reset VM.
> + *
> + */
> +int kvm_vm_reset(struct kvm *kvm)
> +{
> + struct kvm_vcpu *vcpu;
> + int i;
> +
>
Dong, Eddie wrote:
> Kernel side patch to introduce a new API for kernel device reset and
> force
> vcpu mp_state to UNINATIALIZED state if it is reset.
> thx,eddie
>
>
>
> +
> +/*
> + * Reset VM.
> + *
> + */
> +int kvm_vm_reset(struct kvm *kvm)
> +{
> + struct kvm_vcpu *vcpu;
> + int i;
>
User level change to add callback to reset kernel devices.
thx,eddie
Add user reset callback support for kernel devices.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 4d0bb93..d81e7e1 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/p
Kernel side patch to introduce a new API for kernel device reset and
force
vcpu mp_state to UNINATIALIZED state if it is reset.
thx,eddie
Add VM reset support in kernel side to
reset the kernel devices and VCPUs.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git
25 matches
Mail list logo
