On 12/10/2018 18:00, Michael S. Tsirkin wrote:
> This all looks good to me. Minor nits:
> - I think DEBUG mode is best just removed for now
> - Slightly wrong patch splitup causing a misaligned structure
> in uapi until all patches are applied.
Thanks a lot for the review, I'll fix these up and
On 12/10/2018 17:35, Michael S. Tsirkin wrote:
>> +list_del(&req->list);
>> +kfree(req);
>
> So with DEBUG set, this will actually free memory that device still
> DMA's into. Hardly pretty. I think you want to mark device broken,
> queue the request and then wait for device
On Fri, Oct 12, 2018 at 06:17:48PM +0100, James Morse wrote:
> Ripping out the existing #ifdefs and replacing them with IS_ENABLED() would
> let
> the compiler work out the estatus stuff is unused, and saves us describing the
> what-uses-it logic in Kconfig.
>
> But this does expose the x86 nmi s
On Fri, Sep 21, 2018 at 11:17:02PM +0100, James Morse wrote:
> Each struct ghes has an worst-case sized buffer for storing the
> estatus. If an error is being processed by ghes_proc() in process
> context this buffer will be in use. If the error source then triggers
> an NMI-like notification, the
On Fri, Sep 21, 2018 at 11:17:01PM +0100, James Morse wrote:
> ghes_read_estatus() reads the record address, then the record's
> header, then performs some sanity checks before reading the
> records into the provided estatus buffer.
>
> We either need to know the size of the records before we call
Hi Boris,
On 12/10/2018 11:02, Borislav Petkov wrote:
> On Fri, Sep 21, 2018 at 11:16:54PM +0100, James Morse wrote:
>> To split up APEIs in_nmi() path, we need the nmi-like callers to always
>> be in_nmi(). Add a helper to do the work and claim the notification.
>>
>> When KVM or the arch code ta
Hi Boris,
On 12/10/2018 10:57, Borislav Petkov wrote:
> On Fri, Sep 21, 2018 at 11:16:53PM +0100, James Morse wrote:
>> To split up APEIs in_nmi() path, we need any nmi-like callers to always
>> be in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
>> out into a header file.
>>
Hi Boris,
On 04/10/2018 18:34, Borislav Petkov wrote:
> On Wed, Oct 03, 2018 at 06:50:36PM +0100, James Morse wrote:
>> I'm all in favour of letting the compiler work it out, but the existing ghes
>> code has #ifdef/#else all over the place. This is 'keeping the style'.
>
> Yeah, but this "style"
On Fri, Sep 21, 2018 at 11:17:00PM +0100, James Morse wrote:
> ghes_read_estatus() sets a flag in struct ghes if the buffer of
> CPER records needs to be cleared once the records have been
> processed. This global flags value is a problem if a struct ghes
> can be processed concurrently, as happens
On Fri, Oct 12, 2018 at 03:59:10PM +0100, Jean-Philippe Brucker wrote:
> Implement the virtio-iommu driver, following specification v0.8 [1].
> Changes since v2 [2]:
>
> * Patches 2-4 allow virtio-iommu to use the PCI transport, since QEMU
> would like to phase out the MMIO transport. This produ
On Fri, Sep 21, 2018 at 11:16:58PM +0100, James Morse wrote:
> Subsequent patches will split up ghes_read_estatus(), at which
> point passing around the 'silent' flag gets annoying. This is to
> suppress prink() messages, which prior to 42a0bb3f7138 ("printk/nmi:
> generic solution for safe printk
Hi Mikulas,
On 12/10/18 17:20, Mikulas Patocka wrote:
> Hi
>
> I report this crash that happened on ARM64 in the host kernel when running
> a workload in a virtual machine. The crash is not reproducible. Kernel
> 4.18.12, board MacchiatoBin.
>
> The call sequence that leads up to the crash: fi
On Fri, Oct 12, 2018 at 03:59:16PM +0100, Jean-Philippe Brucker wrote:
> When the device offers the probe feature, send a probe request for each
> device managed by the IOMMU. Extract RESV_MEM information. When we
> encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
> This will
Nitpick:
Subject: Re: [PATCH v6 10/18] ACPI / APEI: preparatory split of ghes->estatus
Pls have an active formulation in your Subject and start it with a capital
letter, i.e., something like:
"Split ghes->estatus in preparation for... "
On Fri, Sep 21, 2018 at 11:16:57PM +0100, James Mo
On Fri, Oct 12, 2018 at 03:59:15PM +0100, Jean-Philippe Brucker wrote:
> The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
> requests such as map/unmap over virtio transport without emulating page
> tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
> requests.
>
Rename kvm_arch_dev_ioctl_check_extension() to
kvm_arch_vm_ioctl_check_extension(), because it does
not have any relationship with device.
Renaming this function can make code readable.
Cc: James Morse
Reviewed-by: Suzuki K Poulose
Signed-off-by: Dongjiu Geng
---
I remeber James also mentioned
The commit 539aee0edb9f ("KVM: arm64: Share the parts of
get/set events useful to 32bit") shares the get/set events
helper for arm64 and arm32, but forgot to share the cap
extension code.
User space will check whether KVM supports vcpu events by
checking the KVM_CAP_VCPU_EVENTS extension
Cc: Jame
Rename the kvm_arch_dev_ioctl_check_extension() to
kvm_arch_vm_ioctl_check_extension, because the name
is not readable;
Enable the 32 bit vcpu events support.
Change since v3:
1. Address James's comments to update the patch commit messages
Change since v2:
1. Address Suzuki's comments to update
On 12/10/2018 15:37, Kirill A. Shutemov wrote:
On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow
On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
> On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations. The mremap system call can be really slow if THP is
> > not enabled. The bottlenec
Hi Dongjiu Geng,
On 11/10/2018 20:07, Dongjiu Geng wrote:
> Rename kvm_arch_dev_ioctl_check_extension() to
> kvm_arch_vm_ioctl_check_extension(), because it does
> not have any relationship with device.
>
> Renaming this function can make code readable.
Lots of things in the kernel are misnamed,
Hi James,
> Hi Dongjiu Geng,
>
> On 11/10/2018 20:07, Dongjiu Geng wrote:
> > The commit 539aee0edb9f ("KVM: arm64: Share the parts of get/set
> > events useful to 32bit") shares the get/set events helper for arm64
> > and arm32,
>
> Oops. I evidently didn't test this bit. Looks like I just depe
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio transport without emulating page
tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code transforms calls coming from the IOMMU API into
correspondi
Using the iommu-map binding, endpoints in a given PCI domain can be
managed by different IOMMUs. Some virtual machines may allow a subset of
endpoints to bypass the IOMMU. In some case the IOMMU itself is presented
as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). Currently, when a
PCI root comp
The event queue offers a way for the device to report access faults from
endpoints. It is implemented on virtqueue #1. Whenever the host needs to
signal a fault, it fills one of the buffers offered by the guest and
interrupts it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iomm
When the device offers the probe feature, send a probe request for each
device managed by the IOMMU. Extract RESV_MEM information. When we
encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
This will tell other subsystems that there is no need to map the MSI
doorbell in the virt
Implement the virtio-iommu driver, following specification v0.8 [1].
Changes since v2 [2]:
* Patches 2-4 allow virtio-iommu to use the PCI transport, since QEMU
would like to phase out the MMIO transport. This produces a complex
topology where the programming interface of the IOMMU could appea
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Signed-off-by: Jean-Philippe Brucker
---
drivers/pci/of.c | 7 +++
1 file cha
Some systems implement virtio-iommu as a PCI endpoint. The operating
systems needs to discover the relationship between IOMMU and masters long
before the PCI endpoint gets probed. Add a PCI child node to describe the
virtio-iommu device.
The virtio-pci-iommu is conceptually split between a PCI pro
The nature of a virtio-mmio node is discovered by the virtio driver at
probe time. However the DMA relation between devices must be described
statically. When a virtio-mmio node is a virtio-iommu device, it needs an
"#iommu-cells" property as specified by bindings/iommu/iommu.txt.
Otherwise, the v
This series speeds up mremap(2) syscall by copying page tables at the
PMD level even for non-THP systems. There is concern that the extra
'address' argument that mremap passes to pte_alloc may do something
subtle architecture related in the future, that makes the scheme not
work. Also we find that
On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations. The mremap system call can be really slow if THP is
> >
On Thu, Oct 11, 2018 at 06:37:55PM -0700, Joel Fernandes (Google) wrote:
> diff --git a/arch/m68k/include/asm/mcf_pgalloc.h
> b/arch/m68k/include/asm/mcf_pgalloc.h
> index 12fe700632f4..4399d712f6db 100644
> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h
> @@
On Fri, Oct 12, 2018 at 05:50:46AM -0700, Joel Fernandes wrote:
> On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> > On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > > Android needs to mremap large regions of memory during memory management
> > > rel
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be rea
On Thu, Oct 11, 2018 at 8:21 AM Laszlo Ersek wrote:
>
> On 10/11/18 09:54, Marc Zyngier wrote:
> > Hi Miriam,
> >
> > On Wed, 10 Oct 2018 19:38:47 +0100,
> > Miriam Zimmerman wrote:
> >>
> >> (oops, sorry for lack of plaintext in the first email. must've
> >> forgotten to click the button in my e
On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
This series speeds up mremap(2) syscall by copying page tables at the
PMD level even for non-THP systems. There is concern that the extra
'address' argument that mremap passes to pte_alloc may do something
subtle architecture related in the fu
On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> Android needs to mremap large regions of memory during memory management
> related operations. The mremap system call can be really slow if THP is
> not enabled. The bottleneck is move_page_tables, which is copying each
> pt
On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > @@ -239,7 +287,21 @@ unsigned long move_page_tables(struct vm_area_struct
> > *vma,
> > split_huge_pmd(vma, old_pmd, old_addr);
> >
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slow across a large map. Turning on THP
may not be
Hi Dongjiu Geng,
On 11/10/2018 20:07, Dongjiu Geng wrote:
> The commit 539aee0edb9f ("KVM: arm64: Share the parts of
> get/set events useful to 32bit") shares the get/set events
> helper for arm64 and arm32,
Oops. I evidently didn't test this bit. Looks like I just depended on the symbol
to be d
On Fri, Sep 21, 2018 at 11:16:56PM +0100, James Morse wrote:
> ghes_copy_tofrom_phys() uses a different fixmap slot depending on in_nmi().
> This doesn't work when we have multiple NMI-like notifications, that
> can interrupt each other.
>
> As with the locking, move the chosen fixmap_idx to the n
On Fri, Sep 21, 2018 at 11:16:55PM +0100, James Morse wrote:
> ghes_copy_tofrom_phys() takes different locks depending on in_nmi().
> This doesn't work when we have multiple NMI-like notifications, that
> can interrupt each other.
>
> Now that NOTIFY_SEA is always called as an NMI, move the lock-t
On Fri, Sep 21, 2018 at 11:16:54PM +0100, James Morse wrote:
> To split up APEIs in_nmi() path, we need the nmi-like callers to always
> be in_nmi(). Add a helper to do the work and claim the notification.
>
> When KVM or the arch code takes an exception that might be a RAS
> notification, it asks
On Fri, Sep 21, 2018 at 11:16:53PM +0100, James Morse wrote:
> To split up APEIs in_nmi() path, we need any nmi-like callers to always
> be in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
> out into a header file.
>
> Currently guest synchronous external aborts are claimed a
On Fri, Oct 12, 2018 at 09:56:05AM +0100, Will Deacon wrote:
> On Fri, Oct 12, 2018 at 09:53:54AM +0100, Mark Rutland wrote:
> > On Thu, Oct 11, 2018 at 05:28:14PM +0100, Will Deacon wrote:
> > > On Fri, Oct 05, 2018 at 09:47:38AM +0100, Kristina Martsenko wrote:
> >
> > > > +#define ESR_ELx_EC_PA
On Fri, Oct 12, 2018 at 09:53:54AM +0100, Mark Rutland wrote:
> On Thu, Oct 11, 2018 at 05:28:14PM +0100, Will Deacon wrote:
> > On Fri, Oct 05, 2018 at 09:47:38AM +0100, Kristina Martsenko wrote:
>
> > > +#define ESR_ELx_EC_PAC (0x09)
> >
> > Really minor nit: but shouldn't this be ESR
On Thu, Oct 11, 2018 at 05:28:14PM +0100, Will Deacon wrote:
> On Fri, Oct 05, 2018 at 09:47:38AM +0100, Kristina Martsenko wrote:
> > +#define ESR_ELx_EC_PAC (0x09)
>
> Really minor nit: but shouldn't this be ESR_EL2_EC_PAC, since this trap
> can't occur at EL1 afaict?
It can also b
48 matches
Mail list logo
