CONFIG_GUP_TEST provides userspace with an ioctl to invoke
pin_user_pages(), and this test uses the ioctl to pin pages, to check
that memory attributes cannot be set to private if shared pages are
pinned.
Signed-off-by: Ackerley Tng
---
tools/testing/selftests/kvm/Makefile | 1
Update private_mem_conversions_test for various private memory backing
source types.
Signed-off-by: Ackerley Tng
---
.../kvm/x86_64/private_mem_conversions_test.c | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86_64
Adds support for various type of backing sources for private
memory (in the sense of confidential computing), similar to the
backing sources available for shared memory.
Signed-off-by: Ackerley Tng
---
.../testing/selftests/kvm/include/test_util.h | 16
tools/testing/selftests/kvm/lib
On 16.05.24 19:44, Guillaume Morin wrote:
On 02 May 5:59, Guillaume Morin wrote:
On 30 Apr 21:25, David Hildenbrand wrote:
I tried to get the hugepd stuff right but this was the first I heard
about it :-) Afaict follow_huge_pmd and friends were already DTRT
I'll have to have a closer look a
On 02 May 5:59, Guillaume Morin wrote:
>
> On 30 Apr 21:25, David Hildenbrand wrote:
> > > I tried to get the hugepd stuff right but this was the first I heard
> > > about it :-) Afaict follow_huge_pmd and friends were already DTRT
> >
> > I'll have to have a closer look at some details (the huge
tatic int __write_opcode_hugetlb(pte_t *ptep, unsigned long page_mask,
+ unsigned long vaddr,
+ unsigned long next, struct mm_walk *walk)
+{
+ struct uwo_data *data = walk->private;
+ const bool is_register = !!is_swbp_insn(&data->opcode);
+
On 26.04.24 21:55, Guillaume Morin wrote:
On 26 Apr 9:19, David Hildenbrand wrote:
A couple of points:
a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want
to check PageAnonExclusive.
b) If you're not following the can_follow_write_pte/_pmd model, you are
doing something
suddenly on head pages.
The main reason is that the previous __replace_page worked directly on the full
HP page so adjusting after gup seemed to make more sense to me. But
now I guess it's not that useful (esp we're going with a different
version of write_uprobe). I'll fix
(...)
&g
-static int __write_opcode_pte(pte_t *ptep, unsigned long vaddr,
- unsigned long next, struct mm_walk *walk)
+static int __write_opcode(pte_t *ptep, unsigned long vaddr,
+ unsigned long page_mask, struct mm_walk *walk)
Unrelated alignment change.
{
struc
gned long vaddr,
- unsigned long next, struct mm_walk *walk)
+static int __write_opcode(pte_t *ptep, unsigned long vaddr,
+ unsigned long page_mask, struct mm_walk *walk)
{
struct uwo_data *data = walk->private;;
const bool is_r
amp; (VM_MAYSHARE | VM_SHARED))
+ return false;
+
+ /* ... or read-only private ones */
+ if (!(vma->vm_flags & VM_MAYWRITE))
+ return false;
+
+ /* ... or already writable ones that just need to take a write fault */
+ if (vma->vm_flags &
Yes, my patch seems to be working. The hugetlb code is pretty simple.
And it allows ptrace and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the faul
> > be
> > > the cleaner thing to use here once I manage to switch over to
> > > FOLL_WRITE|FOLL_FORCE to break COW.
> >
> > Yes, my patch seems to be working. The hugetlb code is pretty simple.
> > And it allows ptrace and the proc pid mem file to work on the ex
trace and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault and
follow_page_mask paths. I am not sure if we can simply assume in the
hugetlb code that i
trace and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault and
follow_page_mask paths. I am not sure if we can simply assume in the
hugetlb code that i
llows ptrace and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault and
follow_page_mask paths. I am not sure if we can simply assume in the
hugetlb co
On 24.04.24 22:44, Guillaume Morin wrote:
On 24 Apr 22:09, David Hildenbrand wrote:
Let me try to see if we can get this done cleaner.
One ugly part (in general here) is the custom page replacement in the
registration part.
We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing
On 24 Apr 22:09, David Hildenbrand wrote:
> > > Let me try to see if we can get this done cleaner.
> > >
> > > One ugly part (in general here) is the custom page replacement in the
> > > registration part.
> > >
> > > We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing
> > > pa
On 22.04.24 22:53, Guillaume Morin wrote:
On 22 Apr 20:59, David Hildenbrand wrote:
The benefit - to me - is very clear. People do use hugetlb mappings to
run code in production environments. The perf benefits are there for some
workloads. Intel has published a whitepaper about it etc.
Uprobes a
On 22 Apr 20:59, David Hildenbrand wrote:
> > The benefit - to me - is very clear. People do use hugetlb mappings to
> > run code in production environments. The perf benefits are there for some
> > workloads. Intel has published a whitepaper about it etc.
> > Uprobes are a very good tool to do liv
Morin wrote:
libhugetlbfs, the Intel iodlr code both allow to remap .text onto a
hugetlb private mapping. It's also pretty easy to do it manually.
One drawback of using this functionality is the lack of support for
uprobes (NOTE uprobe ignores shareable vmas)
This patch adds support for priva
, the Intel iodlr code both allow to remap .text onto a
> > hugetlb private mapping. It's also pretty easy to do it manually.
> > One drawback of using this functionality is the lack of support for
> > uprobes (NOTE uprobe ignores shareable vmas)
> >
> > This patch
th that is shared
amongst segments. This lead to a situation where some segments are
not transformed correctly when segmentation happens at layer 3.
Fix this by using private skb extensions for segmented and hw offloaded
ESP packets.
Fixes: 94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion
th that is shared
amongst segments. This lead to a situation where some segments are
not transformed correctly when segmentation happens at layer 3.
Fix this by using private skb extensions for segmented and hw offloaded
ESP packets.
Fixes: 94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data. The only difference is that these return a void *
instead of an unsigned long, which matches the majority of users.
Turn attach_page_private
On Fri, 9 Apr 2021, at 13:37, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:43AM CDT, Andrew Jeffery wrote:
> >Move all client-private data out of `struct kcs_bmc` into the KCS client
> >implementation.
> >
> >With this change the KCS BMC core code now only conce
On Fri, Mar 19, 2021 at 01:27:43AM CDT, Andrew Jeffery wrote:
>Move all client-private data out of `struct kcs_bmc` into the KCS client
>implementation.
>
>With this change the KCS BMC core code now only concerns itself with
>abstract `struct kcs_bmc` and `struct kcs_bmc_client` t
On Sat, Mar 20, 2021 at 10:41:56AM +0800, Lu Baolu wrote:
> drivers/iommu/intel/svm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
On Wed, Mar 31, 2021 at 07:47:10PM +0100, Matthew Wilcox (Oracle) wrote:
> Add folio_private() and set_folio_private() which mirror page_private()
> and set_page_private() -- ie folio private data is the same as page
> private data. The only difference is that these return a void *
>
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro and
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
drivers/us
this patchset replaces RT_PRINT_DATA private macro for dump hex values
with the kernel helper used for this pourpose.
-
Changes in v2:
- removed the do-nothing macro declaration as well
Fabio Aiuto (2):
staging: rtl8723bs: use print_hex_dump_debug
replace private macro RT_PRINT_DATA with in-kernel helper
print_hex_dump_debug
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/hal_com.c | 13 ---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 22 ++-
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c
On Wed, Mar 31, 2021 at 11:34:05AM +0200, Fabio Aiuto wrote:
> this patchset replaces RT_PRINT_DATA private macro for dump hex values
> with the kernel helper used for this pourpose.
>
> Fabio Aiuto (2):
> staging: rtl8723bs: use print_hex_dump_debug instead of private
>
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
drivers/us
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data. The only difference is that these return a void *
instead of an unsigned long, which matches the majority of users.
Turn attach_page_private
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro and
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
drivers/us
this patchset replace all RT_TRACE usages with public log functions
used for this pourpose
Fabio Aiuto (40):
staging: rtl8723bs: replace RT_TRACE with public printk wrappers in
core/rtw_xmit.c
staging: rtl8723bs: replace RT_TRACE with public printk wrappers in
core/rtw_security.c
sta
replace private macro RT_PRINT_DATA with in-kernel helper
print_hex_dump_debug
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/hal_com.c | 13 ---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 22 ++-
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c
this patchset replaces RT_PRINT_DATA private macro for dump hex values
with the kernel helper used for this pourpose.
Fabio Aiuto (2):
staging: rtl8723bs: use print_hex_dump_debug instead of private
RT_PRINT_DATA
staging: rtl8723bs: remove unused macro RT_PRINT_DATA
drivers/staging
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
drivers/us
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
drivers/us
> > CM3 won't use this interface till ethtool priv flag was set, it can be done
> > by
> communication over CM3 SRAM memory.
> >
> > > How does CM3 know the status of the link?
> >
> > CM3 has access to MAC registers and can read port status bit.
> >
> > > How does CM3 set its
> > > flow control d
On Mon, Mar 22, 2021 at 03:59:43PM +, Stefan Chulski wrote:
>
> > > 2. CM3 code has very small footprint requirement, we cannot
> > > implement the complete Serdes and PHY infrastructure that kernel
> > > provides as part of CM3 application. Therefore I would like to
> > > continue relying
> > 2. CM3 code has very small footprint requirement, we cannot
> > implement the complete Serdes and PHY infrastructure that kernel
> > provides as part of CM3 application. Therefore I would like to
> > continue relying on kernel configuration for that.
>
> How can that work? How does Linux
This driver implements its own routines to allocate, access and free the
private data of its net_device. Use the functionality from the networking
core instead.
Signed-off-by: Martin Kaiser
---
drivers/staging/rtl8188eu/core/rtw_debug.c| 8 +-
drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data. The only difference is that these return a void *
instead of an unsigned long, which matches the majority of users.
Turn attach_page_private
The VT-d specification (section 7.6) requires that the value in the
Private Data field of a Page Group Response Descriptor must match
the value in the Private Data field of the respective Page Request
Descriptor.
The private data field of a page group response descriptor is set then
immediately
Move all client-private data out of `struct kcs_bmc` into the KCS client
implementation.
With this change the KCS BMC core code now only concerns itself with
abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving
expected separation of concerns. Further, the change clears the path
> 2. CM3 code has very small footprint requirement, we cannot
> implement the complete Serdes and PHY infrastructure that kernel
> provides as part of CM3 application. Therefore I would like to
> continue relying on kernel configuration for that.
How can that work? How does Linux know when CM3 has
ng around a tail pointer cast to a folio is not going to
get very far, assuming CONFIG_DEBUG_VM_PGFLAGS is enabled (most distros
don't, but I do when I'm testing anything THPish).
These helpers aren't going to live for very long ... I expect to have
all filesystems which use attach/detach page
On Thu 18-03-21 11:02:17, Johannes Weiner wrote:
> On Thu, Mar 18, 2021 at 03:01:25PM +0100, Michal Hocko wrote:
> > On Wed 17-03-21 18:59:59, Shakeel Butt wrote:
> > > The function swap_readpage() (and other functions it call) extracts swap
> > > entry from
On Wed, Mar 17, 2021 at 06:59:59PM -0700, Shakeel Butt wrote:
> The function swap_readpage() (and other functions it call) extracts swap
> entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> skips the swapcache and thus we need to manually set the page->private
On Thu, Mar 18, 2021 at 03:01:25PM +0100, Michal Hocko wrote:
> On Wed 17-03-21 18:59:59, Shakeel Butt wrote:
> > The function swap_readpage() (and other functions it call) extracts swap
> > entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> > skips t
On Wed 17-03-21 18:59:59, Shakeel Butt wrote:
> The function swap_readpage() (and other functions it call) extracts swap
> entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> skips the swapcache and thus we need to manually set the page->private
> with the
On Wed, Mar 17, 2021 at 06:59:59PM -0700, Shakeel Butt wrote:
> The function swap_readpage() (and other functions it call) extracts swap
> entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> skips the swapcache and thus we need to manually set the page->private
The function swap_readpage() (and other functions it call) extracts swap
entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
skips the swapcache and thus we need to manually set the page->private
with the swap entry before calling swap_readpage().
Signed-off-by: Shakee
> +static inline void attach_page_private(struct page *page, void *data)
> +{
> + attach_folio_private((struct folio *)page, data);
> +}
> +
> +static inline void *detach_page_private(struct page *page)
> +{
> + return detach_folio_private((struct folio *)page);
> +}
I hate these open code
gt; > > > From: Subbaraya Sundeep
> > > >
> > > > Memory for driver private structure rvu_devlink is
> > > > also allocated during devlink_alloc. Hence use
> > > > the allocated memory by devlink_alloc and access it
> > > > by devlink_priv call.
On Tue, 16 Mar 2021 23:33:40 +0530 sundeep subbaraya wrote:
> On Tue, Mar 16, 2021 at 10:53 PM Jakub Kicinski wrote:
> >
> > On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> > > From: Subbaraya Sundeep
> > >
> > > Memory for driver p
Hi Jakub,
On Tue, Mar 16, 2021 at 10:53 PM Jakub Kicinski wrote:
>
> On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> > From: Subbaraya Sundeep
> >
> > Memory for driver private structure rvu_devlink is
> > also allocated during devlink_alloc. Hence u
On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> From: Subbaraya Sundeep
>
> Memory for driver private structure rvu_devlink is
> also allocated during devlink_alloc. Hence use
> the allocated memory by devlink_alloc and access it
> by devlink_priv call.
&g
> I really, really hope that someone has thought this through:
>
> Packet Processor I/O Interface (PPIO)
>
>The MUSDK PPIO driver provides low-level network interface API for
>User-Space network drivers/applications. The PPIO infrastrcuture maps
>Marvell's Packet Processor (PPv2) co
On Tue, Mar 16, 2021 at 03:28:51PM +, Stefan Chulski wrote:
> No XDP doesn't require this. One of the use cases of the port reservation
> feature is the Marvell User Space SDK (MUSDK) which its latest code is
> publicly available here:
> https://github.com/MarvellEmbeddedProcessors/musdk-marv
her XDP capable drivers having a
> flag like this. If this was required, i would expect it to be a common
> properly,
> not driver private.
No XDP doesn't require this. One of the use cases of the port reservation
feature is the Marvell User Space SDK (MUSDK) which its latest
Notification private data is currently accessible via handle->notify_priv;
this data was indeed meant to be private to the notification core support
and not to be accessible by SCMI drivers: make it private hiding it inside
instance descriptor struct scmi_info and accessible only via dedica
From: Subbaraya Sundeep
Memory for driver private structure rvu_devlink is
also allocated during devlink_alloc. Hence use
the allocated memory by devlink_alloc and access it
by devlink_priv call.
Fixes: fae06da4("octeontx2-af: Add devlink suppoort to af driver")
Signed-off-by: Subbara
oo.
This difference means the type of the private pointers varies
between control and monitor info dirs.
If the flags are RF_MON_INFO, its a struct rdt_resource. If the
flags are RF_CTRL_INFO, its a struct resctrl_schema. Nothing in
res_common_files[] has both flags.
Reviewed-by: Jamie Iles
Signed
ource doesn't reflect the
>> right level of information.
>>
>> For the info dirs that represent a control, the information needed
>> is in the schema, as this is how the resource is being used. For the
>> monitors, its the resource as L3CODE_MON doesn't make sense, and
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro and
On Thu, 11 Mar 2021 18:43:27 +0200 stef...@marvell.com wrote:
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the same communication processor silicon die
> (CP11x) share the same Classifier and Parser engines.
>
> Armada is an embedded platform and t
e port, and the DT for the CM3
does. Linux never sees the port, since Linux should not be using it.
> or by user-space data plane application.
You mean XDP/AF_XDP? I don't see any other XDP capable drivers having
a flag like this. If this was required, i would expect it to be
ne MVPP22_F_IF_RESERVED BIT(2)
/* Marvell tag types */
enum mvpp2_tag_type {
@@ -1251,6 +1252,9 @@ struct mvpp2_port {
/* Firmware TX flow control */
bool tx_fc;
+
+ /* private storage, allocated/used by Reserved/Normal mode toggling */
+ void *res_cfg;
};
> > From: Stefan Chulski
> >
> > According to Armada SoC architecture and design, all the PPv2 ports
> > which are populated on the same communication processor silicon die
> > (CP11x) share the same Classifier and Parser engines.
> >
> > Armada is an embedded platform and therefore there is a nee
On Wed, Mar 10, 2021 at 11:42:09AM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the same communication processor silicon die
> (CP11x) share the same Classifier and Parser engines.
>
> Ar
> Make it patch series? I can split it to 2/3 patches.
I don't think that will be needed. The helpers should be pretty
obvious.
Andrew
> k...@kernel.org; li...@armlinux.org.uk; m...@semihalf.com;
> rmk+ker...@armlinux.org.uk; aten...@kernel.org; rab...@solid-run.com
> Subject: [EXT] Re: [net-next] net: mvpp2: Add reserved port private flag
> configuration
>
> External Email
>
> --
> static void mvpp2_ethtool_get_strings(struct net_device *netdev, u32 sset,
> u8 *data)
> {
> struct mvpp2_port *port = netdev_priv(netdev);
> int i, q;
>
> - if (sset != ETH_SS_STATS)
> - return;
> + switch (sset) {
> + c
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro and
MVPP22_F_IF_RESERVED BIT(2)
/* Marvell tag types */
enum mvpp2_tag_type {
@@ -1251,6 +1252,9 @@ struct mvpp2_port {
/* Firmware TX flow control */
bool tx_fc;
+
+ /* private storage, allocated/used by Reserved/Normal mode toggling */
+ void *res_cfg;
};
/* The
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro and
On 3/1/21 9:21 PM, Daniel Lezcano wrote:
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is
On Mon, Mar 08, 2021 at 06:12:29AM +, Sudeep Holla wrote:
> On Tue, Feb 02, 2021 at 10:15:53PM +, Cristian Marussi wrote:
> > Notification private data is currently accessible via handle->notify_priv;
> > this data was indeed meant to be private to the notification core s
On Tue, Feb 02, 2021 at 10:15:53PM +, Cristian Marussi wrote:
> Notification private data is currently accessible via handle->notify_priv;
> this data was indeed meant to be private to the notification core support
> and not to be accessible by SCMI drivers: make it private hidi
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data.
Turn attach_page_private() into attach_folio_private() and reimplement
attach_page_private() as a wrapper. No filesystem which uses page
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro and
wxprt->sc_cm_id->event_handler = svc_rdma_cma_handler;
-
/* Construct RDMA-CM private message */
pmsg.cp_magic = rpcrdma_cmp_magic;
pmsg.cp_version = RPCRDMA_CMP_VERSION;
@@ -498,7 +495,10 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt
*xprt)
}
From: Dave Jiang
[ Upstream commit c06e424be5f5184468c5f761c0d2cf1ed0a4e0fc ]
Add DMA_PRIVATE attribute flag to idxd DMA channels. The dedicated WQs are
expected to be used by a single client and not shared. While doing NTB
testing this mistake was discovered, which prevented ntb_transport from
From: Dave Jiang
[ Upstream commit c06e424be5f5184468c5f761c0d2cf1ed0a4e0fc ]
Add DMA_PRIVATE attribute flag to idxd DMA channels. The dedicated WQs are
expected to be used by a single client and not shared. While doing NTB
testing this mistake was discovered, which prevented ntb_transport from
wxprt->sc_cm_id->event_handler = svc_rdma_cma_handler;
-
/* Construct RDMA-CM private message */
pmsg.cp_magic = rpcrdma_cmp_magic;
pmsg.cp_version = RPCRDMA_CMP_VERSION;
@@ -498,7 +495,10 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt
*xprt)
}
When an IOASID set is used for guest SVA, each VM will acquire its
ioasid_set for IOASID allocations. IOASIDs within the VM must have a
host/physical IOASID backing, mapping between guest and host IOASIDs can
be non-identical. IOASID set private ID (SPID) is introduced in this
patch to be used as
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
net/sunrpc/au
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
net/sunrpc/au
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
net/sunrpc/au
Move all client-private data out of `struct kcs_bmc` into the KCS client
implementation.
With this change the KCS BMC core code now only concerns itself with
abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving
expected separation of concerns. Further, the change clears the path
This is a bit of a tidy-up, but also helps with extending the
iioutils_get_type() function a bit, as we don't need to use it outside of
the iio_utils.c file. So, we'll need to update it only in one place.
With this change, the 'unsigned' types are updated to 'unsigned int' in the
iioutils_get_type
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
net/sunrpc/au
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
net/sunrpc/au
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
net/sunrpc/au
1 - 100 of 1694 matches
Mail list logo