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 (16 w, 4 d)

Recent Activity

Sat, Jun 12

ehem_freebsd_m5p.com added a comment to D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.

...and testing failed, ugh. I stick to my point the event channel numbering in xen_intr.c seems a bit mixed. I'm not entirely sure of the best course for this.

Sat, Jun 12, 6:16 AM
ehem_freebsd_m5p.com added a comment to D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.

Initial verification passed, final verification is in-progress (previous build failed, but the failure suggested a problem elsewhere and this was fine).

Sat, Jun 12, 1:00 AM

Fri, Jun 11

ehem_freebsd_m5p.com requested review of D30743: xen/intr: rework handling of event channel numbers in xen_intr.c.
Fri, Jun 11, 11:28 PM
ehem_freebsd_m5p.com updated the diff for D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.

Add more to comment before xen_intr_isrc_lock. Give explicit condition for unlocking.

Fri, Jun 11, 11:15 PM
ehem_freebsd_m5p.com updated the diff for D30725: xen/intr: protect xen_intr_port_to_isrc[] during resume.

Adding not to commit message about not actually being required.

Fri, Jun 11, 11:11 PM
ehem_freebsd_m5p.com added a comment to D30280: kern/rman: fix overflow in rman_reserve_resource_bound().

I'm actually tempted to suggest adding:

if (RMAN_IS_DEFAULT_RANGE(start, end))
        panic("resource manager initialized with illegal range");

to rman_manage_region(). Too many architectures initialize their address and interrupt rmans to that range, which means they aren't performing a useful function.

Fri, Jun 11, 8:53 PM
ehem_freebsd_m5p.com added a comment to D29304: xen/xenpv: remove low memory limit for non-x86.

One note, seems the issue I was running into was elsewhere. The value of 0 works fine with that issue addressed.

Fri, Jun 11, 8:33 PM
ehem_freebsd_m5p.com added a comment to D30724: xen/intr: partially revert "xen: fix IPI setup with EARLY_AP_STARTUP".

This needs checking, I'm mostly testing on ARM. I think what this does shouldn't recreate the breakage ca7af67ac958d3749ebfc4771cecf0cd7525e6a0 was trying to fix, but I'm not 100% certain.

Fri, Jun 11, 8:28 PM
ehem_freebsd_m5p.com added a comment to D30725: xen/intr: protect xen_intr_port_to_isrc[] during resume.

True enough, I'll add that to the commit message.

Fri, Jun 11, 8:13 PM
ehem_freebsd_m5p.com requested review of D30726: xen/intr: rework locking, prepare xen_intr_alloc_isrc() for split.
Fri, Jun 11, 2:56 PM
ehem_freebsd_m5p.com requested review of D30725: xen/intr: protect xen_intr_port_to_isrc[] during resume.
Fri, Jun 11, 2:55 PM
ehem_freebsd_m5p.com added a reverting change for R10:ca7af67ac958: xen: fix IPI setup with EARLY_AP_STARTUP: D30724: xen/intr: partially revert "xen: fix IPI setup with EARLY_AP_STARTUP".
Fri, Jun 11, 2:54 PM
ehem_freebsd_m5p.com requested review of D30724: xen/intr: partially revert "xen: fix IPI setup with EARLY_AP_STARTUP".
Fri, Jun 11, 2:53 PM

Sun, Jun 6

ehem_freebsd_m5p.com updated the diff for D30599: xen/intr: rework xen_intr_resume() to use port mappings as implicit listing.

Add a safety check. Protect against left-behind entries in xen_intr_port_to_isrc[] (shouldn't happen, but just in case).

Sun, Jun 6, 1:48 AM

Fri, Jun 4

ehem_freebsd_m5p.com requested review of D30648: xen/intr: move x86 bits into xen_arch_isrc_t structure.
Fri, Jun 4, 9:29 PM
ehem_freebsd_m5p.com updated the diff for D30634: kern/intr: implement isrc_release_counters().

Careful review and looks like atomic_store_rel_int() is needed inside isrc_release_counters(). Otherwise stores could move after and that would break. The accesses in isrc_setup_counters() all depend upon "index" which is synchronized.

Fri, Jun 4, 3:38 PM
ehem_freebsd_m5p.com added a comment to D29310: kern/intr: switch to allocating handles forward.

Any comments on what is currently present?

Fri, Jun 4, 1:35 AM
ehem_freebsd_m5p.com added a comment to D30554: ofwbus: remove handling of resources from ofwbus.

@mhorne, you got it exactly right. Issue is ofwbus is keeping everything to itself, which is fine if *everything* goes through ofwbus, but a major problem for anything independent of ofwbus (such as Xen PV).

Fri, Jun 4, 1:29 AM
ehem_freebsd_m5p.com added a comment to D30634: kern/intr: implement isrc_release_counters().

Theory is to make intr_isrc_deregister() work in the general case. Without this (or a fixed version) isrc_release_counters() is of course a wrapper around panic(). What needs checking is I'm unsure of how the atomic_*() functions are supposed to work, I think I got their use right, but please check. Actual hardware removable interrupt sources aren't common, but software removable ones are quite common (VMs).

Fri, Jun 4, 1:00 AM

Thu, Jun 3

ehem_freebsd_m5p.com requested review of D30634: kern/intr: implement isrc_release_counters().
Thu, Jun 3, 11:29 PM

Wed, Jun 2

ehem_freebsd_m5p.com updated the diff for D30605: xen/intr: remove xen_intr_alloc_and_bind_ipi() from !x86.

Moving the declaration removal to D30605. Though this does really make D30605 and D29913 rather small. Used to be larger until the PVHv1 removal.

Wed, Jun 2, 2:44 AM
ehem_freebsd_m5p.com retitled D29913: xen/intr: move x86-only variable out of common from xen/intr: move x86-only bits out of common to xen/intr: move x86-only variable out of common.
Wed, Jun 2, 2:41 AM
ehem_freebsd_m5p.com updated the diff for D29913: xen/intr: move x86-only variable out of common.

Rebalancing between D29913 and D30605; D29913 should really only be the variable move.

Wed, Jun 2, 2:40 AM

Tue, Jun 1

ehem_freebsd_m5p.com added a comment to D30605: xen/intr: remove xen_intr_alloc_and_bind_ipi() from !x86.

Appears xen_intr_alloc_and_bind_ipi() was originally pulled to make getting things working easier. Appears it does in fact build on other architectures, but it isn't needed elsewhere. One can argue for or against pulling it on other architectures.

Tue, Jun 1, 6:55 PM
ehem_freebsd_m5p.com requested review of D30605: xen/intr: remove xen_intr_alloc_and_bind_ipi() from !x86.
Tue, Jun 1, 6:53 PM
ehem_freebsd_m5p.com added a comment to D30600: xen/intr: disable xen_intr_suspend() and xen_intr_resume() on !x86.

Get the ordering right. This really needs D30236 to make sense; I've got it after D30599 in my tree, but there isn't any actual ordering issue with D30599.

Tue, Jun 1, 4:33 PM
ehem_freebsd_m5p.com added a comment to D30599: xen/intr: rework xen_intr_resume() to use port mappings as implicit listing.

Actually, one question for the FreeBSD/Xen maintainer: Is the order of the xen_intr_port_to_isrc[cur->xi_port] = cur; and evtchn_unmask_port(cur->xi_port); lines important?

Tue, Jun 1, 4:18 PM
ehem_freebsd_m5p.com added a comment to D30600: xen/intr: disable xen_intr_suspend() and xen_intr_resume() on !x86.

I'm now unsure of this. Originally this had been disabling x86-only functionality on other architectures, but the D30598 and D30599 make the current form of these functions build on other architectures. As such there is no longer an urgent need to disable them on other architectures, but they simply don't accomplish anything on non-x86.

Tue, Jun 1, 3:57 PM
ehem_freebsd_m5p.com added a comment to D30599: xen/intr: rework xen_intr_resume() to use port mappings as implicit listing.

This is the main goal of D30598/D30599. The variables xen_intr_auto_vector_count and first_evtchn_irq are x86-specific. The call intr_lookup_source() is also x86-specific which is being utilized to get access to interrupt_sources and use that as a table of allocated event channel interrupts. These two make it so xen_intr_port_to_isrc is used for this purpose instead.

Tue, Jun 1, 3:55 PM
ehem_freebsd_m5p.com requested review of D30600: xen/intr: disable xen_intr_suspend() and xen_intr_resume() on !x86.
Tue, Jun 1, 3:45 PM
ehem_freebsd_m5p.com requested review of D30599: xen/intr: rework xen_intr_resume() to use port mappings as implicit listing.
Tue, Jun 1, 3:44 PM
ehem_freebsd_m5p.com requested review of D30598: xen/intr: merge parts of resume functionality into new function.
Tue, Jun 1, 3:43 PM
ehem_freebsd_m5p.com updated the summary of D29913: xen/intr: move x86-only variable out of common.
Tue, Jun 1, 3:42 PM

Mon, May 31

ehem_freebsd_m5p.com planned changes to D29875: xen/arm64: add handling of Xen device-tree.

The update had been aimed at keeping what was in Phabricator up to date. Unfortunately I still don't think this is quite ready and should still be in the "changed planned" state.

Mon, May 31, 3:17 AM
ehem_freebsd_m5p.com updated the summary of D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.
Mon, May 31, 3:11 AM
ehem_freebsd_m5p.com retitled D29310: kern/intr: switch to allocating handles forward from kern/intr: restart interrupt allocations after free to kern/intr: switch to allocating handles forward.
Mon, May 31, 3:02 AM
ehem_freebsd_m5p.com updated the summary of D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.
Mon, May 31, 2:18 AM
ehem_freebsd_m5p.com updated the diff for D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.

Addressing @royger's comment. The removal of the lapic_eoi() call had been in a distinct commit, but it does make sense to move here.

Mon, May 31, 2:11 AM

Sun, May 30

ehem_freebsd_m5p.com added a comment to D30554: ofwbus: remove handling of resources from ofwbus.

This is a very early tentative proposal. The issue is without this resource allocations which get to the nexus may be given ranges overlapping with what the OpenFirmware code has. Two drivers trying to use the same physical address range will be Bad(tm).

Sun, May 30, 5:15 PM
ehem_freebsd_m5p.com updated subscribers of D30554: ofwbus: remove handling of resources from ofwbus.
Sun, May 30, 5:01 PM
ehem_freebsd_m5p.com requested review of D30554: ofwbus: remove handling of resources from ofwbus.
Sun, May 30, 5:01 PM
ehem_freebsd_m5p.com added a comment to D30553: arm64/nexus: limit to 2^16 interrupts.

Based on how rm_end = ~0 breaks the resource manager code, using that as the maximum is wrong. I'm unsure of what upper limit should be used, but 2^16 seems reasonable as the maximum interrupt number for the nexus. Perhaps 2^20 to leave a bit more headroom between the maximum allowed by a GICv3 and what some perverse system designer might actually make use of?

Sun, May 30, 4:54 PM
ehem_freebsd_m5p.com requested review of D30553: arm64/nexus: limit to 2^16 interrupts.
Sun, May 30, 4:48 PM
ehem_freebsd_m5p.com requested review of D29304: xen/xenpv: remove low memory limit for non-x86.

Now to get this out of "Changes Planned" since changes elsewhere reduce the concerns I had for a bit with this (accept my own change? @imp had already marked acceptable).

Sun, May 30, 4:47 PM

Sat, May 29

ehem_freebsd_m5p.com updated the diff for D29913: xen/intr: move x86-only variable out of common.

Needed to update the commit message too. That also shrinks due to removals.

Sat, May 29, 5:42 PM

Mon, May 24

ehem_freebsd_m5p.com updated the diff for D29913: xen/intr: move x86-only variable out of common.

Update due to PVHv1 removal. Quite the chunk of xen_intr_x86.h disappeared
due to the removal of PVHv1. I now wonder if the declaration of
xen_intr_alloc_and_bind_ipi() should be moved to x86/xen-os.h, this might
make other pieces cleaner.

Mon, May 24, 5:26 AM

Sun, May 23

ehem_freebsd_m5p.com updated the diff for D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.

Update due to removal of PVHv1, much of the commit is gone, but some
valuable portions remain. xen_handle_shared_info() is still there, the
architecture-independent variables are still here.

Sun, May 23, 10:47 PM

Thu, May 20

ehem_freebsd_m5p.com added a comment to D30297: arm64/nexus: use actual PA range for I/O memory limit.

(one remaining issue is whether I've added the functions in the right place, I'm unsure if perhaps they should be more towards top/bottom of cpu.h and machdep.c)

Thu, May 20, 9:55 PM
ehem_freebsd_m5p.com added a comment to D30297: arm64/nexus: use actual PA range for I/O memory limit.

Comparing with line 52 of sys/x86/acpica/srat.c, it appears acpi_pxm_init() should be getting the maximum valid address as the second argument. This means D26144 was off-by-one. Since the need for the aarch64 nexus is the same value, have the function providing that be the global one. Since I foresee someone wanting the number of address bits or the total count of addresses, leave get_physaddr_bits() and get_physaddr_count() behind with the potential to be made global.

Thu, May 20, 8:06 PM
ehem_freebsd_m5p.com updated the summary of D30297: arm64/nexus: use actual PA range for I/O memory limit.
Thu, May 20, 8:02 PM
ehem_freebsd_m5p.com updated the diff for D30297: arm64/nexus: use actual PA range for I/O memory limit.

Getting things closer to a ready version. Now a common function, the
two (?) off-by-ones are fixed.

Thu, May 20, 8:00 PM

May 17 2021

ehem_freebsd_m5p.com added a comment to D30297: arm64/nexus: use actual PA range for I/O memory limit.

Yes, in nexus_attach() it would need to be nexus_get_parange() - 1. This happens when you're not really sure what should be done.

May 17 2021, 4:41 AM

May 16 2021

ehem_freebsd_m5p.com added a comment to D30297: arm64/nexus: use actual PA range for I/O memory limit.

This part is simply the observation, why the heck will bus_alloc_resource(..., SYS_RES_MEMORY, 0, ~0, $large_size,) happily return address ranges (and sizes) which cannot possibly be valid (architecture doesn't allow for processors which have 64 address lines). This simply limits the potential ranges to potentially valid physical addresses.

May 16 2021, 7:28 PM
ehem_freebsd_m5p.com added a comment to D30297: arm64/nexus: use actual PA range for I/O memory limit.

This is being proposed due to problems being run into when trying to get Xen operational. This is very much preliminary.

May 16 2021, 7:14 PM
ehem_freebsd_m5p.com added a reviewer for D30297: arm64/nexus: use actual PA range for I/O memory limit: arm64.
May 16 2021, 7:13 PM
ehem_freebsd_m5p.com requested review of D30297: arm64/nexus: use actual PA range for I/O memory limit.
May 16 2021, 7:12 PM
ehem_freebsd_m5p.com added a comment to D29304: xen/xenpv: remove low memory limit for non-x86.

Looking at sys/arm64/arm64/nexus.c I see rather major issues and I'm inclined to think the merits of the approach used for x86 is right whereas what is present for aarch64 is wrong.

May 16 2021, 3:41 AM
ehem_freebsd_m5p.com added a comment to D30280: kern/rman: fix overflow in rman_reserve_resource_bound().

There is actually a trade-off between two issues here. Is it valuable for rman_reserve_resource_bound() to handle the case of being given a count of 0? Is it valuable for rman_reserve_resource_bound() to handle the situation of count == 0? Both are a bit funky and a bit valuable to handle.

May 16 2021, 3:09 AM

May 15 2021

ehem_freebsd_m5p.com requested review of D30280: kern/rman: fix overflow in rman_reserve_resource_bound().
May 15 2021, 7:38 PM
ehem_freebsd_m5p.com planned changes to D29818: xen/xenpv: introduce xen_arch_alloc_addr()/xen_arch_release_addr().

There are questions of approach for this. While this has demonstrated viability, there are sufficient concerns for this not to be ready yet. The alternative is D29304 which has a distinct issue.

May 15 2021, 2:27 AM
ehem_freebsd_m5p.com planned changes to D29304: xen/xenpv: remove low memory limit for non-x86.

The change planned this isn't ready for commit until it passes tests. I'm pretty sure the problem is elsewhere, but until that is resolved this isn't ready.

May 15 2021, 2:26 AM
ehem_freebsd_m5p.com accepted D30228: x86/xen: remove PVHv1 code.

This causes a whole bunch of #if defined(__amd64__) || defined(__i386__)/#endif pairs to disappear from unsubmitted commits. For my attempts at getting FreeBSD/ARM operational on Xen/ARM this is a noticeable improvement.

May 15 2021, 2:05 AM
ehem_freebsd_m5p.com reclaimed D29304: xen/xenpv: remove low memory limit for non-x86.

This approach to the problem is still potentially viable and still qualifies as an alternative to D29818. Problem is there is some sort of bug causing this not to work and this needs diagnosis before being committed. I suspect D29694 might have fixed the bug, but this requires a build and test to check current status.

May 15 2021, 1:59 AM
ehem_freebsd_m5p.com added a comment to D30256: sbin/init: merge ttys file down to single file.

Tested in a build and passed. Can be adjusted on commit, but I suspect this really should be titled "etc/ttys: merge ttys file down to single file". Grabbed the repository file location, instead of the output location when initially committing.

May 15 2021, 1:54 AM

May 13 2021

ehem_freebsd_m5p.com added a comment to D30256: sbin/init: merge ttys file down to single file.

Follow on for D29873. Clearly the ttys files have been slowly converging, so perhaps it is finally time to go ahead and merge them into a single file.

May 13 2021, 10:36 PM
ehem_freebsd_m5p.com requested review of D30256: sbin/init: merge ttys file down to single file.
May 13 2021, 10:22 PM
ehem_freebsd_m5p.com added a comment to D29873: etc/ttys: add the xen console.

One item of concern, is the placement of xc0 in the right spot in the list; should it be lower? Very much is not a serial port.

May 13 2021, 10:16 PM
ehem_freebsd_m5p.com retitled D29873: etc/ttys: add the xen console from etc/aarch64: ttys: add the xen console to etc/ttys: add the xen console.
May 13 2021, 10:10 PM
ehem_freebsd_m5p.com updated the diff for D29873: etc/ttys: add the xen console.

Adding an entry for /etc/ttys for amd64. PVH mode on x86 also has the simulated console.

May 13 2021, 10:08 PM
ehem_freebsd_m5p.com added a comment to D29873: etc/ttys: add the xen console.
In D29873#675696, @imp wrote:

The only reason to maybe add it is that our ttys are the same everywhere and we'd like to go to 1 ttys since the need to have it be radically different has passed away.

May 13 2021, 7:05 AM
ehem_freebsd_m5p.com requested review of D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.

Placing this back in the queue. I dislike proposing this without D30236 in place, since otherwise this looks like a bizarre commit.

May 13 2021, 4:13 AM
ehem_freebsd_m5p.com added a comment to D29818: xen/xenpv: introduce xen_arch_alloc_addr()/xen_arch_release_addr().

For the purposes of ARM, the API might be better to have a xenpv_set_addr_mgr(struct rman *) function. This allows for the allocated range to come from either device-tree or ACPI table. There are two outstanding issues.

May 13 2021, 4:06 AM
ehem_freebsd_m5p.com abandoned D29326: kern/intr: remove maxirqs from isrc_alloc_irq().

Changes to other commits overlapped this enough to make it no longer worthwhile as a separate commit.

May 13 2021, 3:46 AM
ehem_freebsd_m5p.com added a comment to D30228: x86/xen: remove PVHv1 code.

This isn't quite what I had expected, I was expecting more of cfa0b7b82fbdda56d7160569def5c6133eb045aa to be reverted. That though appears to have been done in a separate commit which isn't here.

May 13 2021, 3:20 AM

May 12 2021

ehem_freebsd_m5p.com requested review of D30236: xen/intr: move sys/x86/xen/xen_intr.c to sys/xen/xen_intr.c.
May 12 2021, 9:37 PM

May 8 2021

ehem_freebsd_m5p.com updated the diff for D29875: xen/arm64: add handling of Xen device-tree.

Updating D29875 to what I currently have, though I do not expect this to be final either. Mostly this is updating others on what I have. General idea is the call to xen_domain() at the top of xencons_cnprobe() could be replaced with a call to xen_early_probe(). On x86 xen_early_probe() would simply be a #define to xen_domain(), whereas on other architectures the console probe is when Xen's presence or absence needs to be known.

May 8 2021, 5:33 AM
ehem_freebsd_m5p.com updated the diff for D29310: kern/intr: switch to allocating handles forward.

Now with a much larger commit message. Notably this approach distinctly shrinks isrc_alloc_irq(). I like preserving the features which enhance performance. I'll admit some of the simplification is due to D29327 making maxirqs completely unnecessary (its purpose was to provide an unsigned version of intr_nirq).

May 8 2021, 5:26 AM
ehem_freebsd_m5p.com updated the diff for D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.

Updating with the latest from my current successful build. The PVHv1 portion may end up removed due to discontinuing support for PVHv1, but the handling of the shared_info page should be here. Plus hvm_start_flags and xen_domain_type become common.

May 8 2021, 5:20 AM

May 4 2021

ehem_freebsd_m5p.com updated the diff for D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.

Switching to SI_ORDER_SECOND from SI_ORDER_FIRST. With hypervisors, SI_ORDER_FIRST should be reserved for probing, whereas this is merely very early setup.

May 4 2021, 4:23 AM

May 3 2021

ehem_freebsd_m5p.com planned changes to D29598: xen/blkfront: WRITE_BARRIER and FLUSH_DISKCACHE require barrier.

Marking D29598 as changed planned. This needs to be tested for whether this is now unneeded.

May 3 2021, 3:31 AM
ehem_freebsd_m5p.com added a comment to D29873: etc/ttys: add the xen console.

Think about this, should D29873 add the Xen virtual console device to the sbin/init/ttys.* files for all architectures? This would keep these files consistent and at least one other architecture is looking at potential Xen support. My only question would be the treatment of x86. As of FreeBSD 12, the Xen code was using the emulated serial port as console instead of the ring. Should the ring device be added for x86 even though it currently isn't used?

May 3 2021, 3:29 AM
ehem_freebsd_m5p.com abandoned D29874: xen/arm64: add xen early init.

Marking D29874 as abandoned as the hunks have been scattered. The initial probe code has moved back to the device-tree code with D29875. The shared_info portions have joined D28982.

May 3 2021, 3:23 AM
ehem_freebsd_m5p.com planned changes to D29875: xen/arm64: add handling of Xen device-tree.

As a revision, I think this is mostly ready. Problem is due to taking the role of feeding interrupts to the rest of the Xen interface, it really needs the interrupt work done first.

May 3 2021, 3:16 AM
ehem_freebsd_m5p.com planned changes to D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.

Revision Actions => Plan Changes

May 3 2021, 3:14 AM

May 2 2021

ehem_freebsd_m5p.com added a comment to D29875: xen/arm64: add handling of Xen device-tree.

Several of the comments have been addressed, yet the issue pointed to during upload now looms large. This looks like it should come after the interrupt code situation is resolved.

May 2 2021, 1:11 AM
ehem_freebsd_m5p.com updated the diff for D29875: xen/arm64: add handling of Xen device-tree.

Still not in final shape.

May 2 2021, 12:59 AM
ehem_freebsd_m5p.com added a comment to D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.

Then I realize this really should be part of the work with the Xen interrupt work (which could still end up as a rewrite instead of being based off sys/x86/xen/xen_intr.c).

May 2 2021, 12:44 AM

May 1 2021

ehem_freebsd_m5p.com updated the diff for D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.

Update creating xen_handle_shared_info(). Idea is to share between x86 and
other architectures. This uses an approach similar to the one proposed for
ARM, but pieces have been inspired by the x86 implementation.

May 1 2021, 6:52 AM

Apr 28 2021

ehem_freebsd_m5p.com updated the diff for D29875: xen/arm64: add handling of Xen device-tree.

Updating to what I currently have. I do not think this is final.

Apr 28 2021, 10:02 PM

Apr 27 2021

ehem_freebsd_m5p.com updated the diff for D29811: xen/xen-os: move inclusion of machine/xen-os.h later.

Hmm, updated this locally and hadn't gotten it uploaded. Simply placing a #error in x86/xen/xen-os.h to prevent direct inclusion.

Apr 27 2021, 8:49 PM
ehem_freebsd_m5p.com added a comment to D29598: xen/blkfront: WRITE_BARRIER and FLUSH_DISKCACHE require barrier.

This is on my queue for investigation (alas, this is behind the queue for being submitted).

Apr 27 2021, 6:18 AM
ehem_freebsd_m5p.com added a comment to D29811: xen/xen-os: move inclusion of machine/xen-os.h later.

D29811 could use some attention. It is marked as parent for several since those break on x86 without D29811 (wrong order of function declaration, several call xen_*_domain()).

Apr 27 2021, 6:17 AM
ehem_freebsd_m5p.com added inline comments to D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.
Apr 27 2021, 4:30 AM
ehem_freebsd_m5p.com added a comment to D29875: xen/arm64: add handling of Xen device-tree.

I'm thinking what is xen_init() here is going to be merged into D28982. While D30006 would make the interrupt bit cleaner (assuming that actually works for x86).

Apr 27 2021, 3:51 AM
ehem_freebsd_m5p.com added a comment to D29913: xen/intr: move x86-only variable out of common.

This is an early phase of getting interrupts operational on ARM. Simply figuring out which functions are actually used in common files (or in case of xen_intr_handle_upcall() needs to be invoked). @julien_xen.org originally implemented it as moving sys/x86/xen/xen_intr.c to sys/xen/xen_intr.c, but I'm wondering whether it is better to start from scratch. The #ifdef in sys/x86/xen/xen_intr.c is a precursor to @julien_xen.org's approach. If it was reimplemented from scratch that would end up useless, but for now I'm keeping that option open.

Apr 27 2021, 3:09 AM
ehem_freebsd_m5p.com added a comment to D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.

The idea behind this is non-x86 really needs a function which can be passed to bus_setup_intr(). This results in two differences which I don't believe need any modifications what-so-ever to x86. First, instead of taking struct trap_frame * it takes void *.
Second, instead of being void, it returns int.

Apr 27 2021, 3:05 AM
ehem_freebsd_m5p.com added a comment to D29874: xen/arm64: add xen early init.

I think what is in D29874 is going to merge into D29875. I've got comments resolved in my tree. Could be a bit before I get things updated here though. This has turned back into a pile of misc patches and needs to get turned back into a patch.

Apr 27 2021, 2:55 AM
ehem_freebsd_m5p.com requested review of D30006: xen/intr: change return of xen_intr_handle_upcall() to match filter.
Apr 27 2021, 2:54 AM

Apr 26 2021

ehem_freebsd_m5p.com added a comment to D28982: xen: move common variables and code off of sys/x86/xen/hvm.c.

Thing is my goal is to get Xen/ARM working. If removing PVHv1 support made that noticeably easier, I would be for that. Yet here it makes minimal difference to simply leave it alone and removing it would require me to check I hadn't broken anything.

Apr 26 2021, 11:10 PM
ehem_freebsd_m5p.com retitled D28982: xen: move common variables and code off of sys/x86/xen/hvm.c from xen: Break hypervisor_info off of sys/x86/xen/hvm.c to xen: move common variables and code off of sys/x86/xen/hvm.c.
Apr 26 2021, 10:59 PM