| Message ID | 20120124145600.GA6555@dhcp-192-168-178-175.profitbricks.localdomain |
|---|---|
| State | New |
| Headers | show |
On 01/24/2012 04:56 PM, Vasilis Liaskovitis wrote: > On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote: > > On 2012-01-24 11:10, Vasilis Liaskovitis wrote: > > > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and > > > enable eject callback only for pc-1.1 machine model. > > > > Just to get the idea: What is the plan and advantage of introducing a > > stub first? How much more is required to have some usable feature, even > > if its just a friction of the full support? > > > There's not really an advantage to adding stubs first. The plan depends on the > lifecycle patches getting accepted in some form at some point. The code is all > out there, and some of it has been reviewed/commented on, but not accepted. > > kvm needs the following patches: > https://lkml.org/lkml/2012/1/6/355 (v7, still in work) > http://patchwork.ozlabs.org/patch/127828/ > This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal > vcpu destruction to the host) but the review mentions there should be a > simpler way. It's unclear to me whether this ioctl is desired or not. Those patches are not strictly needed. On a kernel that doesn't have them, you can simply park the vcpu thread in userspace until it is re-added. I suggest writing the qemu patches without the assumption that you're running on a 3.4+ kernel.
On Thu, Jan 26, 2012 at 12:46:18PM +0200, Avi Kivity wrote: > On 01/24/2012 04:56 PM, Vasilis Liaskovitis wrote: > > On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote: > > > On 2012-01-24 11:10, Vasilis Liaskovitis wrote: > > > > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and > > > > enable eject callback only for pc-1.1 machine model. > > > > > > Just to get the idea: What is the plan and advantage of introducing a > > > stub first? How much more is required to have some usable feature, even > > > if its just a friction of the full support? > > > > > There's not really an advantage to adding stubs first. The plan depends on the > > lifecycle patches getting accepted in some form at some point. The code is all > > out there, and some of it has been reviewed/commented on, but not accepted. > > > > kvm needs the following patches: > > https://lkml.org/lkml/2012/1/6/355 (v7, still in work) > > http://patchwork.ozlabs.org/patch/127828/ > > This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal > > vcpu destruction to the host) but the review mentions there should be a > > simpler way. It's unclear to me whether this ioctl is desired or not. > > Those patches are not strictly needed. On a kernel that doesn't have > them, you can simply park the vcpu thread in userspace until it is > re-added. I suggest writing the qemu patches without the assumption > that you're running on a 3.4+ kernel. ok, I will try to handle CPU ejection without relying on the lifecycle patches. thanks, - Vasilis
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c index 8475aa6..b5fcb4a 100644 --- a/hw/acpi_piix4.c +++ b/hw/acpi_piix4.c @@ -509,6 +509,20 @@ static uint32_t cpuej_read(void *opaque, uint32_t addr) static void cpuej_write(void *opaque, uint32_t addr, uint32_t val) { + PIIX4PMState *s = opaque; + CPUState *env; + int cpu; + int ret; + + cpu = ffs(val); + /* zero means no bit was set, i.e. no CPU ejection happened */ + if (!cpu) + return; + cpu--; + env = cpu_phyid_to_cpu((uint64_t)cpu); + if (s->kvm_enabled && env != NULL) { + kvm_eject_vcpu(env); + } PIIX4_DPRINTF("cpuej write %x <== %d\n", addr, val); } diff --git a/kvm-all.c b/kvm-all.c index 88f1156..d3e53f5 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -193,6 +193,13 @@ static void kvm_reset_vcpu(void *opaque) kvm_arch_reset_vcpu(env); } +static void kvm_eject_vcpu(void *opaque) +{ + CPUState *env = opaque; + + kvm_arch_eject_vcpu(env); +} + int kvm_irqchip_in_kernel(void) { return kvm_state->irqchip_in_kernel; diff --git a/kvm.h b/kvm.h index 40b5ffc..ace28a8 100644 --- a/kvm.h +++ b/kvm.h @@ -125,6 +125,8 @@ int kvm_arch_init_vcpu(CPUState *env); void kvm_arch_reset_vcpu(CPUState *env); +void kvm_arch_eject_vcpu(CPUState *env); + int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr); int kvm_arch_on_sigbus(int code, void *addr); diff --git a/target-i386/kvm.c b/target-i386/kvm.c index e41de39..f8239c0 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -589,6 +589,21 @@ void kvm_arch_reset_vcpu(CPUState *env) } } +void kvm_arch_eject_vcpu(CPUState *env) +{ + struct kvm_vcpu_state state; + int ret = 0; + + if (env->state == CPU_STATE_ZAPREQ) { + state.vcpu_id = env->cpu_index; + state.state = 1; + ret = kvm_vm_ioctl(env->kvm_state, KVM_SETSTATE_VCPU, &state); + if (ret) + fprintf(stderr, "KVM_SETSTATE_VCPU failed: %s\n", + strerror(ret)); + } +} + static int kvm_get_supported_msrs(KVMState *s) { static int kvm_supported_msrs;