On 2015/12/16 15:31, Shannon Zhao wrote:
>>>> >> > But in this case, you're returning an error if it is *not* 
>>>> >> > initialized.
>>>> >> > I understand that in that case you cannot return an interrupt number 
>>>> >> > (-1
>>>> >> > would be weird), but returning -EBUSY feels even more weird.
>>>> >> > 
>>>> >> > I'd settle for -ENOXIO, or something similar. Anyone having a better 
>>>> >> > idea?
>>>> >> > 
>> > ENXIO or ENODEV would be my choice too, and add that to the
>> > Documentation clearly describing when this error code is used.
>> > 
>> > By the way, why do you loop over all VCPUS to set the same value when
>> > you can't do anything per VCPU anyway?  It seems to me it's either a
>> > per-VM property (that you can store on the VM data structure) or it's a
>> > true per-VCPU property?
> This is a per-VCPU property. PMU interrupt could be PPI or SPI. For PPI
> the interrupt numbers are same for each vcpu, while for SPI they are
> different, so it needs to set them separately. I planned to support both
> PPI and SPI. I think I should add support for SPI at this moment and let
> users (QEMU) to set these interrupts for each one.

How about below vPMU Documentation?

ARM Virtual Performance Monitor Unit (vPMU)

Device types supported:
  KVM_DEV_TYPE_ARM_PMU_V3         ARM Performance Monitor Unit v3

Instantiate one PMU instance for per VCPU through this API.

    The attr field of kvm_device_attr encodes two values:
    bits:     | 63 .... 32 | 31 .... 0 |
    values:   | vcpu_index |  irq_num  |
    The irq_num describes the PMU overflow interrupt number for the
    vcpu_index vcpu. This interrupt could be a PPI or SPI, but for one
VM the
    interrupt type must be same for each vcpu.

    -ENXIO: Getting or setting this attribute is not yet supported
    -ENODEV: Getting the PMU overflow interrupt number while it's not set
    -EBUSY: The PMU overflow interrupt is already set
    -EINVAL: Invalid vcpu_index or irq_num supplied


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

Reply via email to