Am 05.04.2013 um 00:35 schrieb Scott Wood <scottw...@freescale.com>:
> On 04/04/2013 05:30:05 PM, Alexander Graf wrote:
>> Am 04.04.2013 um 20:41 schrieb Scott Wood <scottw...@freescale.com>:
>> > On 04/04/2013 07:54:20 AM, Alexander Graf wrote:
>> >> On 03.04.2013, at 03:57, Scott Wood wrote:
>> >> > + if (opp->mpic_mode_mask == GCR_MODE_PROXY)
>> >> Shouldn't this be an &?
>> >
>> > The way the mode field was originally documented was a two-bit field,
>> > where 0b11 was external proxy, and 0b10 was reserved. If we use & it
>> > would have to be:
>> >
>> > if ((opp->mpic_mode_mask & GCR_MODE_PROXY) == GCR_MODE_PROXY)
>> > ...
>> >
>> > Simply testing "opp->mpic_mode_mask & GCR_MODE_PROXY" would return true in
>> > the case of GCR_MODE_MIXED.
>> >
>> > In MPIC 4.3 external proxy is defined as a separate bit (GCR[CI]) that is
>> > ignored if the mixed-mode bit (GCR[M]) is not set, which makes it a bit
>> > more legitimate to view it as a bitmap. Still, I doubt we'll see new mode
>> > bits.
>> Ok, please add a comment about this here then :).
>
> What sort of comment would you like? Or do you want me to use the "(x & y)
> == y" version?
/* This might need to be changed if GCR gets extended */
>
>> >> > @@ -460,6 +464,13 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
>> >> > tasklet_kill(&vcpu->arch.tasklet);
>> >> >
>> >> > kvmppc_remove_vcpu_debugfs(vcpu);
>> >> > +
>> >> > + switch (vcpu->arch.irq_type) {
>> >> > + case KVMPPC_IRQ_MPIC:
>> >> > + kvmppc_mpic_put(vcpu->arch.mpic);
>> >> This doesn't tell the MPIC that this exact CPU is getting killed. What if
>> >> we hotplug remove just a single CPU? Don't we have to deregister the CPU
>> >> with the MPIC?
>> >
>> > If we ever support hot vcpu removal, yes. We'd probably need some MPIC
>> > code changes to accommodate that, and we wouldn't currently have a way to
>> > test it, so I'd rather make it obviously not supported for now.
>> Is there any way to break heavily if user space attempts this?
>
> Is there any way for userspace to request this currently? They can close the
> vcpu fd, but the vcpu won't actually be destroyed until the vm goes down.
Are you sure? X86 does CPU hotplug today, so there has to be something :)
Alex
>
> -Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
