| Message ID | 4d1a19311883c2ac6620633721ecc81d753f26c8.camel@linux.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | Enable VAS and NX-GZIP support on powerVM | expand |
Excerpts from Haren Myneni's message of May 21, 2021 7:34 pm: > > This patch adds HCALLs and other definitions. Also define structs > that are used in VAS implementation on powerVM. > > Signed-off-by: Haren Myneni <haren@linux.ibm.com> > --- > arch/powerpc/include/asm/hvcall.h | 7 ++ > arch/powerpc/include/asm/vas.h | 32 ++++++++ > arch/powerpc/platforms/pseries/vas.h | 110 +++++++++++++++++++++++++++ > 3 files changed, 149 insertions(+) > create mode 100644 arch/powerpc/platforms/pseries/vas.h > > diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h > index e3b29eda8074..7c3418d1b5e9 100644 > --- a/arch/powerpc/include/asm/hvcall.h > +++ b/arch/powerpc/include/asm/hvcall.h > @@ -294,6 +294,13 @@ > #define H_RESIZE_HPT_COMMIT 0x370 > #define H_REGISTER_PROC_TBL 0x37C > #define H_SIGNAL_SYS_RESET 0x380 > +#define H_ALLOCATE_VAS_WINDOW 0x388 > +#define H_MODIFY_VAS_WINDOW 0x38C > +#define H_DEALLOCATE_VAS_WINDOW 0x390 > +#define H_QUERY_VAS_WINDOW 0x394 > +#define H_QUERY_VAS_CAPABILITIES 0x398 > +#define H_QUERY_NX_CAPABILITIES 0x39C > +#define H_GET_NX_FAULT 0x3A0 > #define H_INT_GET_SOURCE_INFO 0x3A8 > #define H_INT_SET_SOURCE_CONFIG 0x3AC > #define H_INT_GET_SOURCE_CONFIG 0x3B0 > diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h > index 49bfb5be896d..371f62d99174 100644 > --- a/arch/powerpc/include/asm/vas.h > +++ b/arch/powerpc/include/asm/vas.h > @@ -181,6 +181,7 @@ struct vas_tx_win_attr { > bool rx_win_ord_mode; > }; > > +#ifdef CONFIG_PPC_POWERNV > /* > * Helper to map a chip id to VAS id. > * For POWER9, this is a 1:1 mapping. In the future this maybe a 1:N > @@ -248,6 +249,37 @@ void vas_win_paste_addr(struct vas_window *window, u64 *addr, > int vas_register_api_powernv(struct module *mod, enum vas_cop_type cop_type, > const char *name); > void vas_unregister_api_powernv(void); > +#endif > + > +#ifdef CONFIG_PPC_PSERIES > + > +/* VAS Capabilities */ > +#define VAS_GZIP_QOS_FEAT 0x1 > +#define VAS_GZIP_DEF_FEAT 0x2 > +#define VAS_GZIP_QOS_FEAT_BIT PPC_BIT(VAS_GZIP_QOS_FEAT) /* Bit 1 */ > +#define VAS_GZIP_DEF_FEAT_BIT PPC_BIT(VAS_GZIP_DEF_FEAT) /* Bit 2 */ > + > +/* NX Capabilities */ > +#define VAS_NX_GZIP_FEAT 0x1 > +#define VAS_NX_GZIP_FEAT_BIT PPC_BIT(VAS_NX_GZIP_FEAT) /* Bit 1 */ > +#define VAS_DESCR_LEN 8 > + > +/* > + * These structs are used to retrieve overall VAS capabilities that > + * the hypervisor provides. > + */ > +struct hv_vas_all_caps { ... > + > +/* > + * Use to get feature specific capabilities from the > + * hypervisor. > + */ > +struct hv_vas_ct_caps { ... > +/* > + * To get window information from the hypervisor. > + */ > +struct hv_vas_win_lpar { Are any of these names coming from PAPR? If not, then typically we don't use hv_ kind of prefixes for something we got from the hypervisor, but rather something that's hypervisor privileged or specific information about the hypervisor perhaps (which is not the same as what the hypervisor may or may not advertise to the guest). So if these are all capabilities and features the hypervisor advertises to the LPAR, I think the hv_ should be dropped. Otherwise seems okay. I would be careful of the "lpar" name. I think it's okay in this situation where the hypervisor advertises features to the partition, but in other parts of the vas code you call it pseries_ but you also have some lpar_ bits. So aside from interacting with PAPR APIs, it would be safe to consistently use pseries for your driver and type names. Thanks, Nick
On Thu, 2021-06-03 at 14:47 +1000, Nicholas Piggin wrote: > Excerpts from Haren Myneni's message of May 21, 2021 7:34 pm: > > This patch adds HCALLs and other definitions. Also define structs > > that are used in VAS implementation on powerVM. > > > > Signed-off-by: Haren Myneni <haren@linux.ibm.com> > > --- > > arch/powerpc/include/asm/hvcall.h | 7 ++ > > arch/powerpc/include/asm/vas.h | 32 ++++++++ > > arch/powerpc/platforms/pseries/vas.h | 110 > > +++++++++++++++++++++++++++ > > 3 files changed, 149 insertions(+) > > create mode 100644 arch/powerpc/platforms/pseries/vas.h > > > > diff --git a/arch/powerpc/include/asm/hvcall.h > > b/arch/powerpc/include/asm/hvcall.h > > index e3b29eda8074..7c3418d1b5e9 100644 > > --- a/arch/powerpc/include/asm/hvcall.h > > +++ b/arch/powerpc/include/asm/hvcall.h > > @@ -294,6 +294,13 @@ > > #define H_RESIZE_HPT_COMMIT 0x370 > > #define H_REGISTER_PROC_TBL 0x37C > > #define H_SIGNAL_SYS_RESET 0x380 > > +#define H_ALLOCATE_VAS_WINDOW 0x388 > > +#define H_MODIFY_VAS_WINDOW 0x38C > > +#define H_DEALLOCATE_VAS_WINDOW 0x390 > > +#define H_QUERY_VAS_WINDOW 0x394 > > +#define H_QUERY_VAS_CAPABILITIES 0x398 > > +#define H_QUERY_NX_CAPABILITIES 0x39C > > +#define H_GET_NX_FAULT 0x3A0 > > #define H_INT_GET_SOURCE_INFO 0x3A8 > > #define H_INT_SET_SOURCE_CONFIG 0x3AC > > #define H_INT_GET_SOURCE_CONFIG 0x3B0 > > diff --git a/arch/powerpc/include/asm/vas.h > > b/arch/powerpc/include/asm/vas.h > > index 49bfb5be896d..371f62d99174 100644 > > --- a/arch/powerpc/include/asm/vas.h > > +++ b/arch/powerpc/include/asm/vas.h > > @@ -181,6 +181,7 @@ struct vas_tx_win_attr { > > bool rx_win_ord_mode; > > }; > > > > +#ifdef CONFIG_PPC_POWERNV > > /* > > * Helper to map a chip id to VAS id. > > * For POWER9, this is a 1:1 mapping. In the future this maybe a > > 1:N > > @@ -248,6 +249,37 @@ void vas_win_paste_addr(struct vas_window > > *window, u64 *addr, > > int vas_register_api_powernv(struct module *mod, enum vas_cop_type > > cop_type, > > const char *name); > > void vas_unregister_api_powernv(void); > > +#endif > > + > > +#ifdef CONFIG_PPC_PSERIES > > + > > +/* VAS Capabilities */ > > +#define VAS_GZIP_QOS_FEAT 0x1 > > +#define VAS_GZIP_DEF_FEAT 0x2 > > +#define VAS_GZIP_QOS_FEAT_BIT PPC_BIT(VAS_GZIP_QOS_FEAT) /* > > Bit 1 */ > > +#define VAS_GZIP_DEF_FEAT_BIT PPC_BIT(VAS_GZIP_DEF_FEAT) /* > > Bit 2 */ > > + > > +/* NX Capabilities */ > > +#define VAS_NX_GZIP_FEAT 0x1 > > +#define VAS_NX_GZIP_FEAT_BIT PPC_BIT(VAS_NX_GZIP_FEAT) /* > > Bit 1 */ > > +#define VAS_DESCR_LEN 8 > > + > > +/* > > + * These structs are used to retrieve overall VAS capabilities > > that > > + * the hypervisor provides. > > + */ > > +struct hv_vas_all_caps { > > ... > > > + > > +/* > > + * Use to get feature specific capabilities from the > > + * hypervisor. > > + */ > > +struct hv_vas_ct_caps { > > ... > > > +/* > > + * To get window information from the hypervisor. > > + */ > > +struct hv_vas_win_lpar { > > Are any of these names coming from PAPR? If not, then typically we > don't > use hv_ kind of prefixes for something we got from the hypervisor, > but > rather something that's hypervisor privileged or specific information > about the hypervisor perhaps (which is not the same as what the > hypervisor may or may not advertise to the guest). > > So if these are all capabilities and features the hypervisor > advertises > to the LPAR, I think the hv_ should be dropped. The hypervisor advertises the available capabalities and the LPAR passes buffer to HCALLs to retrieve these capabilties / features (in BE). I was using *_be in the previous version. So can I use like 'struct vas_ct_caps_be' > > Otherwise seems okay. I would be careful of the "lpar" name. I think > it's okay in this situation where the hypervisor advertises features > to > the partition, but in other parts of the vas code you call it > pseries_ > but you also have some lpar_ bits. So aside from interacting with > PAPR > APIs, it would be safe to consistently use pseries for your driver > and > type names. I can use 'struct hv_vas_win_pseries' or 'struct vas_win_pseries_be' > > Thanks, > Nick
Excerpts from Haren Myneni's message of June 4, 2021 11:30 am: > On Thu, 2021-06-03 at 14:47 +1000, Nicholas Piggin wrote: >> Excerpts from Haren Myneni's message of May 21, 2021 7:34 pm: >> > This patch adds HCALLs and other definitions. Also define structs >> > that are used in VAS implementation on powerVM. >> > >> > Signed-off-by: Haren Myneni <haren@linux.ibm.com> >> > --- >> > arch/powerpc/include/asm/hvcall.h | 7 ++ >> > arch/powerpc/include/asm/vas.h | 32 ++++++++ >> > arch/powerpc/platforms/pseries/vas.h | 110 >> > +++++++++++++++++++++++++++ >> > 3 files changed, 149 insertions(+) >> > create mode 100644 arch/powerpc/platforms/pseries/vas.h >> > >> > diff --git a/arch/powerpc/include/asm/hvcall.h >> > b/arch/powerpc/include/asm/hvcall.h >> > index e3b29eda8074..7c3418d1b5e9 100644 >> > --- a/arch/powerpc/include/asm/hvcall.h >> > +++ b/arch/powerpc/include/asm/hvcall.h >> > @@ -294,6 +294,13 @@ >> > #define H_RESIZE_HPT_COMMIT 0x370 >> > #define H_REGISTER_PROC_TBL 0x37C >> > #define H_SIGNAL_SYS_RESET 0x380 >> > +#define H_ALLOCATE_VAS_WINDOW 0x388 >> > +#define H_MODIFY_VAS_WINDOW 0x38C >> > +#define H_DEALLOCATE_VAS_WINDOW 0x390 >> > +#define H_QUERY_VAS_WINDOW 0x394 >> > +#define H_QUERY_VAS_CAPABILITIES 0x398 >> > +#define H_QUERY_NX_CAPABILITIES 0x39C >> > +#define H_GET_NX_FAULT 0x3A0 >> > #define H_INT_GET_SOURCE_INFO 0x3A8 >> > #define H_INT_SET_SOURCE_CONFIG 0x3AC >> > #define H_INT_GET_SOURCE_CONFIG 0x3B0 >> > diff --git a/arch/powerpc/include/asm/vas.h >> > b/arch/powerpc/include/asm/vas.h >> > index 49bfb5be896d..371f62d99174 100644 >> > --- a/arch/powerpc/include/asm/vas.h >> > +++ b/arch/powerpc/include/asm/vas.h >> > @@ -181,6 +181,7 @@ struct vas_tx_win_attr { >> > bool rx_win_ord_mode; >> > }; >> > >> > +#ifdef CONFIG_PPC_POWERNV >> > /* >> > * Helper to map a chip id to VAS id. >> > * For POWER9, this is a 1:1 mapping. In the future this maybe a >> > 1:N >> > @@ -248,6 +249,37 @@ void vas_win_paste_addr(struct vas_window >> > *window, u64 *addr, >> > int vas_register_api_powernv(struct module *mod, enum vas_cop_type >> > cop_type, >> > const char *name); >> > void vas_unregister_api_powernv(void); >> > +#endif >> > + >> > +#ifdef CONFIG_PPC_PSERIES >> > + >> > +/* VAS Capabilities */ >> > +#define VAS_GZIP_QOS_FEAT 0x1 >> > +#define VAS_GZIP_DEF_FEAT 0x2 >> > +#define VAS_GZIP_QOS_FEAT_BIT PPC_BIT(VAS_GZIP_QOS_FEAT) /* >> > Bit 1 */ >> > +#define VAS_GZIP_DEF_FEAT_BIT PPC_BIT(VAS_GZIP_DEF_FEAT) /* >> > Bit 2 */ >> > + >> > +/* NX Capabilities */ >> > +#define VAS_NX_GZIP_FEAT 0x1 >> > +#define VAS_NX_GZIP_FEAT_BIT PPC_BIT(VAS_NX_GZIP_FEAT) /* >> > Bit 1 */ >> > +#define VAS_DESCR_LEN 8 >> > + >> > +/* >> > + * These structs are used to retrieve overall VAS capabilities >> > that >> > + * the hypervisor provides. >> > + */ >> > +struct hv_vas_all_caps { >> >> ... >> >> > + >> > +/* >> > + * Use to get feature specific capabilities from the >> > + * hypervisor. >> > + */ >> > +struct hv_vas_ct_caps { >> >> ... >> >> > +/* >> > + * To get window information from the hypervisor. >> > + */ >> > +struct hv_vas_win_lpar { >> >> Are any of these names coming from PAPR? If not, then typically we >> don't >> use hv_ kind of prefixes for something we got from the hypervisor, >> but >> rather something that's hypervisor privileged or specific information >> about the hypervisor perhaps (which is not the same as what the >> hypervisor may or may not advertise to the guest). >> >> So if these are all capabilities and features the hypervisor >> advertises >> to the LPAR, I think the hv_ should be dropped. > > The hypervisor advertises the available capabalities and the LPAR > passes buffer to HCALLs to retrieve these capabilties / features (in > BE). > > I was using *_be in the previous version. So can I use like 'struct > vas_ct_caps_be' > >> >> Otherwise seems okay. I would be careful of the "lpar" name. I think >> it's okay in this situation where the hypervisor advertises features >> to >> the partition, but in other parts of the vas code you call it >> pseries_ >> but you also have some lpar_ bits. So aside from interacting with >> PAPR >> APIs, it would be safe to consistently use pseries for your driver >> and >> type names. > > I can use 'struct hv_vas_win_pseries' or 'struct vas_win_pseries_be' I'm actually wrong about hv_ prefix now I look a bit further, there are other structures that do use it for similar hcalls, sorry about that. I'm not sure I like it too much but it is what it is. I would say don't worry about churning your hv_ names for now. It's probably better / more used than _be postfix. Changing conventions could be a later powerpc-wide series if it's that important. Thanks, Nick
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h index e3b29eda8074..7c3418d1b5e9 100644 --- a/arch/powerpc/include/asm/hvcall.h +++ b/arch/powerpc/include/asm/hvcall.h @@ -294,6 +294,13 @@ #define H_RESIZE_HPT_COMMIT 0x370 #define H_REGISTER_PROC_TBL 0x37C #define H_SIGNAL_SYS_RESET 0x380 +#define H_ALLOCATE_VAS_WINDOW 0x388 +#define H_MODIFY_VAS_WINDOW 0x38C +#define H_DEALLOCATE_VAS_WINDOW 0x390 +#define H_QUERY_VAS_WINDOW 0x394 +#define H_QUERY_VAS_CAPABILITIES 0x398 +#define H_QUERY_NX_CAPABILITIES 0x39C +#define H_GET_NX_FAULT 0x3A0 #define H_INT_GET_SOURCE_INFO 0x3A8 #define H_INT_SET_SOURCE_CONFIG 0x3AC #define H_INT_GET_SOURCE_CONFIG 0x3B0 diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h index 49bfb5be896d..371f62d99174 100644 --- a/arch/powerpc/include/asm/vas.h +++ b/arch/powerpc/include/asm/vas.h @@ -181,6 +181,7 @@ struct vas_tx_win_attr { bool rx_win_ord_mode; }; +#ifdef CONFIG_PPC_POWERNV /* * Helper to map a chip id to VAS id. * For POWER9, this is a 1:1 mapping. In the future this maybe a 1:N @@ -248,6 +249,37 @@ void vas_win_paste_addr(struct vas_window *window, u64 *addr, int vas_register_api_powernv(struct module *mod, enum vas_cop_type cop_type, const char *name); void vas_unregister_api_powernv(void); +#endif + +#ifdef CONFIG_PPC_PSERIES + +/* VAS Capabilities */ +#define VAS_GZIP_QOS_FEAT 0x1 +#define VAS_GZIP_DEF_FEAT 0x2 +#define VAS_GZIP_QOS_FEAT_BIT PPC_BIT(VAS_GZIP_QOS_FEAT) /* Bit 1 */ +#define VAS_GZIP_DEF_FEAT_BIT PPC_BIT(VAS_GZIP_DEF_FEAT) /* Bit 2 */ + +/* NX Capabilities */ +#define VAS_NX_GZIP_FEAT 0x1 +#define VAS_NX_GZIP_FEAT_BIT PPC_BIT(VAS_NX_GZIP_FEAT) /* Bit 1 */ +#define VAS_DESCR_LEN 8 + +/* + * These structs are used to retrieve overall VAS capabilities that + * the hypervisor provides. + */ +struct hv_vas_all_caps { + __be64 descriptor; + __be64 feat_type; +} __packed __aligned(0x1000); + +struct vas_all_caps { + char name[VAS_DESCR_LEN + 1]; + u64 descriptor; + u64 feat_type; +}; + +#endif /* * Register / unregister coprocessor type to VAS API which will be exported diff --git a/arch/powerpc/platforms/pseries/vas.h b/arch/powerpc/platforms/pseries/vas.h new file mode 100644 index 000000000000..033667921d36 --- /dev/null +++ b/arch/powerpc/platforms/pseries/vas.h @@ -0,0 +1,110 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Copyright 2020-21 IBM Corp. + */ + +#ifndef _VAS_H +#define _VAS_H +#include <asm/vas.h> +#include <linux/mutex.h> +#include <linux/stringify.h> + +/* + * VAS window modify flags + */ +#define VAS_MOD_WIN_CLOSE PPC_BIT(0) +#define VAS_MOD_WIN_JOBS_KILL PPC_BIT(1) +#define VAS_MOD_WIN_DR PPC_BIT(3) +#define VAS_MOD_WIN_PR PPC_BIT(4) +#define VAS_MOD_WIN_SF PPC_BIT(5) +#define VAS_MOD_WIN_TA PPC_BIT(6) +#define VAS_MOD_WIN_FLAGS (VAS_MOD_WIN_JOBS_KILL | VAS_MOD_WIN_DR | \ + VAS_MOD_WIN_PR | VAS_MOD_WIN_SF) + +#define VAS_WIN_ACTIVE 0x0 +#define VAS_WIN_CLOSED 0x1 +#define VAS_WIN_INACTIVE 0x2 /* Inactive due to HW failure */ +/* Process of being modified, deallocated, or quiesced */ +#define VAS_WIN_MOD_IN_PROCESS 0x3 + +#define VAS_COPY_PASTE_USER_MODE 0x00000001 +#define VAS_COP_OP_USER_MODE 0x00000010 + +/* + * Co-processor feature - GZIP QoS windows or GZIP default windows + */ +enum vas_cop_feat_type { + VAS_GZIP_QOS_FEAT_TYPE, + VAS_GZIP_DEF_FEAT_TYPE, + VAS_MAX_FEAT_TYPE, +}; + +/* + * Use to get feature specific capabilities from the + * hypervisor. + */ +struct hv_vas_ct_caps { + __be64 descriptor; + u8 win_type; /* Default or QoS type */ + u8 user_mode; + __be16 max_lpar_creds; + __be16 max_win_creds; + union { + __be16 reserved; + __be16 def_lpar_creds; /* Used for default capabilities */ + }; + __be16 target_lpar_creds; +} __packed __aligned(0x1000); + +/* + * Feature specific (QoS or default) capabilities. + */ +struct vas_ct_caps { + char name[VAS_DESCR_LEN + 1]; + u64 descriptor; + u8 win_type; /* Default or QoS type */ + u8 user_mode; /* User mode copy/paste or COP HCALL */ + u16 max_lpar_creds; /* Max credits available in LPAR */ + /* Max credits can be assigned per window */ + u16 max_win_creds; + union { + u16 reserved; /* Used for QoS credit type */ + u16 def_lpar_creds; /* Used for default credit type */ + }; + /* Total LPAR available credits. Can be different from max LPAR */ + /* credits due to DLPAR operation */ + atomic_t target_lpar_creds; + atomic_t used_lpar_creds; /* Used credits so far */ + u16 avail_lpar_creds; /* Remaining available credits */ +}; + +/* + * Feature (QoS or Default) specific to store capabilities and + * the list of open windows. + */ +struct vas_caps { + struct vas_ct_caps caps; + struct list_head list; /* List of open windows */ +}; + +/* + * To get window information from the hypervisor. + */ +struct hv_vas_win_lpar { + __be16 version; + u8 win_type; + u8 status; + __be16 credits; /* No of credits assigned to this window */ + __be16 reserved; + __be32 pid; /* LPAR Process ID */ + __be32 tid; /* LPAR Thread ID */ + __be64 win_addr; /* Paste address */ + __be32 interrupt; /* Interrupt when NX request completes */ + __be32 fault; /* Interrupt when NX sees fault */ + /* Associativity Domain Identifiers as returned in */ + /* H_HOME_NODE_ASSOCIATIVITY */ + __be64 domain[6]; + __be64 win_util; /* Number of bytes processed */ +} __packed __aligned(0x1000); + +#endif /* _VAS_H */
This patch adds HCALLs and other definitions. Also define structs that are used in VAS implementation on powerVM. Signed-off-by: Haren Myneni <haren@linux.ibm.com> --- arch/powerpc/include/asm/hvcall.h | 7 ++ arch/powerpc/include/asm/vas.h | 32 ++++++++ arch/powerpc/platforms/pseries/vas.h | 110 +++++++++++++++++++++++++++ 3 files changed, 149 insertions(+) create mode 100644 arch/powerpc/platforms/pseries/vas.h