[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 27/49] ARM: new VGIC: Add MMIO handling framework
Hi Andre, On 13/02/18 18:17, Andre Przywara wrote: On 13/02/18 16:52, Julien Grall wrote:+struct vgic_register_region { + unsigned int reg_offset; + unsigned int len; + unsigned int bits_per_irq; + unsigned int access_flags; + union + { + unsigned long (*read)(struct vcpu *vcpu, paddr_t addr, + unsigned int len); + unsigned long (*its_read)(struct domain *d, struct vgic_its *its, + paddr_t addr, unsigned int len); + }; + union + { + void (*write)(struct vcpu *vcpu, paddr_t addr, + unsigned int len, unsigned long val); + void (*its_write)(struct domain *d, struct vgic_its *its, + paddr_t addr, unsigned int len, + unsigned long val); + }; + unsigned long (*uaccess_read)(struct vcpu *vcpu, paddr_t addr, + unsigned int len); + union + { + void (*uaccess_write)(struct vcpu *vcpu, paddr_t addr, + unsigned int len, unsigned long val); + int (*uaccess_its_write)(struct domain *d, struct vgic_its *its, + paddr_t addr, unsigned int len, + unsigned long val); + };I don't think uaccess helpers makes sense for Xen.True, I was unsure about whether to keep them. I have the gut feeling we need it later when we want to suspend/resume the VGIC, so removing everything and then simplifying the code afterwards might bite us in the future. So as long as it doesn't really hurt, I am tempted to keep that code in, which also keeps it closer the the KVM implementation. I don't want to see code that is going to potentially rot. If we really need it, we can add it afterwards. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |