LGTM, it's a shame we don't have a more declarative way to express such dependencies.

tyvm!

Hello, can I please get this approved?

Ping? This is an almost trivial change, since it's a straight backport from an upstream commit.

In D20770#450048, @mindal_semihalf.com wrote:

Interestingly enough on arm and powerpc that array is stored as a part of dma map structure, so we might run into that anyway.
Anyway I agree with you that we need to have the same behavior across architectures.

In D20770#450023, @mindal_semihalf.com wrote:

In D20770#449642, @royger wrote:

In D20770#449628, @mindal_semihalf.com wrote:

In D20770#449275, @royger wrote:

In D20770#449259, @mindal_semihalf.com wrote:

In D20770#449256, @royger wrote:

Can you be more specific about the flow that can lead to overwrite the segs array?

Basically if you have a lot of threads doing DMA loads on the same tag concurrently there is a small chance of the segs array being overwritten before it is read in the callback.
It is a rare race, but reproducible.

Hm, I'm not sure I see how that's supposed to happen. busdma_swi already takes a lock (dmat->common.lockfunc) to prevent issuing multiple loads on the same tag, thus there should be no overwriting while the caller callback is using tag->segs?

Well, I'm not sure how dusdma_swi can help us in this case.
If you go through the flow starting at bus_dmamap_load, then going into bounce_bus_dmamap_load_buffer no lock is acquired there.

Right, the lock is only used for the deferred callback.
I think this is fine, but should be done for x86 also at least (that's where arm64 busdma code is coming from). This expected behaviour should also be mentioned on the busdma man page.
I think the general expectation of busdma code is that you serialize loads when using the same tag, but I cannot find an explicit reference to it on the man page, and IMO the locking section is too vague and doesn't explicitly say that you are not supposed to issue concurrent load calls using the same tag.

Ok, so as you said we have two ways to proceed from here:

1. Modify the manual to explicitly require the user to serialize all loads on the same tag.

Do we know if all existing drivers follow that rule?

2. Move the segmets array on all architectures.

I could prepare the patch, but frankly I don't feel competent enough to make such design decision.

In D20770#449628, @mindal_semihalf.com wrote:

In D20770#449275, @royger wrote:

In D20770#449259, @mindal_semihalf.com wrote:

In D20770#449256, @royger wrote:

Can you be more specific about the flow that can lead to overwrite the segs array?

Basically if you have a lot of threads doing DMA loads on the same tag concurrently there is a small chance of the segs array being overwritten before it is read in the callback.
It is a rare race, but reproducible.

Hm, I'm not sure I see how that's supposed to happen. busdma_swi already takes a lock (dmat->common.lockfunc) to prevent issuing multiple loads on the same tag, thus there should be no overwriting while the caller callback is using tag->segs?

Well, I'm not sure how dusdma_swi can help us in this case.
If you go through the flow starting at bus_dmamap_load, then going into bounce_bus_dmamap_load_buffer no lock is acquired there.

In D20770#449259, @mindal_semihalf.com wrote:

In D20770#449256, @royger wrote:

Can you be more specific about the flow that can lead to overwrite the segs array?

Basically if you have a lot of threads doing DMA loads on the same tag concurrently there is a small chance of the segs array being overwritten before it is read in the callback.
It is a rare race, but reproducible.

I'm not sure I understand the motivation behind that change, is this fixing an existing issue with a specific driver?

Fixed in the new version, thanks!

s/FILESDIR/PATCHDIR/

In D20148#433866, @kevans wrote:

I suspect you'll need to bump some g_raid parts as well- it has modules declared at SI_SUB_DRIVERS/SI_ORDER_{FIRST,SECOND,THIRD} that I suspect could/should be bumped to SECOND/THIRD/FOURTH -- but I haven't had time to dig into it and examine the dependencies there.

In D19591#419483, @novel wrote:

Shouldn't this patch be added to EXTRA_PATCHES?

• Use a explicit target to only build man pages, instead of using the generic docs target and expecting only the man pages to be built.
• Remove the markdown dependency, the html files can be easily fetched from https://xenbits.xen.org/docs/.

In D19592#419471, @mat wrote:

What happened to all the html files in DOCSDIR?

In D19521#418756, @mat wrote:

The manpages should not be behind the DOCS option, they should either always be installed, or be behind a MANPAGES option (that defaults to on).

Forgot to ask but can you commit this?

Update to add patches for XSA-{284,287,290,292-294}

LGTM, thanks!

Ping?

Add a couple more of backported fixes that should improve the
user-experience, ie: prevent Xen from crashing or deadlocking.

Thank you very much for reviewing them! No rush to commit.

Remove previous MOVED entry.

Thanks, I'm afraid this is kind of messy however. There was a previous line on the MOVED file from the xen-{kernel/tools} -> xen-{kernel/tools}-47, and now poudriere tells me:

# poudriere testport -o emulators/xen-kernel -j 130-20190207-amd64 -p local -J 16
[00:00:00] Creating the reference jail... done
[00:00:01] Warning: !!! Jail is newer than host. (Jail: 1300010, Host: 1300008) !!!
[00:00:01] Warning: This is not supported.
[00:00:01] Warning: Host kernel must be same or newer than jail.
[00:00:01] Warning: Expect build failures.
[00:00:02] Mounting system devices for 130-20190207-amd64-local
[00:00:02] Mounting ports/packages/distfiles
[00:00:02] Stashing existing package repository
[00:00:02] Mounting packages from: /usr/local/poudriere/data/packages/130-20190207-amd64-local
[00:00:02] Copying /var/db/ports from: /usr/local/etc/poudriere.d/130-20190207-amd64-local-options
/etc/resolv.conf -> /usr/local/poudriere/data/.m/130-20190207-amd64-local/ref/etc/resolv.conf
[00:00:03] Starting jail 130-20190207-amd64-local
[00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:06] MOVED: emulators/xen-kernel moved to emulators/xen-kernel47
[...]

Is this fine?

Fix package suffix

If it's not too much hassle please commit it :)

Apply requested fixes, run igor.

Apply requested fixes, run igor.

Thanks, all fixed :).

Thanks, new version coming.

I plan to get rid of the Xen specific MSI implementation soon.

Thanks, this allows to fix the Xen boot issue. Would you mind including the following diff into your patch?