Thiago Jung Bauermann writes:
> Ram Pai writes:
...
>> +
>> +/* We got one, store it and use it from here on out */
>> +if (need_to_set_mm_pkey)
>> +mm->context.execute_only_pkey = execute_only_pkey;
>> +return execute_only_pkey;
>> +}
>
> If you follow the code flow in __
On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> Add core infrastructure to support I3C in Linux and document it.
>
> This infrastructure is not complete yet and will be extended over
> time.
>
> There are a few design choices that are worth mentioning because they
> impact the
No longer needed, now all managed by transparent VF logic.
Signed-off-by: Stephen Hemminger
---
tools/hv/bondvf.sh | 255 -
1 file changed, 255 deletions(-)
delete mode 100755 tools/hv/bondvf.sh
diff --git a/tools/hv/bondvf.sh b/tools/hv/bond
This patch set changes how SR-IOV Virtual Function devices are managed
in the Hyper-V network driver. It was part of earlier bundle, but
is now updated.
Background
In Hyper-V SR-IOV can be enabled (and disabled) by changing guest settings
on host. When SR-IOV is enabled a matching PCI device is h
Add some background documentation on netvsc device options
and limitations.
Signed-off-by: Stephen Hemminger
---
Documentation/networking/netvsc.txt | 63 +
MAINTAINERS | 1 +
2 files changed, 64 insertions(+)
create mode 100644 Docum
This patch implements transparent fail over from synthetic NIC to
SR-IOV virtual function NIC in Hyper-V environment. It is a better
alternative to using bonding as is done now. Instead, the receive and
transmit fail over is done internally inside the driver.
Using bonding driver has lots of issue
On Mon, 31 Jul 2017 16:37:12 -0700
Stephen Hemminger wrote:
> The setup of MSI with Hyper-V host was sleeping with locks held.
> This error is reported when doing SR-IOV hotplug with kernel built with
> lockdep.
>
> BUG: sleeping function called from invalid context at
> kernel/sched/compl
This patch set changes how SR-IOV Virtual Function devices are managed
in the Hyper-V network driver. It was part of earlier bundle, but
is now updated.
Background
In Hyper-V SR-IOV can be enabled (and disabled) by changing guest settings
on host. When SR-IOV is enabled a matching PCI device is ho
This patch implements transparent fail over from synthetic NIC to
SR-IOV virtual function NIC in Hyper-V environment. It is a better
alternative to using bonding as is done now. Instead, the receive and
transmit fail over is done internally inside the driver.
Using bonding driver has lots of issue
The setup of MSI with Hyper-V host was sleeping with locks held.
This error is reported when doing SR-IOV hotplug with kernel built with lockdep.
BUG: sleeping function called from invalid context at
kernel/sched/completion.c:93
in_atomic(): 1, irqs_disabled(): 1, pid: 1405, name: ip
Add some background documentation on netvsc device options
and limitations.
Signed-off-by: Stephen Hemminger
---
Documentation/networking/netvsc.txt | 63 +
MAINTAINERS | 1 +
2 files changed, 64 insertions(+)
create mode 100644 Docum
No longer needed, now all managed by transparent VF logic.
Signed-off-by: Stephen Hemminger
---
tools/hv/bondvf.sh | 255 -
1 file changed, 255 deletions(-)
delete mode 100755 tools/hv/bondvf.sh
diff --git a/tools/hv/bondvf.sh b/tools/hv/bond
> Actually, that's the first option I considered, but I3C and I2C are
> really different. I'm not talking about the physical layer here, but
> the way the bus has to be handled by the software layer. Actually, I
> thing the I3C bus is philosophically closer to auto-discoverable busses
> like USB t
On 2017-07-31 23:15, Boris Brezillon wrote:
> [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register
Stupid non-programmers...
This part
65 41 0101 Accelerometer
66 42 0110 Gyroscope
67 43 0111 Magnetometer
68 44 01000100 Accel/Gyro Combo
69 45 01000101 Accel/Mag Combo
Hi Arnd,
Le Mon, 31 Jul 2017 22:16:42 +0200,
Arnd Bergmann a écrit :
> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> wrote:
> > Add core infrastructure to support I3C in Linux and document it.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers an
Le Mon, 31 Jul 2017 21:17:21 +0200,
Wolfram Sang a écrit :
> > +This document is just a brief introduction to the I3C protocol and the
> > concepts
> > +it brings on the table. If you need more information, please refer to the
> > MIPI
> > +I3C specification.
>
> I wish I could.
>
> > +
> >
> > I agree this is the least invasive and also the most compatible
> > approach. The other solution would probably be to have some kind of
> > emulation layer?
>
> Could you detail a bit more what you mean by "emulation layer"?
Not really. That was more a extremly high level approach of what
th
Hi Wolfram,
Le Mon, 31 Jul 2017 21:17:45 +0200,
Wolfram Sang a écrit :
> Hi Boris,
>
> > This patch series is a proposal for a new I3C [1] subsystem.
>
> Nice. Good luck with that!
>
> Some hi-level comments from me related to I2C. I can't say a lot more
> because the specs are not public
On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
wrote:
> Add core infrastructure to support I3C in Linux and document it.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a
Hi Boris,
> This patch series is a proposal for a new I3C [1] subsystem.
Nice. Good luck with that!
Some hi-level comments from me related to I2C. I can't say a lot more
because the specs are not public :(
> - the bus element is a separate object and is not implicitly described
> by the maste
> +This document is just a brief introduction to the I3C protocol and the
> concepts
> +it brings on the table. If you need more information, please refer to the
> MIPI
> +I3C specification.
I wish I could.
> +
> +Introduction
> +
> +
> +The I3C (I-Cube-C) is a MIPI standardized pr
Ram Pai writes:
> static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
> {
> - return -EINVAL;
> + if (!pkey_inited)
> + return -1;
Sorry, I missed this earlier but the pkey_free syscall will pass this
value to userspace so it needs to be an errno as well (-EINVAL
On Mon, Jul 31, 2017 at 11:53:35AM -0400, Sean Anderson wrote:
> - i_mutex(inode)
> -lookup: yes
> + i_rwsem(inode)
> +lookup: shared
> create: yes
Could you change all the 'yes' to 'exclusive' when it's changed from mutex
to rwsem?
On 07/25/2017 08:55 AM, Luis R. Rodriguez wrote:
> On Tue, Jul 25, 2017 at 08:17:26AM -0400, Prarit Bhargava wrote:
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index fc47863f629c..26cf6cadd267 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -120
This patch series is a proposal for a new I3C [1] subsystem.
This infrastructure is not complete yet and will be extended over
time.
There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:
- all functions used to se
A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.
Document this generic representation.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++
1 file
Add a driver for Cadence I3C master IP.
Signed-off-by: Boris Brezillon
---
drivers/i3c/master/Kconfig |4 +
drivers/i3c/master/Makefile |1 +
drivers/i3c/master/i3c-master-cdns.c | 1382 ++
3 files changed, 1387 insertions(+)
create mod
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
diff --git a/Documentation/d
I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.
We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure bec
Ram Pai writes:
> On Fri, Jul 28, 2017 at 07:17:13PM -0300, Thiago Jung Bauermann wrote:
>>
>> Ram Pai writes:
>> > --- a/arch/powerpc/mm/pkeys.c
>> > +++ b/arch/powerpc/mm/pkeys.c
>> > @@ -97,3 +97,60 @@ int __arch_set_user_pkey_access(struct task_struct
>> > *tsk, int pkey,
>> >init_iam
Documentation/filesystems/Locking no longer reflects current locking
semantics. i_mutex is no longer used for locking, and has been superseded
by i_rwsem. Additionally, ->iterate_shared() was not documented.
Signed-off-by: Sean Anderson
---
Documentation/filesystems/Locking | 15 ++-
Ram Pai writes:
> On Thu, Jul 27, 2017 at 02:32:59PM -0300, Thiago Jung Bauermann wrote:
>> Ram Pai writes:
>> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>> > index 2ad725e..9429361 100644
>> > --- a/arch/powerpc/kernel/process.c
>> > +++ b/arch/powerpc/kernel/pr
Hi Jintack,
On Tue, Jul 18, 2017 at 11:58:26AM -0500, Jintack Lim wrote:
> Nested virtualization is the ability to run a virtual machine inside another
> virtual machine. In other words, it’s about running a hypervisor (the guest
> hypervisor) on top of another hypervisor (the host hypervisor).
>
On Tue, Jul 18, 2017 at 11:59:04AM -0500, Jintack Lim wrote:
> Forward CPACR_EL1 traps to the virtual EL2 if virtual CPTR_EL2 is
> configured to trap CPACR_EL1 accesses from EL1.
>
> This is for recursive nested virtualization.
>
> Signed-off-by: Jintack Lim
> ---
> arch/arm64/kvm/sys_regs.c |
Ram Pai writes:
> On Thu, Jul 27, 2017 at 11:54:31AM -0300, Thiago Jung Bauermann wrote:
>>
>> Ram Pai writes:
>>
>> > --- a/arch/powerpc/include/asm/pkeys.h
>> > +++ b/arch/powerpc/include/asm/pkeys.h
>> > @@ -2,6 +2,18 @@
>> > #define _ASM_PPC64_PKEYS_H
>> >
>> > extern bool pkey_inited;
>
On Tue, Jul 18, 2017 at 11:59:03AM -0500, Jintack Lim wrote:
> Forward ELR_EL1, SPSR_EL1 and VBAR_EL1 traps to the virtual EL2 if the
> virtual HCR_EL2.NV bit is set.
>
> This is for recursive nested virtualization.
>
> Signed-off-by: Jintack Lim
> ---
> arch/arm64/include/asm/kvm_arm.h | 1 +
On Tue, Jul 18, 2017 at 11:59:02AM -0500, Jintack Lim wrote:
> Forward the EL1 virtual memory register traps to the virtual EL2 if they
> are not coming from the virtual EL2 and the virtual HCR_EL2.TVM or TRVM
> bit is set.
I noticed that all these recursive patches don't change how we program
the
On Tue, Jul 18, 2017 at 11:59:01AM -0500, Jintack Lim wrote:
> In addition to EL2 register accesses, setting NV bit will also make EL12
> register accesses trap to EL2. To emulate this for the virtual EL2,
> forword traps due to EL12 register accessses to the virtual EL2 if the
> virtual HCR_EL2.NV
Hi Catalin,
On Thu, Jul 27, 2017 at 06:12:22PM +0100, Catalin Marinas wrote:
> Hi Yury,
>
> On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
[...]
> > This is the 4.12 and linux-next - based kernel patches:
> > https://github.com/norov/linux/tree/ilp32-4.12
> > https://github.com/nor
On Tue, Jul 18, 2017 at 11:58:59AM -0500, Jintack Lim wrote:
> Now that the virtual EL2 can access EL2 register states via EL1
> registers, we need to consider it when selecting the register to
> emulate.
I don't really understand what this patch does from the commit message.
>From looking at the
On Tue, Jul 18, 2017 at 11:58:58AM -0500, Jintack Lim wrote:
> While the EL1 virtual memory control registers can be accessed in the
> virtual EL2 with VHE without trap to manuplate the virtual EL2 states,
> we can't do that for CPTR_EL2 for an unfortunate reason.
>
> This is because the top bit o
On Tue, Jul 18, 2017 at 11:58:57AM -0500, Jintack Lim wrote:
In the subject: s/virtual E2H bit enabled/virtual E2H bit is set/
> When creating the shadow context for the virtual EL2 execution, we can
> directly copy the EL2 register states to the shadow EL1 register states
> if the virtual HCR_EL
On Tue, Jul 18, 2017 at 11:58:56AM -0500, Jintack Lim wrote:
> When the virtual E2H bit is set, we can support EL2 register accesses
> via EL1 registers from the virtual EL2 by doing trap-and-emulate. A
> better alternative, however, is to allow the virtual EL2 to access EL2
> register states witho
On Tue, Jul 18, 2017 at 11:58:55AM -0500, Jintack Lim wrote:
nit: The subject is a little hard to understand.
> On VHE systems, EL0 of the host kernel is considered as a part of 'VHE
> host'; The execution of EL0 is affected by system registers set by the
> VHE kernel including the hypervisor. To
On Tue, Jul 18, 2017 at 11:58:54AM -0500, Jintack Lim wrote:
> With HCR_EL2.NV bit set, accesses to EL12 registers in the virtual EL2
> trap to EL2. Handle those traps just like we do for EL1 registers.
>
> One exception is CNTKCTL_EL12. We don't trap on CNTKCTL_EL1 for non-VHE
> virtual EL2 becau
45 matches
Mail list logo
