Page MenuHomeFreeBSD

br (Ruslan Bukin)
User

Projects

User Details

User Since
Nov 27 2014, 10:57 AM (309 w, 21 h)

Recent Activity

Yesterday

br updated the diff for D24618: ARM SMMU v3.2 support.

Set domain.end address (max guest addr + 1) to the VM_MAXUSER_ADDR

Thu, Oct 29, 3:22 PM

Wed, Oct 28

br updated the diff for D26877: SMMU pmap routines added.

Fix comment

Wed, Oct 28, 10:12 AM

Tue, Oct 27

br updated the diff for D24618: ARM SMMU v3.2 support.

Rename iommu_smmu.c to smmu_iommu.c

Tue, Oct 27, 5:28 PM
br updated the diff for D24618: ARM SMMU v3.2 support.

The final patch to review

Tue, Oct 27, 4:42 PM
br committed rS367085: o Add the domain member to the struct bus_dma_tag_common as required by.
o Add the domain member to the struct bus_dma_tag_common as required by
Tue, Oct 27, 3:30 PM
br closed D26904: gicv3_its_release_irqsrc() locking.
Tue, Oct 27, 3:18 PM
br committed rS367084: Take the ITS device lock around gicv3_its_release_irqsrc() since that.
Take the ITS device lock around gicv3_its_release_irqsrc() since that
Tue, Oct 27, 3:18 PM
br updated the diff for D26877: SMMU pmap routines added.

Address markj@ queries

Tue, Oct 27, 3:06 PM
br added inline comments to D26877: SMMU pmap routines added.
Tue, Oct 27, 3:06 PM

Sun, Oct 25

br closed D26878: IOMMU support for GICv3 ITS.
Sun, Oct 25, 10:09 AM
br committed rS367037: Add IOMMU support to GICv3 Interrupt Translation Service (ITS) driver..
Add IOMMU support to GICv3 Interrupt Translation Service (ITS) driver.
Sun, Oct 25, 10:09 AM

Sat, Oct 24

br abandoned D25974: map_msi for IOMMU.
Sat, Oct 24, 8:11 PM
br closed D26906: iommu_unmap_msi() added.
Sat, Oct 24, 8:09 PM
br committed rS367016: o Add iommu de-initialization method for MSI interface..
o Add iommu de-initialization method for MSI interface.
Sat, Oct 24, 8:09 PM
br updated the diff for D26906: iommu_unmap_msi() added.

Add default implementations of iommu_init/deinit

Sat, Oct 24, 11:18 AM

Fri, Oct 23

br updated the diff for D26878: IOMMU support for GICv3 ITS.

gicv3_iommu_deinit() added

Fri, Oct 23, 10:29 PM
br updated the diff for D26906: iommu_unmap_msi() added.

o Check if entry is not NULL, otherwise return early
o Remove gicv3_its.c changes from this diff. They are moved to https://reviews.freebsd.org/D26878

Fri, Oct 23, 10:27 PM
br closed D26887: Add bus_dma_iommu_set_buswide() stubs.
Fri, Oct 23, 9:28 PM
br committed rS366980: Move the iommu stubs to a generic place, so they are available on all the.
Move the iommu stubs to a generic place, so they are available on all the
Fri, Oct 23, 9:28 PM
br updated the diff for D26887: Add bus_dma_iommu_set_buswide() stubs.

Move iommu stubs to subr_bus_dma.c

Fri, Oct 23, 2:35 PM
br added a comment to D26887: Add bus_dma_iommu_set_buswide() stubs.

Would it make sense to move these to subr_bus_dma.c in the non-IOMMU case?

Fri, Oct 23, 8:37 AM

Thu, Oct 22

br requested review of D26906: iommu_unmap_msi() added.
Thu, Oct 22, 5:04 PM
br requested review of D26904: gicv3_its_release_irqsrc() locking.
Thu, Oct 22, 4:20 PM
br added inline comments to D26877: SMMU pmap routines added.
Thu, Oct 22, 3:45 PM
br updated the diff for D26877: SMMU pmap routines added.

o Rename pmap_sremove_all() to pmap_sremove_pages()
o Remove unneeded check for L2_BLOCK in pmap_sremove_pages()

Thu, Oct 22, 3:40 PM

Wed, Oct 21

br requested review of D26887: Add bus_dma_iommu_set_buswide() stubs.
Wed, Oct 21, 11:37 AM

Tue, Oct 20

br added inline comments to D26878: IOMMU support for GICv3 ITS.
Tue, Oct 20, 11:15 AM
br requested review of D26878: IOMMU support for GICv3 ITS.
Tue, Oct 20, 9:55 AM
br requested review of D26877: SMMU pmap routines added.
Tue, Oct 20, 9:52 AM

Mon, Oct 19

br committed rS366865: Fix build: only set iommu buswide flag if IOMMU code is included..
Fix build: only set iommu buswide flag if IOMMU code is included.
Mon, Oct 19, 10:32 PM
br closed D26857: IOMMU quirks added.
Mon, Oct 19, 9:27 PM
br committed rS366863: Add IOMMU_BUSWIDE ahci quirk..
Add IOMMU_BUSWIDE ahci quirk.
Mon, Oct 19, 9:27 PM
br updated the diff for D26857: IOMMU quirks added.

Add IOMMU quirks for all the devices listed in linux

Mon, Oct 19, 7:03 PM
br updated the diff for D26857: IOMMU quirks added.

Update AHCI quirk bitstring

Mon, Oct 19, 3:59 PM
br closed D26859: Assign MSI entry to x86.
Mon, Oct 19, 3:51 PM
br committed rS366835: Assign the reserved apic region (GAS entry) to the iommu domain msi_entry..
Assign the reserved apic region (GAS entry) to the iommu domain msi_entry.
Mon, Oct 19, 3:51 PM
br updated the diff for D26857: IOMMU quirks added.

Move the quirk to ahci driver

Mon, Oct 19, 3:27 PM
br requested review of D26859: Assign MSI entry to x86.
Mon, Oct 19, 2:08 PM
br requested review of D26857: IOMMU quirks added.
Mon, Oct 19, 1:35 PM
br closed D26705: Manage MSI iommu pages.
Mon, Oct 19, 1:10 PM
br committed rS366833: Manage MSI iommu pages..
Manage MSI iommu pages.
Mon, Oct 19, 1:10 PM
br added inline comments to D26705: Manage MSI iommu pages.
Mon, Oct 19, 1:09 PM
br added inline comments to D26705: Manage MSI iommu pages.
Mon, Oct 19, 10:22 AM
br updated the diff for D26705: Manage MSI iommu pages.

o Add a KASSERT
o Mark MSI fields in the iommu_domain as arch-specific

Mon, Oct 19, 10:20 AM

Sun, Oct 18

br updated the diff for D26705: Manage MSI iommu pages.

Regenerate

Sun, Oct 18, 8:42 PM
br updated the diff for D26705: Manage MSI iommu pages.

o Move iommu_get_ctx_domain(), iommu_get_dev_ctx() to iommu.h

Sun, Oct 18, 8:40 PM
br added a comment to D26705: Manage MSI iommu pages.
In D26705#598296, @kib wrote:

I am curious. There is no arch restriction on the value of MSI base address ? System can map MSI page anywhere, and just programming the correct address into MSI address register would make it work ?

This is very non-x86ish.

Sun, Oct 18, 8:39 PM
br updated the diff for D26705: Manage MSI iommu pages.

o Put Andrew's copyright
o Remove ifdef IOMMU

Sun, Oct 18, 8:29 PM

Fri, Oct 16

br accepted D26813: Add an entry to RELNOTES about renaming ACPI_DMAR to IOMMU.

We could also note that the amd64's IOMMU subsystem was splitted-out from amd64 DMAR support and is now generic, i.e. could be used by all architectures

Fri, Oct 16, 10:06 AM

Thu, Oct 15

br added inline comments to D26705: Manage MSI iommu pages.
Thu, Oct 15, 4:01 PM
br updated the diff for D26705: Manage MSI iommu pages.

Regenerate

Thu, Oct 15, 2:08 PM
br committed rS366724: Split-out Guest Address Space (GAS) macroses to a separate header..
Split-out Guest Address Space (GAS) macroses to a separate header.
Thu, Oct 15, 1:48 PM

Wed, Oct 14

br updated the diff for D26705: Manage MSI iommu pages.

Address kibs's notes

Wed, Oct 14, 9:53 PM
br closed D26780: Add iommu_types.h.
Wed, Oct 14, 9:22 PM
br committed rS366710: Split-out iommu type definitions to a separate header..
Split-out iommu type definitions to a separate header.
Wed, Oct 14, 9:22 PM
br closed D26722: Add a per-arch macro for unload sleep.
Wed, Oct 14, 2:51 PM
br committed rS366704: Add a per-each macro IOMMU_DOMAIN_UNLOAD_SLEEP which allows to sleep.
Add a per-each macro IOMMU_DOMAIN_UNLOAD_SLEEP which allows to sleep
Wed, Oct 14, 2:51 PM
br requested review of D26780: Add iommu_types.h.
Wed, Oct 14, 2:16 PM
br committed rS366702: Add iommu_get_ctx_domain() that allows to get iommu domain for a given.
Add iommu_get_ctx_domain() that allows to get iommu domain for a given
Wed, Oct 14, 2:12 PM
br committed rS366701: Rename a header protection macro..
Rename a header protection macro.
Wed, Oct 14, 1:39 PM

Tue, Oct 13

br updated the diff for D26705: Manage MSI iommu pages.

Address kib's notes:

  • add iommu_types.h
  • add md macro IOMMU_UNLOAD_SLEEP
Tue, Oct 13, 1:14 PM

Fri, Oct 9

br requested review of D26722: Add a per-arch macro for unload sleep.
Fri, Oct 9, 2:08 PM
br committed rS366571: Add iommu_get_dev_ctx() helper that allows to instantiate an iommu context.
Add iommu_get_dev_ctx() helper that allows to instantiate an iommu context
Fri, Oct 9, 1:11 PM

Thu, Oct 8

br updated the diff for D26705: Manage MSI iommu pages.

context added

Thu, Oct 8, 3:19 PM
br added a comment to D26705: Manage MSI iommu pages.
In D26705#595414, @br wrote:
In D26705#595261, @kib wrote:

So would adding a header iommu_msi.h with just msi-related prototypes enough ? I suspect that x86/msi.c can also get rid of iommu.h then.

I will try and see if it works

Thu, Oct 8, 2:54 PM
br updated the diff for D26705: Manage MSI iommu pages.

Manage MSI iommu pages

Thu, Oct 8, 2:53 PM
br added a comment to D26705: Manage MSI iommu pages.
In D26705#595261, @kib wrote:

So would adding a header iommu_msi.h with just msi-related prototypes enough ? I suspect that x86/msi.c can also get rid of iommu.h then.

Thu, Oct 8, 11:54 AM

Wed, Oct 7

br added a comment to D26705: Manage MSI iommu pages.
In D26705#595130, @kib wrote:

Convention for var.h is not suitable for your case IMO. We have signal.h and signalvar.h, where signal.h is usable by userspace and signalvar.h is for kernel private stuff.

Can you provide some enumeration of stuff you want to keep in iommu.h, and an explanation of why ?

Wed, Oct 7, 7:34 PM
br updated the diff for D24618: ARM SMMU v3.2 support.

a change by andrew@:

Wed, Oct 7, 3:31 PM
br requested review of D26705: Manage MSI iommu pages.
Wed, Oct 7, 2:18 PM

Thu, Oct 1

br accepted D26621: riscv: Handle access faults in user mode.
Thu, Oct 1, 1:42 PM

Wed, Sep 30

br added a comment to D24618: ARM SMMU v3.2 support.
In D24618#583893, @mmel wrote:

I’m slightly confused by code partitioning.
With that in mind that we have multiple types of IOMMUs (rockchip, tegra, smmu v2, allwinner …, and one SoC can have multiple different IOMMUs, I’m not sure how this patch fit in this situation.
Is iommu.c intended as base for future IOMMU independent part of framework? If yes, why it contain functions prefixed by smmu_? If not, why it’s named by generic name?
Do you have any roadmap, ideas how final (supporting multiple kinds of IOMMUs in one generic kernel) should be structured?

Wed, Sep 30, 2:13 PM
br updated the diff for D24618: ARM SMMU v3.2 support.

Regenerate

Wed, Sep 30, 2:01 PM

Sep 29 2020

br committed rS366267: Rename kernel option ACPI_DMAR to IOMMU..
Rename kernel option ACPI_DMAR to IOMMU.
Sep 29 2020, 8:29 PM
br closed D26587: Rename ACPI_DMAR.
Sep 29 2020, 8:29 PM
br requested review of D26587: Rename ACPI_DMAR.
Sep 29 2020, 4:15 PM
br committed rS366257: o Rename acpi_iommu_get_dma_tag() -> iommu_get_dma_tag()..
o Rename acpi_iommu_get_dma_tag() -> iommu_get_dma_tag().
Sep 29 2020, 3:11 PM
br closed D26584: Rename acpi_iommu_get_dma_tag().
Sep 29 2020, 3:11 PM
br updated the diff for D26584: Rename acpi_iommu_get_dma_tag().

Don't repeat iommu_get_dma_tag() declaration, include iommu.h instead.

Sep 29 2020, 2:48 PM
br requested review of D26584: Rename acpi_iommu_get_dma_tag().
Sep 29 2020, 10:18 AM

Sep 24 2020

br abandoned D26360: PCI function address aliasing support.

Thanks kib@: buswide quirk works, I have updated the main diff:
https://reviews.freebsd.org/D24618

Sep 24 2020, 2:01 PM
br updated the diff for D24618: ARM SMMU v3.2 support.

Regenerate

Sep 24 2020, 2:00 PM
br updated the diff for D24618: ARM SMMU v3.2 support.

Add quirk: iommu set to buswide for Marvell AHCI

Sep 24 2020, 1:53 PM

Sep 21 2020

br added a comment to D26360: PCI function address aliasing support.
In D26360#589183, @kib wrote:

Yes, I was aware of some AHCI controllers mis-handling RIDs. It is the duty of the driver to ensure that proper domain is created which includes all relevant contexts (not that we have an KPI for this right now).

But wait, why cannot you use iommu_set_buswide_ctx() there ?

Sep 21 2020, 10:34 AM

Sep 18 2020

br added a comment to D26360: PCI function address aliasing support.

Also here are Linux quirks for Marvell:
https://elixir.bootlin.com/linux/latest/source/drivers/pci/quirks.c#L4026

Sep 18 2020, 3:57 PM
br added a comment to D26360: PCI function address aliasing support.
In D26360#588838, @kib wrote:
In D26360#588657, @br wrote:
In D26360#588498, @kib wrote:
In D26360#587442, @br wrote:
In D26360#587123, @kib wrote:

Well, this is not the right approach. I am guilty of the buswide_ctx() of course, but this one goes much further.

Proper solution is to finish my patch to support DMAR (IOMMU ?) domains, where single domain with its page table serves some number of contexts. Then multi-function devices that must share translations should be put into common domain instead of creating per-function domains.

We don't create a per-function domain. This is just to setup a Stream Table Entry (STE) alias in the 2-level walk table.
Marvel SATA issues non-dma requests from SID 0x600, and DMA from 0x601. So SMMU simply could not find a valid STE in the position of 0x601 in the 2-level walk table.
The solution is just to copy the same STE to a required position in the walk table and everything works (this is what Linux does as well).

In essence, you just reworded what I wrote.

Let me be more explicit: I believe such cases should be handled by creating domains which contain more than one context.

Do you mean that each function alias should be in a separate iommu context?

There are no aliases in PCIe spec or DMAR. Yes, DMAR spec makes 1:1 correspondence between context and RID. Domain can group several contexts that share page tables, making all RIDs from domain using identical translations. I believe AMD IOMMU is same.

Sep 18 2020, 11:33 AM

Sep 17 2020

br added a comment to D26360: PCI function address aliasing support.
In D26360#588498, @kib wrote:
In D26360#587442, @br wrote:
In D26360#587123, @kib wrote:

Well, this is not the right approach. I am guilty of the buswide_ctx() of course, but this one goes much further.

Proper solution is to finish my patch to support DMAR (IOMMU ?) domains, where single domain with its page table serves some number of contexts. Then multi-function devices that must share translations should be put into common domain instead of creating per-function domains.

We don't create a per-function domain. This is just to setup a Stream Table Entry (STE) alias in the 2-level walk table.
Marvel SATA issues non-dma requests from SID 0x600, and DMA from 0x601. So SMMU simply could not find a valid STE in the position of 0x601 in the 2-level walk table.
The solution is just to copy the same STE to a required position in the walk table and everything works (this is what Linux does as well).

In essence, you just reworded what I wrote.

Let me be more explicit: I believe such cases should be handled by creating domains which contain more than one context.

Sep 17 2020, 11:06 AM

Sep 12 2020

br added a comment to D26360: PCI function address aliasing support.
In D26360#587123, @kib wrote:

Well, this is not the right approach. I am guilty of the buswide_ctx() of course, but this one goes much further.

Proper solution is to finish my patch to support DMAR (IOMMU ?) domains, where single domain with its page table serves some number of contexts. Then multi-function devices that must share translations should be put into common domain instead of creating per-function domains.

Sep 12 2020, 4:21 PM

Sep 10 2020

br added a reviewer for D26360: PCI function address aliasing support: kib.
Sep 10 2020, 4:37 PM
br added a comment to D26360: PCI function address aliasing support.

Why is it in the pci code rather then iommu? I could imagine broken non-pci devices could also need a DMA alias.

Sep 10 2020, 4:24 PM
br committed rS365577: Move the rid variable to the generic iommu context..
Move the rid variable to the generic iommu context.
Sep 10 2020, 2:12 PM
br closed D26373: Move PCI rid.
Sep 10 2020, 2:12 PM

Sep 9 2020

br requested review of D26373: Move PCI rid.
Sep 9 2020, 2:06 PM

Sep 8 2020

br requested review of D26360: PCI function address aliasing support.
Sep 8 2020, 3:38 PM

Sep 4 2020

br accepted D26327: Maintain a stack alignment of 16-bytes..
Sep 4 2020, 8:20 PM

Aug 15 2020

br added inline comments to D26072: Add support for PMU on SMP systems for ARM64.
Aug 15 2020, 9:34 AM

Aug 11 2020

br updated the diff for D24618: ARM SMMU v3.2 support.

Regenerate

Aug 11 2020, 12:48 PM
br updated the diff for D25974: map_msi for IOMMU.

Check the return value of smmu_map_msi()

Aug 11 2020, 12:42 PM

Aug 7 2020

br abandoned D25094: Split-out DMAR busdma backend.
Aug 7 2020, 10:15 PM

Aug 6 2020

br updated the summary of D25974: map_msi for IOMMU.
Aug 6 2020, 5:10 PM