On 17/12/15 08:41, Shannon Zhao wrote: > > > On 2015/12/17 16:33, Marc Zyngier wrote: >> On Thu, 17 Dec 2015 15:22:50 +0800 >> Shannon Zhao <zhaoshenglong@xxxxxxxxxx> wrote: >> >>>> >>>> >>>> On 2015/12/17 4:33, Christoffer Dall wrote: >>>>>> On Wed, Dec 16, 2015 at 04:06:49PM +0800, Shannon Zhao wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> Groups: >>>>>>>> KVM_DEV_ARM_PMU_GRP_IRQ >>>>>>>> Attributes: >>>>>>>> The attr field of kvm_device_attr encodes two values: >>>>>>>> bits: | 63 .... 32 | 31 .... 0 | >>>>>>>> values: | vcpu_index | irq_num | >>>> BTW, I change this Attribute to below format and pass vcpu_index through >>>> this Attribute while pass irq_num through kvm_device_attr.addr. >>>> Is it fine? >>>> >>>> bits: | 63 .... 32 | 31 .... 0 | >>>> values: | reserved | vcpu_index | >> Using the .addr field for something that is clearly not an address is >> rather odd. Is there any prior usage of that field for something that >> is not an address? > > I see this usage in vgic_attr_regs_access(). But if you prefer previous > one, I'll use that. Ah, you're using the .addr field to point to a userspace value, not to carry the value itself! That'd be fine by me (even if I still prefer the original one), but I'd like others to chime in (I'm quite bad at defining userspace stuff...). Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
