On Fri, Jul 21, 2017 at 06:49:42PM -0500, Grygorii Strashko wrote:
> There could be significant delay in CPTS work schedule under high system
> load and on -RT which could cause CPTS misbehavior due to internal counter
> overflow. Usage of own kthread_worker allows to avoid such kind of issues
>
On Fri, Jul 21, 2017 at 06:49:42PM -0500, Grygorii Strashko wrote:
> There could be significant delay in CPTS work schedule under high system
> load and on -RT which could cause CPTS misbehavior due to internal counter
> overflow. Usage of own kthread_worker allows to avoid such kind of issues
>
Hi Sinan, Bjorn:
On 2017/7/14 21:54, Sinan Kaya wrote:
> On 7/13/2017 9:26 PM, Ding Tianhong wrote:
>> There is no code to enable the PCIe Relaxed Ordering bit in the
>> configuration space,
>> it is only be enable by default according to the PCIe Standard
>> Specification, what we
>> do is to
Hi Sinan, Bjorn:
On 2017/7/14 21:54, Sinan Kaya wrote:
> On 7/13/2017 9:26 PM, Ding Tianhong wrote:
>> There is no code to enable the PCIe Relaxed Ordering bit in the
>> configuration space,
>> it is only be enable by default according to the PCIe Standard
>> Specification, what we
>> do is to
From: Hanjun Guo
When running 4.13-rc1 on top of D05, I got the boot log:
[0.00] SRAT: PXM 0 -> ITS 0 -> Node 0
[0.00] SRAT: PXM 0 -> ITS 1 -> Node 0
[0.00] SRAT: PXM 0 -> ITS 2 -> Node 0
[0.00] SRAT: PXM 1 -> ITS 3 -> Node 1
[0.00]
From: Hanjun Guo
When running 4.13-rc1 on top of D05, I got the boot log:
[0.00] SRAT: PXM 0 -> ITS 0 -> Node 0
[0.00] SRAT: PXM 0 -> ITS 1 -> Node 0
[0.00] SRAT: PXM 0 -> ITS 2 -> Node 0
[0.00] SRAT: PXM 1 -> ITS 3 -> Node 1
[0.00] SRAT: ITS affinity
On 2017/7/21 19:42, Ganapatrao Kulkarni wrote:
> Hi Hanjun,
>
>
> On Fri, Jul 21, 2017 at 4:50 PM, Marc Zyngier wrote:
>> On 21/07/17 11:06, Hanjun Guo wrote:
>>> On 2017/7/21 17:51, Hanjun Guo wrote:
From: Hanjun Guo
When running
On 2017/7/21 19:42, Ganapatrao Kulkarni wrote:
> Hi Hanjun,
>
>
> On Fri, Jul 21, 2017 at 4:50 PM, Marc Zyngier wrote:
>> On 21/07/17 11:06, Hanjun Guo wrote:
>>> On 2017/7/21 17:51, Hanjun Guo wrote:
From: Hanjun Guo
When running 4.13-rc1 on top of D05, I got the boot log:
Fixed checkpatch errors of "please, no spaces at the start of a line"
Signed-off-by: Derek Robson
---
drivers/staging/pi433/rf69.c | 4 +-
drivers/staging/pi433/rf69_enum.h | 206 +++---
2 files changed, 105 insertions(+), 105
Fixed checkpatch errors of "please, no spaces at the start of a line"
Signed-off-by: Derek Robson
---
drivers/staging/pi433/rf69.c | 4 +-
drivers/staging/pi433/rf69_enum.h | 206 +++---
2 files changed, 105 insertions(+), 105 deletions(-)
diff --git
Fixed checkpatch errors of "no space before tabs"
Signed-off-by: Derek Robson
---
drivers/staging/pi433/pi433_if.c | 12 ++--
drivers/staging/pi433/pi433_if.h | 4 ++--
drivers/staging/pi433/rf69.c | 8
drivers/staging/pi433/rf69.h | 6 +++---
4
Fixed checkpatch errors of "no space before tabs"
Signed-off-by: Derek Robson
---
drivers/staging/pi433/pi433_if.c | 12 ++--
drivers/staging/pi433/pi433_if.h | 4 ++--
drivers/staging/pi433/rf69.c | 8
drivers/staging/pi433/rf69.h | 6 +++---
4 files changed, 15
Fixed the alignment of block comments
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/pi433/pi433_if.c | 38 +++--
drivers/staging/pi433/rf69.c | 10 +-
drivers/staging/pi433/rf69_registers.h | 280 -
3
Fixed the alignment of block comments
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/pi433/pi433_if.c | 38 +++--
drivers/staging/pi433/rf69.c | 10 +-
drivers/staging/pi433/rf69_registers.h | 280 -
3 files changed, 169
Assorted styel fix across whole driver
Found using checkpatch
Derek Robson (3):
staging: pi433: Style fix - align block comments
staging: pi433: - style fix, space before tabs
staging: pi433: - style fix, space at start of line
drivers/staging/pi433/pi433_if.c | 50 +++---
Assorted styel fix across whole driver
Found using checkpatch
Derek Robson (3):
staging: pi433: Style fix - align block comments
staging: pi433: - style fix, space before tabs
staging: pi433: - style fix, space at start of line
drivers/staging/pi433/pi433_if.c | 50 +++---
Hi Martin,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc1 next-20170721]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Martin-Wilck/Improve-readbility-of-NVME
Hi Martin,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc1 next-20170721]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Martin-Wilck/Improve-readbility-of-NVME
On 2017/7/21 19:20, Marc Zyngier wrote:
> On 21/07/17 11:06, Hanjun Guo wrote:
>> On 2017/7/21 17:51, Hanjun Guo wrote:
>>> From: Hanjun Guo
>>>
>>> When running 4.13-rc1 on top of D05, I got the boot log:
>>>
>>> [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0
>>> [
On 2017/7/21 19:20, Marc Zyngier wrote:
> On 21/07/17 11:06, Hanjun Guo wrote:
>> On 2017/7/21 17:51, Hanjun Guo wrote:
>>> From: Hanjun Guo
>>>
>>> When running 4.13-rc1 on top of D05, I got the boot log:
>>>
>>> [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0
>>> [0.00] SRAT: PXM 0 -> ITS
From: Elaine Zhang
The RK808 and RK805 PMICs are using a similar register map.
We can reuse the clk driver for the RK805 PMIC. So let's add
the RK805 in the Kconfig description.
Signed-off-by: Elaine Zhang
---
drivers/clk/Kconfig | 4 ++--
1
From: Elaine Zhang
The RK808 and RK805 PMICs are using a similar register map.
We can reuse the clk driver for the RK805 PMIC. So let's add
the RK805 in the Kconfig description.
Signed-off-by: Elaine Zhang
---
drivers/clk/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On Fri, Jul 21, 2017 at 2:22 PM, Andrew Morton
wrote:
> On Thu, 20 Jul 2017 11:11:06 +0200 Ingo Molnar wrote:
>
>>
>> * Kees Cook wrote:
>>
>> > This implements refcount_t overflow protection on x86 without a noticeable
>> >
On Fri, Jul 21, 2017 at 2:22 PM, Andrew Morton
wrote:
> On Thu, 20 Jul 2017 11:11:06 +0200 Ingo Molnar wrote:
>
>>
>> * Kees Cook wrote:
>>
>> > This implements refcount_t overflow protection on x86 without a noticeable
>> > performance impact, though without the fuller checking of
Hi Ganapat,
On 2017/6/8 12:44, Ganapatrao Kulkarni wrote:
> Add code to parse proximity domain in SMMUv3 IORT table to
> set numa node mapping for smmuv3 devices.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> drivers/acpi/arm64/iort.c | 28
Hi Ganapat,
On 2017/6/8 12:44, Ganapatrao Kulkarni wrote:
> Add code to parse proximity domain in SMMUv3 IORT table to
> set numa node mapping for smmuv3 devices.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> drivers/acpi/arm64/iort.c | 28 ++--
> 1 file changed, 26
在 2017-05-29 15:34,Chen-Yu Tsai 写道:
Hi,
On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.
Add support for it.
Signed-off-by: Icenowy Zheng
在 2017-05-29 15:34,Chen-Yu Tsai 写道:
Hi,
On Sat, May 27, 2017 at 06:23:06PM +0800, Icenowy Zheng wrote:
Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in
[ adding Chris ]
On Fri, Jul 21, 2017 at 4:44 PM, Dan Williams wrote:
> On Fri, Jul 21, 2017 at 3:58 PM, Ingo Molnar wrote:
>>
>> * Dan Williams wrote:
>>
>>> [...]
>>>
>>> * Like perf, ndctl borrows the sub-command
[ adding Chris ]
On Fri, Jul 21, 2017 at 4:44 PM, Dan Williams wrote:
> On Fri, Jul 21, 2017 at 3:58 PM, Ingo Molnar wrote:
>>
>> * Dan Williams wrote:
>>
>>> [...]
>>>
>>> * Like perf, ndctl borrows the sub-command architecture and option
>>> parsing from git. So, this code could be
This patchset contains only two patches.
The first one is a minor fix for the A10 pinctrl driver, add a function
of a pin, which used to be missing in A10/A20 pinctrl driver. Thanks for
Chen-Yu for discovering it when reviewing my R40 pinctrl patchset.
The second one is the real R40 pinctrl
This patchset contains only two patches.
The first one is a minor fix for the A10 pinctrl driver, add a function
of a pin, which used to be missing in A10/A20 pinctrl driver. Thanks for
Chen-Yu for discovering it when reviewing my R40 pinctrl patchset.
The second one is the real R40 pinctrl
R40 is said to be an upgrade of A20, and its pin configuration is also
similar to A20 (and thus similar to A10).
Add support for R40 to the A10 pinctrl driver.
Signed-off-by: Icenowy Zheng
Reviewed-by: Chen-Yu Tsai
---
Changes in v3:
- Fixed a missing comma in
R40 is said to be an upgrade of A20, and its pin configuration is also
similar to A20 (and thus similar to A10).
Add support for R40 to the A10 pinctrl driver.
Signed-off-by: Icenowy Zheng
Reviewed-by: Chen-Yu Tsai
---
Changes in v3:
- Fixed a missing comma in v2.
- Added Chen-Yu's review tag.
The PH16 pin has a function with mux id 0x5, which is the DET pin of the
"sim" (smart card reader) IP block.
This function is missing in old versions of A10/A20 SoCs' datasheets and
user manuals, so it's also missing in the old drivers. The newest A10
Datasheet V1.70 and A20 Datasheet V1.41
The PH16 pin has a function with mux id 0x5, which is the DET pin of the
"sim" (smart card reader) IP block.
This function is missing in old versions of A10/A20 SoCs' datasheets and
user manuals, so it's also missing in the old drivers. The newest A10
Datasheet V1.70 and A20 Datasheet V1.41
The SoPine official baseboard uses the A64 chip's EMAC to provide an
Ethernet link.
Add the ethernet0 alias in the device tree, in order to let U-Boot
generate a MAC address from the chip's SID.
Signed-off-by: Icenowy Zheng
---
The SoPine official baseboard uses the A64 chip's EMAC to provide an
Ethernet link.
Add the ethernet0 alias in the device tree, in order to let U-Boot
generate a MAC address from the chip's SID.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts | 1
Allwinner A64 SoC has an EMAC which is used to provide Ethernet
function on several boards.
The EMAC itself doesn't have a fixed MAC address, but the sunxi
mainline U-Boot have the ability to generate one based on the eFUSE
SID in the chip, and add the generated MAC address to the device
tree
The Pine64 (including the Plus models) board uses the A64 chip's
EMAC to provide Ethernet link.
Add the ethernet0 alias in the device tree, in order to let U-Boot
generate a MAC address from the chip's SID.
Signed-off-by: Icenowy Zheng
---
Allwinner A64 SoC has an EMAC which is used to provide Ethernet
function on several boards.
The EMAC itself doesn't have a fixed MAC address, but the sunxi
mainline U-Boot have the ability to generate one based on the eFUSE
SID in the chip, and add the generated MAC address to the device
tree
The Pine64 (including the Plus models) board uses the A64 chip's
EMAC to provide Ethernet link.
Add the ethernet0 alias in the device tree, in order to let U-Boot
generate a MAC address from the chip's SID.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |
The Banana Pi M64 board uses the A64 chip's EMAC to provide Ethernet
link.
Add the ethernet0 alias in the device tree, in order to let U-Boot
generate a MAC address from the chip's SID.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
The Banana Pi M64 board uses the A64 chip's EMAC to provide Ethernet
link.
Add the ethernet0 alias in the device tree, in order to let U-Boot
generate a MAC address from the chip's SID.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 1 +
1 file
The SoPine SoM has an AXP803 PMIC connected to the RSB bus of the A64
SoC, and the regulators of the PMIC are used both on the SoM itself and
on the official baseboard
Add related device tree parts to the SoPine SoM DTSI file and the
baseboard DT.
Signed-off-by: Icenowy Zheng
Add support of AXP803 regulators in the Pine64 device tree.
The phy-supply regulator is also set in EMAC device node, in order to
prevent Ethernet regression by regulator get disabled by regulator
framework.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Change the min
The SoPine SoM has an AXP803 PMIC connected to the RSB bus of the A64
SoC, and the regulators of the PMIC are used both on the SoM itself and
on the official baseboard
Add related device tree parts to the SoPine SoM DTSI file and the
baseboard DT.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
Add support of AXP803 regulators in the Pine64 device tree.
The phy-supply regulator is also set in EMAC device node, in order to
prevent Ethernet regression by regulator get disabled by regulator
framework.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Change the min voltage of vdd-cpux to
The Pine64 and SoPine w/ baseboard boards have an AXP803 PMIC, and the
regulators of the PMIC are used.
This patchset adds the regulators to the device tree of these two boards.
The first patch is for Pine64 and the second if for SoPine w/ official
baseboard.
The patches that drop the dummy
The Pine64 and SoPine w/ baseboard boards have an AXP803 PMIC, and the
regulators of the PMIC are used.
This patchset adds the regulators to the device tree of these two boards.
The first patch is for Pine64 and the second if for SoPine w/ official
baseboard.
The patches that drop the dummy
On Fri, Jul 21, 2017 at 1:32 PM, Randy Dunlap wrote:
>
> and send with correct file encoding!
Congratulations, you were indeed successful in fixing whatever locale
issue that was biting you.
Linus
On Fri, Jul 21, 2017 at 1:32 PM, Randy Dunlap wrote:
>
> and send with correct file encoding!
Congratulations, you were indeed successful in fixing whatever locale
issue that was biting you.
Linus
Changes from V1 (https://lkml.org/lkml/2017/7/20/180)
* Refactor topology extension logic into __get_topoext() (per Boris)
Suravee Suthikulpanit (2):
x86/amd: Refactor topology extension related code
x86/amd: Fixup cpu_core_id for family17h downcore configuration
arch/x86/kernel/cpu/amd.c
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system with downcore configuration
(where not all physical cores within a die are available), this could
result in the case where
Refactoring in preparation for subsequent changes.
There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/amd.c | 79 ++-
1 file changed, 44 insertions(+), 35 deletions(-)
diff --git
Changes from V1 (https://lkml.org/lkml/2017/7/20/180)
* Refactor topology extension logic into __get_topoext() (per Boris)
Suravee Suthikulpanit (2):
x86/amd: Refactor topology extension related code
x86/amd: Fixup cpu_core_id for family17h downcore configuration
arch/x86/kernel/cpu/amd.c
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system with downcore configuration
(where not all physical cores within a die are available), this could
result in the case where
Refactoring in preparation for subsequent changes.
There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kernel/cpu/amd.c | 79 ++-
1 file changed, 44 insertions(+), 35 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c
On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki wrote:
> On Tuesday, July 18, 2017 06:04:19 PM Andy Shevchenko wrote:
>> Some platform might take care of legacy devices on theirs own.
>> Let's allow them to do that by exporting a weak function.
>>
>> Signed-off-by: Andy
On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki wrote:
> On Tuesday, July 18, 2017 06:04:19 PM Andy Shevchenko wrote:
>> Some platform might take care of legacy devices on theirs own.
>> Let's allow them to do that by exporting a weak function.
>>
>> Signed-off-by: Andy Shevchenko
>
> I'd
On Sat, Jul 22, 2017 at 1:28 AM, Rafael J. Wysocki wrote:
> On Tuesday, July 18, 2017 06:04:20 PM Andy Shevchenko wrote:
>> As per note in 5.2.9 Fixed ACPI Description Table (FADT) chapter of ACPI
>> specification OSPM will ignore fields related to the ACPI HW register
>>
On Sat, Jul 22, 2017 at 1:28 AM, Rafael J. Wysocki wrote:
> On Tuesday, July 18, 2017 06:04:20 PM Andy Shevchenko wrote:
>> As per note in 5.2.9 Fixed ACPI Description Table (FADT) chapter of ACPI
>> specification OSPM will ignore fields related to the ACPI HW register
>> interface, one of which
Fixed alignment of all block comments.
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/bluetooth/ath3k.c | 3 ++-
drivers/bluetooth/bt3c_cs.c | 8 +---
drivers/bluetooth/btmrvl_sdio.c | 6 --
drivers/bluetooth/btsdio.c | 3 ++-
Fixed alignment of all block comments.
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/bluetooth/ath3k.c | 3 ++-
drivers/bluetooth/bt3c_cs.c | 8 +---
drivers/bluetooth/btmrvl_sdio.c | 6 --
drivers/bluetooth/btsdio.c | 3 ++-
On 7/17/2017 9:45 PM, santosh.shilim...@oracle.com wrote:
On 7/17/17 8:26 PM, Suman Anna wrote:
Hi Santosh,
The following patch series adds the necessary defconfig options to
keystone_defconfig to enable the TI-SCI protocol and their respective
genpd/clock/reset drivers.
This is the first
On 7/17/2017 9:45 PM, santosh.shilim...@oracle.com wrote:
On 7/17/17 8:26 PM, Suman Anna wrote:
Hi Santosh,
The following patch series adds the necessary defconfig options to
keystone_defconfig to enable the TI-SCI protocol and their respective
genpd/clock/reset drivers.
This is the first
From: Chao Yu
When ->freeze_fs is called from lvm for doing snapshot, it needs to
make sure there will be no more changes in filesystem's data, however,
previously, background threads like GC thread wasn't aware of freezing,
so in environment with active background threads,
From: Chao Yu
When ->freeze_fs is called from lvm for doing snapshot, it needs to
make sure there will be no more changes in filesystem's data, however,
previously, background threads like GC thread wasn't aware of freezing,
so in environment with active background threads, data of snapshot
(Cc netdev and Intel)
On Tue, Jul 18, 2017 at 1:57 PM, Justin Piszcz wrote:
> Hello,
>
> Kernel: 4.12.0
> Arch: x86_64
>
> What causes this issue?
It is likely a igb driver issue.
>
> [199141.434449] NETDEV WATCHDOG: eth1 (igb): transmit queue 7 timed out
>
(Cc netdev and Intel)
On Tue, Jul 18, 2017 at 1:57 PM, Justin Piszcz wrote:
> Hello,
>
> Kernel: 4.12.0
> Arch: x86_64
>
> What causes this issue?
It is likely a igb driver issue.
>
> [199141.434449] NETDEV WATCHDOG: eth1 (igb): transmit queue 7 timed out
> [199141.434501] [ cut
Hi Jaegeuk,
On 2017/7/22 4:54, Jaegeuk Kim wrote:
> Hi Chao,
>
> On 07/21, Chao Yu wrote:
>> When ->freeze_fs is called from lvm for doing snapshot, it needs to
>> make sure there will be no more changes in filesystem's data, however,
>> previously, background GC wasn't aware of freezing, so in
Hi Jaegeuk,
On 2017/7/22 4:54, Jaegeuk Kim wrote:
> Hi Chao,
>
> On 07/21, Chao Yu wrote:
>> When ->freeze_fs is called from lvm for doing snapshot, it needs to
>> make sure there will be no more changes in filesystem's data, however,
>> previously, background GC wasn't aware of freezing, so in
Hi Qiuyang,
This fails xfstests/generic/413.
Thanks,
On 07/20, sunqiuyang wrote:
> From: Qiuyang Sun
>
> This patch implements Direct Access (DAX) in F2FS, including:
> - a mount option to choose whether to enable DAX or not
> - read/write and mmap of regular files in
Hi Qiuyang,
This fails xfstests/generic/413.
Thanks,
On 07/20, sunqiuyang wrote:
> From: Qiuyang Sun
>
> This patch implements Direct Access (DAX) in F2FS, including:
> - a mount option to choose whether to enable DAX or not
> - read/write and mmap of regular files in the DAX way
> -
Andi Kleen [a...@firstfloor.org] wrote:
> From: Andi Kleen
>
> Today, when a JSON file fails parsing the build continues,
> but there are no json files built in, which is difficult to debug later.
> Make the build stop on a parse error instead.
I see the problem and we
Andi Kleen [a...@firstfloor.org] wrote:
> From: Andi Kleen
>
> Today, when a JSON file fails parsing the build continues,
> but there are no json files built in, which is difficult to debug later.
> Make the build stop on a parse error instead.
I see the problem and we were being defensive to
Implement the probe function for the pvcalls frontend. Read the
supported versions, max-page-order and function-calls nodes from
xenstore.
Introduce a data structure named pvcalls_bedata. It contains pointers to
the command ring, the event channel, a list of active sockets and a list
of passive
Implement the probe function for the pvcalls frontend. Read the
supported versions, max-page-order and function-calls nodes from
xenstore.
Introduce a data structure named pvcalls_bedata. It contains pointers to
the command ring, the event channel, a list of active sockets and a list
of passive
Send a PVCALLS_SOCKET command to the backend, use the masked
req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array
ready for the response, and there cannot be two outstanding responses
with the same req_id.
Wait
Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for
the active socket.
Introduce a data structure to keep track of sockets. Introduce a
waitqueue to allow the frontend to wait on data coming from the backend
on the active socket (recvmsg command).
Two mutexes (one of reads
Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for
the active socket.
Introduce a data structure to keep track of sockets. Introduce a
waitqueue to allow the frontend to wait on data coming from the backend
on the active socket (recvmsg command).
Two mutexes (one of reads
Send a PVCALLS_SOCKET command to the backend, use the masked
req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array
ready for the response, and there cannot be two outstanding responses
with the same req_id.
Wait
Introduce a xenbus frontend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
This patch only adds the stubs, the code will be added by the following
patches.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC:
Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
sure that only one accept command is executed at any given time by
setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
inflight_accept_req waitqueue.
sock->sk->sk_send_head is not used for ip sockets: reuse the field to
Introduce a xenbus frontend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
This patch only adds the stubs, the code will be added by the following
patches.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
sure that only one accept command is executed at any given time by
setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
inflight_accept_req waitqueue.
sock->sk->sk_send_head is not used for ip sockets: reuse the field to
Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring at any given time.
If not enough data is available on
Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring at any given time.
If not enough data is available on
Also add pvcalls-front to the Makefile.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/Kconfig | 9 +
drivers/xen/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/xen/Kconfig
Also add pvcalls-front to the Makefile.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/Kconfig | 9 +
drivers/xen/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index
Send data to an active socket by copying data to the "out" ring. Take
the active socket out_mutex so that only one function can access the
ring at any given time.
If not enough room is available on the ring, rather than returning
immediately or sleep-waiting, spin for up to 5000 cycles. This
Send data to an active socket by copying data to the "out" ring. Take
the active socket out_mutex so that only one function can access the
ring at any given time.
If not enough room is available on the ring, rather than returning
immediately or sleep-waiting, spin for up to 5000 cycles. This
Implement pvcalls frontend removal function. Go through the list of
active and passive sockets and free them all, one at a time.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 28
Implement pvcalls frontend removal function. Go through the list of
active and passive sockets and free them all, one at a time.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 28
1 file
Send PVCALLS_BIND to the backend. Introduce a new structure, part of
struct sock_mapping, to store information specific to passive sockets.
Introduce a status field to keep track of the status of the passive
socket.
Introduce a waitqueue for the "accept" command (see the accept command
Send PVCALLS_LISTEN to the backend.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 49 +
drivers/xen/pvcalls-front.h | 1 +
2 files changed, 50 insertions(+)
Send PVCALLS_LISTEN to the backend.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-front.c | 49 +
drivers/xen/pvcalls-front.h | 1 +
2 files changed, 50 insertions(+)
diff --git
Send PVCALLS_BIND to the backend. Introduce a new structure, part of
struct sock_mapping, to store information specific to passive sockets.
Introduce a status field to keep track of the status of the passive
socket.
Introduce a waitqueue for the "accept" command (see the accept command
Hi all,
this series introduces the frontend for the newly introduced PV Calls
procotol.
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them
Hi all,
this series introduces the frontend for the newly introduced PV Calls
procotol.
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them
1 - 100 of 1478 matches
Mail list logo