Page MenuHomeFreeBSD

ehem_freebsd_m5p.com (Elliott Mitchell)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 20 2021, 4:27 AM (41 w, 4 d)

Recent Activity

Sun, Dec 5

ehem_freebsd_m5p.com updated the diff for D30909: xen/intr: introduce xen_arch_intr.c.

Single blank line adjustment, but keeping Phabricator synchronized.

Sun, Dec 5, 11:12 PM

Sat, Dec 4

ehem_freebsd_m5p.com updated the diff for D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.

Tiny update, this line seems appropriate here, but also elsewhere.

Sat, Dec 4, 11:31 PM
ehem_freebsd_m5p.com updated the diff for D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Tiny update, pulling an extra line out of the locked section.

Sat, Dec 4, 11:29 PM

Sun, Nov 28

ehem_freebsd_m5p.com updated the diff for D30598: xen/intr: merge parts of resume functionality into new function.

Updating to ensure consistency with what I've got. Should still apply, but updates on D30743 have made application unclean.

Sun, Nov 28, 3:30 PM
ehem_freebsd_m5p.com added a comment to D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().

Overall this approach seems likely to be simpler in the end. Notably if the approach proposed by D31188/D32866 was brought in, isrc->xi_cpu would always be set and the CPU assignment would be done here in all cases.

Sun, Nov 28, 1:19 AM
ehem_freebsd_m5p.com updated the diff for D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().

Updating due to fallout from D30743 (which I expect to go in first).

Sun, Nov 28, 1:06 AM
ehem_freebsd_m5p.com updated the diff for D32866: xen/inter: merge CPU assignment during port binding together.

Fallout from updates to D30743. The update makes the original patch no longer apply cleanly. Since I expect D30743 to go in first, ensure it works.

Sun, Nov 28, 1:03 AM
ehem_freebsd_m5p.com updated the diff for D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.

As threatened, dropping the preference for isrc->xi_port. Mostly ends up in D30598 anyway.

Sun, Nov 28, 12:58 AM
ehem_freebsd_m5p.com updated the summary of D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.
Sun, Nov 28, 12:50 AM
ehem_freebsd_m5p.com updated the diff for D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Tiny delta, removes one extra line from the lock/unlock in xen_intr_bind_isrc(). (also keeps Phabricator synchronized)

Sun, Nov 28, 12:36 AM

Fri, Nov 26

ehem_freebsd_m5p.com added inline comments to D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.
Fri, Nov 26, 5:36 AM

Thu, Nov 25

ehem_freebsd_m5p.com added a comment to D30909: xen/intr: introduce xen_arch_intr.c.

There have been a bunch of updates to this due to experimentation.

Thu, Nov 25, 7:48 PM
ehem_freebsd_m5p.com added a comment to D30006: xen/intr: adjust xen_intr_handle_upcall() to match interrupt filter.

To summarize the situation in a different way. xen_intr_handle_upcall() had been implemented as the assembly-language entry point (called from apic_vector.S). Both xenpci.c and xen-dt.c were creating wrappers around xen_intr_handle_upcall() in order to call it as a driver_filter_t as a device interrupt.

Thu, Nov 25, 6:58 PM
ehem_freebsd_m5p.com updated the diff for D30006: xen/intr: adjust xen_intr_handle_upcall() to match interrupt filter.

Keeping synchronized. Reduced the one comment. I'm now suspecting modifying td_intr_nesting_level is incorrect, but I need a reviewer for that as I'm insufficiently familiar.

Thu, Nov 25, 6:44 PM
ehem_freebsd_m5p.com retitled D30599: xen/intr: rework xen_intr_resume() for in-place remapping from xen/intr: rework xen_intr_resume() to use port mappings as implicit listing to xen/intr: rework xen_intr_resume() for in-place remapping.
Thu, Nov 25, 6:35 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Upon examination, it was possible to split this into 3 separate commits somewhat reasonably. I'm doubtful the commits are worthy of individual review, so I'm leaving Phabricator alone.

Thu, Nov 25, 6:34 PM
ehem_freebsd_m5p.com updated the summary of D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.
Thu, Nov 25, 6:30 PM

Wed, Nov 24

ehem_freebsd_m5p.com updated the diff for D30909: xen/intr: introduce xen_arch_intr.c.

Keeping things synchronized. Looks like a few stray bits snuck in last time. Need those approvals so I'm not dealing with a huge pile of local commits...

Wed, Nov 24, 5:20 AM

Mon, Nov 22

ehem_freebsd_m5p.com updated the diff for D31062: xen/intr: implement aarch64 variant of xen_arch_intr.c.

Turning a number of the ARM64 compatibility functions into inlines.

Mon, Nov 22, 3:46 PM
ehem_freebsd_m5p.com updated the diff for D30909: xen/intr: introduce xen_arch_intr.c.

Switching to inlines for the paper-thin compatibility layer bits. There is only the tiniest conversion between architecture-independent and architecture-dependent for these.

Mon, Nov 22, 3:45 PM

Sun, Nov 21

ehem_freebsd_m5p.com updated the diff for D32504: kern/intr: remove "irq" from kernel event API.

Updating for MIPS removal.

Sun, Nov 21, 1:56 AM
ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Ensuring Phabricator stays up to date with my tree.

Sun, Nov 21, 1:54 AM

Sat, Nov 20

ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Realizing the last revision ended up with a bug added. Adjust to take care of issue. I still like this approach, but I'm rather lacking feedback...

Sat, Nov 20, 4:34 AM

Fri, Nov 19

ehem_freebsd_m5p.com added inline comments to D30909: xen/intr: introduce xen_arch_intr.c.
Fri, Nov 19, 1:55 AM

Wed, Nov 17

ehem_freebsd_m5p.com updated the diff for D31690: xen/intr: arm64: implement Xen event balancing.

Updating given updates elsewhere. This is the set isrc->xi_cpu approach.

Wed, Nov 17, 4:38 AM

Tue, Nov 16

ehem_freebsd_m5p.com added inline comments to D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().
Tue, Nov 16, 11:09 PM
ehem_freebsd_m5p.com added inline comments to D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().
Tue, Nov 16, 9:58 PM

Sat, Nov 13

ehem_freebsd_m5p.com added inline comments to D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().
Sat, Nov 13, 12:33 AM

Fri, Nov 12

ehem_freebsd_m5p.com added inline comments to D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().
Fri, Nov 12, 4:11 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

D30726 doesn't depend on anything. As originally submitted D31995 wants D30726 first. The big dependency is D30936 depends on D30726.

Fri, Nov 12, 4:11 PM
ehem_freebsd_m5p.com updated the diff for D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().

Sigh, simple goof fix.

Fri, Nov 12, 4:07 PM

Thu, Nov 11

ehem_freebsd_m5p.com updated the diff for D30909: xen/intr: introduce xen_arch_intr.c.

Identifying where the need for <machine/intr_machdep.h> actually disappears.

Thu, Nov 11, 4:03 PM
ehem_freebsd_m5p.com updated the diff for D30936: xen/intr: move interrupt allocation/release to architecture.

Updating to present status. Difficult keeping everything up to date when you've got >60 diffs and ~100 commits in the queue.

Thu, Nov 11, 4:51 AM
ehem_freebsd_m5p.com updated the diff for D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Trying to keep Phabricator synchronized locally. Bit of a problem with the number of patches I'm playing with...

Thu, Nov 11, 4:44 AM
ehem_freebsd_m5p.com updated the diff for D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().

Breaking D30935 apart. Upon examination, this works as an alternative strategy. As I've looked at this, using merely this half has seemed more and more compelling. In fact this approach meshes very well with D32866/D31188.

Thu, Nov 11, 3:48 AM
ehem_freebsd_m5p.com added inline comments to D30936: xen/intr: move interrupt allocation/release to architecture.
Thu, Nov 11, 2:37 AM
ehem_freebsd_m5p.com added inline comments to D31188: xen/intr: switch to passing initial parameters as temporary isrc.
Thu, Nov 11, 2:17 AM
ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Testing revealed unexpect behavior by Clang. Didn't like the _Static_assert() directly after the label. Looks like a Clang bug at first glance. Adding a bit of cleanup while at it.

Thu, Nov 11, 2:10 AM

Wed, Nov 10

ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Minor adjustment. Slightly shorter, but also works better with D30935.

Wed, Nov 10, 11:11 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

I think you've got the gist of it, but the borderline isn't quite where you're placing it and there is a bit more before breaking off.

Wed, Nov 10, 10:11 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Putting another way, there are 4 distinct locking domains:

  1. interrupt_sources[]/x86 interrupts available for reuse
  2. xen_intr_auto_vector_count/newly allocating x86 interrupts
  3. xen_intr_port_to_isrc[]/isrc->xi_port
  4. Acquire/release isrc->xi_refcount
Wed, Nov 10, 5:36 AM
ehem_freebsd_m5p.com added a comment to D31188: xen/intr: switch to passing initial parameters as temporary isrc.

In case comments elsewhere didn't make it obvious, I really like this interface. Yet since it isn't required I continue to keep options open. Getting a decision sooner is highly valuable since this choice effects many follow-on commits substantially.

Wed, Nov 10, 4:17 AM
ehem_freebsd_m5p.com added inline comments to D32866: xen/inter: merge CPU assignment during port binding together.
Wed, Nov 10, 4:15 AM
ehem_freebsd_m5p.com added a comment to D31355: xen/intr: hand off closing of ports sooner.

This appears to potentially benefit from D32876 as it means there is no longer a need to use xen_intr_unbind(). There is even more potential for merging things down, but this needs to be done with care. Alas, this doesn't appear to benefit my main goal.

Wed, Nov 10, 3:55 AM
ehem_freebsd_m5p.com added inline comments to D32866: xen/inter: merge CPU assignment during port binding together.
Wed, Nov 10, 3:50 AM
ehem_freebsd_m5p.com added a comment to D32923: xen/intr: remove xenpci headers.

I'm concerned this may work in my tree due to intermediate commits, but nothing is obvious so I suspect it was something long ago.

Wed, Nov 10, 3:48 AM
ehem_freebsd_m5p.com requested review of D32923: xen/intr: remove xenpci headers.
Wed, Nov 10, 3:44 AM
ehem_freebsd_m5p.com updated the diff for D32876: xen/intr: move handler removal to release from unbind.

Trying to salvage some useful portions of this. I still like having xen_intr_release_isrc() do full cleanup, but clearly I goofed which side xi_cookie was best to remain on.

Wed, Nov 10, 1:23 AM

Tue, Nov 9

ehem_freebsd_m5p.com updated the diff for D30909: xen/intr: introduce xen_arch_intr.c.

Better arrangement of enum evtchn_type. Nothing outside of the interrupt interface needs this, so reducing the visibility is good. I'm still wondering about the xen_arch_intr_remove_handler() interface. Simplest approach to clearing xi_cookie might be D31188, which ensures everything is cleared.

Tue, Nov 9, 3:42 AM

Mon, Nov 8

ehem_freebsd_m5p.com abandoned D32877: xen/intr: allow xen_intr_release_isrc() to reuse lock.

This isn't even the slightest bit of a priority. Worse, this does indeed make locking harrier.

Mon, Nov 8, 10:41 PM
ehem_freebsd_m5p.com updated the diff for D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Adjusting the comment before xen_intr_isrc_lock as per my comment.

Mon, Nov 8, 10:25 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Other issue is the current locking during allocation is really gnarly. Notice how before calling xen_intr_alloc_isrc() the lock must be acquired for access to the x86 allocation variables. Once inside xen_intr_alloc_isrc() after the x86 variables are modified (xen_intr_auto_vector_count is incremented); the lock is released in order to call malloc(); then the lock is reacquired for modifying xen_intr_port_to_isrc[].

You did not explain what is wrong with this pattern. Can something go wrong if the lock is acquired between these sections, or do you just not like it?

I cannot dispute the current implementation functions, but it is really awful. This badly breaks many rules of locking. Whereas the new implementation both acquires and releases xen_intr_x86_lock inside xen_intr_alloc_isrc().

I wish you would quantify at least one way in which it is awful before you call it that.

Mon, Nov 8, 9:59 PM

Nov 8 2021

ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

I doubt there are performance benefits from using two locks, just the resultant implementation will be of substantially lower quality.

Nov 8 2021, 7:50 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

See D30936. The goal is everything being protected by xen_intr_x86_lock is very x86-specific and destined to split away from this file. Whereas the portions which remain protected by xen_intr_isrc_lock are mostly architecture-independent and will remain in this file. Splitting the locks allows them to be static.

Would it be possible to just note that the _arch specific functions require external locking by the callers? (and protect them using the common lock) It might be simpler to just keep a single lock, and I don't think there are any performance benefits or otherwise from using two different locks.

Nov 8 2021, 7:10 PM
ehem_freebsd_m5p.com added inline comments to D30909: xen/intr: introduce xen_arch_intr.c.
Nov 8 2021, 5:07 PM
ehem_freebsd_m5p.com added a comment to D32876: xen/intr: move handler removal to release from unbind.

At the point when I pushed this to Phabricator I was thinking xi_cookie should perhaps move to the architecture-dependent side. Problem is the way to go with this decision is quite unclear and I'm wondering whether to abandon D32876 since the situation is so unclear right now.

Nov 8 2021, 5:02 PM
ehem_freebsd_m5p.com added inline comments to D30909: xen/intr: introduce xen_arch_intr.c.
Nov 8 2021, 4:48 PM
ehem_freebsd_m5p.com added a comment to D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

I'm unsure you actually need to split those apart. Wouldn't Arm also require some kind of locking of the architecture specific bits?

Nov 8 2021, 4:39 PM

Nov 7 2021

ehem_freebsd_m5p.com updated the diff for D30648: xen/intr: move x86 bits into xen_arch_isrc_t structure.

Updating for present tree status. Keeping Phabricator up to date is difficult due to the number of commits needed for this project...

Nov 7 2021, 7:35 PM
ehem_freebsd_m5p.com updated the diff for D30909: xen/intr: introduce xen_arch_intr.c.

Figured out the unpleasant feeling I was having. The cookie is the *handler* cookie. As such the Xen interrupt should really simply be forwarding it to client code. Given this, the cookie belongs to the architecture independent side and the architecture dependent side should simply forward.

Nov 7 2021, 7:28 PM
ehem_freebsd_m5p.com updated the diff for D32877: xen/intr: allow xen_intr_release_isrc() to reuse lock.

Yes, this got into Phabricator before final testing. Indeed, it is broken. The fix is pretty obvious.

Nov 7 2021, 7:07 PM
ehem_freebsd_m5p.com added a comment to D32877: xen/intr: allow xen_intr_release_isrc() to reuse lock.

Kind of a "Hey, look what D32876 allows us to do!"

Nov 7 2021, 4:28 AM
ehem_freebsd_m5p.com requested review of D32877: xen/intr: allow xen_intr_release_isrc() to reuse lock.
Nov 7 2021, 4:25 AM
ehem_freebsd_m5p.com abandoned D32346: sys: add trap frame compatibility macros.

Good news is this did allow identifying places where curthread->tf_intr_frame was obtained from the argument, versus places where it was obtained from curthread. Also places which used driver_filter_t versus duplicating the prototype.

Nov 7 2021, 2:29 AM
ehem_freebsd_m5p.com added a comment to D30648: xen/intr: move x86 bits into xen_arch_isrc_t structure.

Now notable D32876 shows how isrc->xi_cookie can move to isrc->xi_arch.xai_cookie. Just an issue of getting that decision made.

Nov 7 2021, 1:33 AM
ehem_freebsd_m5p.com added a comment to D32876: xen/intr: move handler removal to release from unbind.

This is the latest in the series of slowly getting the architecture-dependent and architecture-independent sides completely separated. If the reviewers (@royger) think this is acceptable, this would allow moving xi_cookie to xai_cookie. Thus the interrupt handler cookie would isolated to the architecture-dependent side.

Nov 7 2021, 1:30 AM
ehem_freebsd_m5p.com requested review of D32876: xen/intr: move handler removal to release from unbind.
Nov 7 2021, 12:50 AM

Nov 6 2021

ehem_freebsd_m5p.com added inline comments to D30598: xen/intr: merge parts of resume functionality into new function.
Nov 6 2021, 1:54 AM
ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Updating to keep synchronized with my local repository. Minimal delta, simply a bit of formatting adjustment.

Nov 6 2021, 1:50 AM
ehem_freebsd_m5p.com added a comment to D32866: xen/inter: merge CPU assignment during port binding together.

Situation of exploring the effects of D31188. I rather like D31188's effect on the interface, but that needs a review before I'm going to start assuming things will head this direction.

Nov 6 2021, 1:40 AM
ehem_freebsd_m5p.com requested review of D32866: xen/inter: merge CPU assignment during port binding together.
Nov 6 2021, 1:10 AM

Nov 5 2021

ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Reverting to previous arrangement. The extra bits didn't seem to go with this delta that well. Trying to grab the full additions would have been too confusing. Do include the reflowing though.

Nov 5 2021, 6:39 PM
ehem_freebsd_m5p.com updated the diff for D31355: xen/intr: hand off closing of ports sooner.

Updating to match D31188 update.

Nov 5 2021, 5:34 AM
ehem_freebsd_m5p.com updated the diff for D31188: xen/intr: switch to passing initial parameters as temporary isrc.

Update due to examining elsewhere and noticing a crucial missing piece. I really do find this approach elegant and I suspect it could simplify things. Do need to choose the approach for the issue.

Nov 5 2021, 5:27 AM
ehem_freebsd_m5p.com updated the diff for D30598: xen/intr: merge parts of resume functionality into new function.

Another small update for the sign auditing.

Nov 5 2021, 5:24 AM

Nov 4 2021

ehem_freebsd_m5p.com updated the diff for D30598: xen/intr: merge parts of resume functionality into new function.

Another signed/unsigned update, sorry.

Nov 4 2021, 2:08 AM
ehem_freebsd_m5p.com updated the diff for D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.

Small tweak I had been pondering. Very minor difference.

Nov 4 2021, 1:15 AM

Nov 3 2021

ehem_freebsd_m5p.com updated the diff for D30599: xen/intr: rework xen_intr_resume() for in-place remapping.

Tiny update for signed/unsigned issue.

Nov 3 2021, 10:42 PM
ehem_freebsd_m5p.com updated the diff for D32789: xen/intr: mark several pieces unsigned.

Finish full checking. The prototype for ffs*() seems *really* bad, it needs to match POSIX, but that is still impressively bad.

Nov 3 2021, 6:54 PM

Nov 2 2021

ehem_freebsd_m5p.com updated the diff for D32796: xen: add SPDX license tags to Xen headers.

Update to match what I have been informed is correct.

Nov 2 2021, 11:18 PM
ehem_freebsd_m5p.com updated the diff for D30996: xen/arm64: add aarch64 hypercall interface.

Update to match comment.

Nov 2 2021, 11:16 PM
ehem_freebsd_m5p.com added a comment to D32796: xen: add SPDX license tags to Xen headers.

Figuring mark these files too in order to avoid future issues like D30996.

Nov 2 2021, 5:58 AM
ehem_freebsd_m5p.com requested review of D32796: xen: add SPDX license tags to Xen headers.
Nov 2 2021, 5:56 AM
ehem_freebsd_m5p.com removed reviewers for D30996: xen/arm64: add aarch64 hypercall interface: emaste, imp.
Nov 2 2021, 5:49 AM
ehem_freebsd_m5p.com updated the diff for D30997: xen/arm64: add sys/arm64/include/xen/synch_bitops.h.

Adjusting several functions to be u_int as that seems more appropriate here (potentially reducing warnings if they get enabled).

Nov 2 2021, 5:43 AM
ehem_freebsd_m5p.com updated the diff for D30996: xen/arm64: add aarch64 hypercall interface.

Adding suggested SPDX tag.

Nov 2 2021, 5:42 AM
ehem_freebsd_m5p.com added a comment to D30996: xen/arm64: add aarch64 hypercall interface.

The Phabricator interface seems to suggest it is possible to remove the Core Team blocking review, but I suspect that is a no-no in cases like this. Due to this could @emaste or @imp give the Core Team okay? Appears the license was approved elsewhere and this isn't GPL (it is a permissive if separated from the Linux kernel).

Nov 2 2021, 3:54 AM
ehem_freebsd_m5p.com added a reviewer for D30996: xen/arm64: add aarch64 hypercall interface: imp.
Nov 2 2021, 3:52 AM
ehem_freebsd_m5p.com added a reviewer for D30996: xen/arm64: add aarch64 hypercall interface: emaste.
Nov 2 2021, 3:47 AM
ehem_freebsd_m5p.com added a comment to D31995: xen/intr: add check for intr_register_source() errors.

I prefer pushing D31995 after D30726. That way the original (approved) form can be used and results in some later deltas being smaller. I don't like leaving mines lying around though.

Nov 2 2021, 2:22 AM
ehem_freebsd_m5p.com added a comment to D32070: sys/x86: make irqs unsigned.

With no guidance, simply do what I suspect was actually desired. Breaking the portion off into a separate diff. So now D32070 is purely making irq variables unsigned, while D32795 is making io_irq unsigned.

Nov 2 2021, 12:51 AM
ehem_freebsd_m5p.com requested review of D32795: x86/io_apic: make io_irq unsigned.
Nov 2 2021, 12:39 AM
ehem_freebsd_m5p.com updated the diff for D32070: sys/x86: make irqs unsigned.

Splitting io_apic portion off into separate diff.

Nov 2 2021, 12:38 AM

Nov 1 2021

ehem_freebsd_m5p.com added a comment to D32793: sys: declare bit sets unsigned.

This needs someone knowledgeable to look and some testing. I imagine most, if not all, uses of bit sets act as if unsigned; if any do not that would be a problem.

Nov 1 2021, 11:17 PM
ehem_freebsd_m5p.com added reviewers for D32793: sys: declare bit sets unsigned: kib, jhb.
Nov 1 2021, 11:09 PM
ehem_freebsd_m5p.com requested review of D32793: sys: declare bit sets unsigned.
Nov 1 2021, 11:07 PM
ehem_freebsd_m5p.com updated the diff for D30935: xen/intr: move interrupt balancing into xen_intr_alloc_isrc().

Broken apart in my local repository. I believe under "Commits" the intermediate point I was thinking of should be visible. This might be a good idea.

Nov 1 2021, 10:53 PM
ehem_freebsd_m5p.com updated the diff for D32789: xen/intr: mark several pieces unsigned.

Trying to clean these out and two more show up.

Nov 1 2021, 10:47 PM
ehem_freebsd_m5p.com added a comment to D31188: xen/intr: switch to passing initial parameters as temporary isrc.

I distinctly like this approach in some ways. Makes the xen_intr_alloc_isrc() prototype simpler and ensures everything potentially needed gets in. This could also simplify a number of error cases as it becomes valid to use xen_intr_release_isrc() for cleanup sooner. Downside I see right now is the temporary struct xenisrc could use a substantial amount of stack.

Nov 1 2021, 9:16 PM
ehem_freebsd_m5p.com added inline comments to D30006: xen/intr: adjust xen_intr_handle_upcall() to match interrupt filter.
Nov 1 2021, 8:51 PM