On Wed, Mar 20, 2019 at 05:02:57PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 20/03/2019 13:58, Sam Bobroff wrote:
> > The EEH_DEV_NO_HANDLER flag is used by the EEH system to prevent the
> > use of driver callbacks in drivers that have been bound part way
> > through the recovery process. This
On Sat, Mar 30, 2019 at 01:54:29PM +0800, Yue Haibing wrote:
> From: YueHaibing
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/crypto/nx/nx-842.c: In function 'decompress':
> drivers/crypto/nx/nx-842.c:356:25: warning: variable 'dpadding' set but not
> used [-Wunused-but-set-var
On 8/4/19 1:08 pm, Christopher M. Riedl wrote:
Operations which write to memory and special purpose registers should be
restricted on systems with integrity guarantees (such as Secure Boot)
and, optionally, to avoid self-destructive behaviors.
Add a config option, XMON_RW, to control default xmo
This is the KVM update to the new idle code. A few improvements:
- Idle sleepers now always return to caller rather than branch out
to KVM first.
- This allows optimisations like very fast return to caller when no
state has been lost.
- KVM no longer requires nap_state_lost because it controls
Reimplement Book3S idle code in C, moving POWER7/8/9 implementation
speific HV idle code to the powernv platform code.
Book3S assembly stubs are kept in common code and used only to save
the stack frame and non-volatile GPRs before executing architected
idle instructions, and restoring the stack a
On Mon, 8 Apr 2019, Leizhen (ThunderTown) wrote:
> >
> > This will break systems using boot options as now, and I think
> > this is unacceptable. If you want to do so, just introduce iommu.dma_mode
> > on top of those iommu boot options with dma mode boot options unchanged,
> > and iommu.dma_mode
On Mon, Apr 8, 2019 at 1:06 PM Christopher M. Riedl wrote:
>
> Operations which write to memory and special purpose registers should be
> restricted on systems with integrity guarantees (such as Secure Boot)
> and, optionally, to avoid self-destructive behaviors.
>
> Add a config option, XMON_RW,
On Tue, Apr 02, 2019 at 03:31:01PM +1100, Alexey Kardashevskiy wrote:
> When called with vmas_arg==NULL, get_user_pages_longterm() allocates
> an array of nr_pages*8 which can easily get greater that the max order,
> for example, registering memory for a 256GB guest does this and fails
> in __alloc
On 2019/4/8 9:14, Hanjun Guo wrote:
> Hi Zhen,
>
> On 2019/4/7 20:41, Zhen Lei wrote:
>> As Robin Murphy's suggestion:
>> "It's also not necessarily obvious to the user how this interacts with
>> IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it
>> would be better to re
Operations which write to memory and special purpose registers should be
restricted on systems with integrity guarantees (such as Secure Boot)
and, optionally, to avoid self-destructive behaviors.
Add a config option, XMON_RW, to control default xmon behavior along
with kernel cmdline options xmon
Hi Zhen,
On 2019/4/7 20:41, Zhen Lei wrote:
> As Robin Murphy's suggestion:
> "It's also not necessarily obvious to the user how this interacts with
> IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it
> would be better to refactor the whole lot into a single selection of s
On Tue, 2 Apr 2019 15:30:35 +0900
William Breathitt Gray wrote:
> Changes in v10:
> - Fix minor typographical errors in documentation
> - Merge the FlexTimer Module Quadrature decoder counter driver patches
>
> This revision is functionally identical to the last; changes in this
> version w
iommu=pt can be replaced with iommu.dma_mode=passthrough.
iommu=nopt can be replaced with iommu.dma_mode=lazy.
intel_iommu=strict can be replaced with iommu.dma_mode=strict.
amd_iommu=fullflush can be replaced with iommu.dma_mode=strict.
Note: intel_iommu_strict is not deleted because it can also
iommu=nobypass can be replaced with iommu.dma_mode=strict.
Signed-off-by: Zhen Lei
---
Documentation/admin-guide/kernel-parameters.txt | 2 --
arch/powerpc/platforms/powernv/pci-ioda.c | 23 +--
drivers/iommu/Kconfig | 1 +
3 files changed, 2
As Robin Murphy's suggestion:
"It's also not necessarily obvious to the user how this interacts with
IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it
would be better to refactor the whole lot into a single selection of something
like IOMMU_DEFAULT_MODE anyway."
In this ve
Add IOMMU_DMA_MODE_IS_LAZY() and IOMMU_DMA_MODE_IS_PASSTHROUGH() to make
the code looks cleaner.
There is no functional change, just prepare for the following patches.
Signed-off-by: Zhen Lei
---
drivers/iommu/iommu.c | 12
include/linux/iommu.h | 11 +++
2 files changed, 1
Currently the IOMMU dma contains 3 modes: passthrough, lazy, strict. The
passthrough mode bypass the IOMMU, the lazy mode defer the invalidation
of hardware TLBs, and the strict mode invalidate IOMMU hardware TLBs
synchronously. The three modes are mutually exclusive. So people maybe
confused about
s390_iommu=strict can be replaced with iommu.dma_mode=strict.
Signed-off-by: Zhen Lei
---
Documentation/admin-guide/kernel-parameters.txt | 7 ---
arch/s390/pci/pci_dma.c | 20 +---
drivers/iommu/Kconfig | 1 +
3 files chang
First, add build option IOMMU_DMA_MODE_LAZY, so that we have the
opportunity to set lazy mode as default at build time. Then put the
three config options in an choice, make people can only choose one of the
three at a time, the same to the boot options iommu.dma_mode.
Signed-off-by: Zhen Lei
---
On 12/02/2019 00.31, David Gibson wrote:
> On Mon, 11 Feb 2019 12:37:12 +0100
> Thomas Huth wrote:
>
>> Recent versions of QEMU provide a XHCI device by default these
>> days instead of an old-fashioned OHCI device:
>>
>> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
>>
>>
20 matches
Mail list logo
