![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / arch / xen / x86
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.24 / (download) - annotate - [select for diffs], Thu May 26 11:06:14 2022 UTC (12 months, 2 weeks ago) by bouyer
Branch: MAIN
CVS Tags: netbsd-10-base,
netbsd-10,
bouyer-sunxi-drm-base,
bouyer-sunxi-drm,
HEAD
Changes since 1.23: +3 -3
lines
Diff to previous 1.23 (colored)
aprint_debug(): if a hypercall fail, print the return code.
Revision 1.23 / (download) - annotate - [select for diffs], Tue May 24 15:51:10 2022 UTC (12 months, 2 weeks ago) by bouyer
Branch: MAIN
Changes since 1.22: +3 -3
lines
Diff to previous 1.22 (colored)
Remove useless info from debug printf, fix format warning on i386
Revision 1.22 / (download) - annotate - [select for diffs], Tue May 24 14:00:23 2022 UTC (12 months, 2 weeks ago) by bouyer
Branch: MAIN
Changes since 1.21: +5 -3
lines
Diff to previous 1.21 (colored)
- msipic_construct_msix_pic(): set mp_table_base to memaddr (without table_offset), this is what Xen wants while there use pci_conf_write16() in msi_set_msictl_enablebit() too, for consistency (it seems that Xen accepts the 32bit write at this point, but this may change). - xen_map_msix_pirq(): don't forget to set map_irq.table_base in the MSI-X case, otherwise Xen maps it as MSI - call pic_hwunmask() after pirq_establish() in msi/msix case, to make sure the msi-x vector is unmasked. Now MSI-X works with Xen so stop disabling it in pci_attach_hook().
Revision 1.21 / (download) - annotate - [select for diffs], Mon May 23 15:03:05 2022 UTC (12 months, 2 weeks ago) by bouyer
Branch: MAIN
Changes since 1.20: +91 -29
lines
Diff to previous 1.20 (colored)
Work in progress on MSI/MSI-X on Xen (MSI works on my hardware, more work needed for MSI-X): - Xen silently rejects 32 bits writes to MSI configuration registers (especially when setting PCI_MSI_CTL_MSI_ENABLE/PCI_MSIX_CTL_ENABLE), it expects 16 bits writes. So introduce a pci_conf_write16(), only available on XENPV (and working only for mode 1 without PCI_OVERRIDE_CONF_WRITE) and use it to enable MSI or MSI-X on XENPV. - for multi-MSI vectors, Xen allocates all of them in a single hypercall, so it's not convenient to do it at intr_establish() time. So do it at alloc() time and register the pirqs in the msipic structure. xen_pic_to_gsi() now just returns the values cached in the msipic. As a bonus, if the PHYSDEVOP_map_pirq hypercall fails we can fail the alloc() and we don't need the xen_pci_msi*_probe() hacks. options NO_PCI_MSI_MSIX still on by default for XEN3_DOM0.
Revision 1.20 / (download) - annotate - [select for diffs], Sat Aug 1 12:39:40 2020 UTC (2 years, 10 months ago) by jdolecek
Branch: MAIN
CVS Tags: thorpej-i2c-spi-conf2-base,
thorpej-i2c-spi-conf2,
thorpej-i2c-spi-conf-base,
thorpej-i2c-spi-conf,
thorpej-futex2-base,
thorpej-futex2,
thorpej-futex-base,
thorpej-futex,
thorpej-cfargs2-base,
thorpej-cfargs2,
thorpej-cfargs-base,
thorpej-cfargs,
cjep_sun2x-base1,
cjep_sun2x-base,
cjep_sun2x,
cjep_staticlib_x-base1,
cjep_staticlib_x-base,
cjep_staticlib_x
Changes since 1.19: +4 -1
lines
Diff to previous 1.19 (colored)
adjust includes to pull __HAVE_PCI_MSI_MSIX properly
Revision 1.19 / (download) - annotate - [select for diffs], Sun Jul 19 16:20:36 2020 UTC (2 years, 10 months ago) by jdolecek
Branch: MAIN
Changes since 1.18: +3 -1
lines
Diff to previous 1.18 (colored)
add #ifdef __HAVE_PCI_MSI_MSIX so this still compiles with NO_PCI_MSI_MSIX
Revision 1.18 / (download) - annotate - [select for diffs], Sun Jul 19 14:27:07 2020 UTC (2 years, 10 months ago) by jdolecek
Branch: MAIN
Changes since 1.17: +63 -23
lines
Diff to previous 1.17 (colored)
for Xen MSI, fallback to INTx when PHYSDEVOP_map_pirq fails for the device apparently Xen requires VT-d to be enabled in BIOS for PHYSDEVOP_map_pirq to work, this change makes it work on systems with VT-d disabled or missing adresses the panic part of PR port-xen/55285 by Patrick Welche
Revision 1.17 / (download) - annotate - [select for diffs], Sat May 23 14:51:19 2020 UTC (3 years ago) by jdolecek
Branch: MAIN
Changes since 1.16: +12 -11
lines
Diff to previous 1.16 (colored)
switch back to PHYSDEVOP_alloc_irq_vector for non-MSI interrupts - on my computer it works the same as PHYSDEVOP_map_pirq, but seems it doesn't on other systems fixes PR port-xen/55285 for Patrick Welche, but not yet for another system by Frank Kardel
Revision 1.16 / (download) - annotate - [select for diffs], Fri May 15 07:42:58 2020 UTC (3 years ago) by jdolecek
Branch: MAIN
Changes since 1.15: +2 -2
lines
Diff to previous 1.15 (colored)
use short for irq2port[] to save memory (4KB), it only needs to store numbers <= NR_EVENT_CHANNELS (2048)
Revision 1.15 / (download) - annotate - [select for diffs], Fri May 15 07:31:07 2020 UTC (3 years ago) by jdolecek
Branch: MAIN
Changes since 1.14: +10 -3
lines
Diff to previous 1.14 (colored)
only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code fixes boot problem reported privately by Frank Kardel and Patrick Welche
Revision 1.14 / (download) - annotate - [select for diffs], Mon May 4 15:55:56 2020 UTC (3 years, 1 month ago) by jdolecek
Branch: MAIN
Changes since 1.13: +52 -30
lines
Diff to previous 1.13 (colored)
add support for using MSI for XenPV Dom0 use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx to use it instead of PHYSDEVOP_alloc_irq_vector MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4) XXX added some provision for MSI-X, but it doesn't actually work (no interrupts delivered), needs some further investigation; disable MSI-X for XENPV via flag in x86/pci/pci_machdep.c
Revision 1.13 / (download) - annotate - [select for diffs], Sat Apr 25 15:26:17 2020 UTC (3 years, 1 month ago) by bouyer
Branch: MAIN
Changes since 1.12: +1 -1
lines
Diff to previous 1.12 (colored)
Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM guests in GENERIC. Xen support can be disabled at runtime with boot -c disable hypervisor
Revision 1.11.2.1 / (download) - annotate - [select for diffs], Sat Apr 25 11:23:57 2020 UTC (3 years, 1 month ago) by bouyer
Branch: bouyer-xenpvh
Changes since 1.11: +10 -11
lines
Diff to previous 1.11 (colored) next main 1.12 (colored)
Sync with bouyer-xenpvh-base2 (HEAD)
Revision 1.12 / (download) - annotate - [select for diffs], Tue Apr 21 20:13:40 2020 UTC (3 years, 1 month ago) by jdolecek
Branch: MAIN
CVS Tags: bouyer-xenpvh-base2
Changes since 1.11: +10 -11
lines
Diff to previous 1.11 (colored)
convert to newer HYPERVISOR_physdev_op() interface, now command and the arg are separate arguments - this is needed for newer physdev_op commands remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since interface version 0x00030202 and is unsupported by newer versions of Xen confirmed working on amd64 Dom0, i386 compile-tested only
Revision 1.3.4.2 / (download) - annotate - [select for diffs], Mon Apr 13 08:04:12 2020 UTC (3 years, 1 month ago) by martin
Branch: phil-wifi
Changes since 1.3.4.1: +1 -2
lines
Diff to previous 1.3.4.1 (colored) to branchpoint 1.3 (colored) next main 1.4 (colored)
Mostly merge changes from HEAD upto 20200411
Revision 1.11 / (download) - annotate - [select for diffs], Tue Apr 7 07:43:33 2020 UTC (3 years, 2 months ago) by jdolecek
Branch: MAIN
CVS Tags: phil-wifi-20200421,
phil-wifi-20200411,
bouyer-xenpvh-base1,
bouyer-xenpvh-base
Branch point for: bouyer-xenpvh
Changes since 1.10: +1 -2
lines
Diff to previous 1.10 (colored)
remove <sys/malloc.h> include, not used here
Revision 1.3.4.1 / (download) - annotate - [select for diffs], Mon Jun 10 22:06:56 2019 UTC (4 years ago) by christos
Branch: phil-wifi
Changes since 1.3: +64 -71
lines
Diff to previous 1.3 (colored)
Sync with HEAD
Revision 1.10 / (download) - annotate - [select for diffs], Wed Feb 13 06:15:51 2019 UTC (4 years, 3 months ago) by cherry
Branch: MAIN
CVS Tags: phil-wifi-20200406,
phil-wifi-20191119,
phil-wifi-20190609,
netbsd-9-base,
netbsd-9-3-RELEASE,
netbsd-9-2-RELEASE,
netbsd-9-1-RELEASE,
netbsd-9-0-RELEASE,
netbsd-9-0-RC2,
netbsd-9-0-RC1,
netbsd-9,
isaki-audio2-base,
isaki-audio2,
is-mlppp-base,
is-mlppp,
ad-namecache-base3,
ad-namecache-base2,
ad-namecache-base1,
ad-namecache-base,
ad-namecache
Changes since 1.9: +9 -7
lines
Diff to previous 1.9 (colored)
Catchup with struct intrstub; unification. This should fix dom0 build breakage.
Revision 1.3.2.1 / (download) - annotate - [select for diffs], Sat Oct 20 06:58:30 2018 UTC (4 years, 7 months ago) by pgoyette
Branch: pgoyette-compat
CVS Tags: pgoyette-compat-merge-20190127
Changes since 1.3: +56 -65
lines
Diff to previous 1.3 (colored) next main 1.4 (colored)
Sync with head
Revision 1.9 / (download) - annotate - [select for diffs], Wed Oct 10 02:34:08 2018 UTC (4 years, 8 months ago) by cherry
Branch: MAIN
CVS Tags: pgoyette-compat-20190127,
pgoyette-compat-20190118,
pgoyette-compat-1226,
pgoyette-compat-1126,
pgoyette-compat-1020
Changes since 1.8: +3 -3
lines
Diff to previous 1.8 (colored)
Do not export the 'irq<->vector' abstraction outside of pintr.c anymore. We now think of them as a unified thing called 'gsi', which is generated by mpacpi/mpbios
Revision 1.8 / (download) - annotate - [select for diffs], Wed Oct 10 02:16:34 2018 UTC (4 years, 8 months ago) by cherry
Branch: MAIN
Changes since 1.7: +2 -3
lines
Diff to previous 1.7 (colored)
Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code, it's possible for shared GSIs to popup even outside the original legacy_irq range. Relax this latter, older assumption. Thanks to Brad Spencer for extensive trialing on interesting hardware.
Revision 1.7 / (download) - annotate - [select for diffs], Sun Oct 7 05:23:01 2018 UTC (4 years, 8 months ago) by cherry
Branch: MAIN
Changes since 1.6: +54 -60
lines
Diff to previous 1.6 (colored)
Switch over to a "GSI" concept for guest irqs. On XEN there is a namespace called GSI which includes: i) legacy_irq (0 - 16) ii) "gsi" (16-nr_irqs_gsi) iii) msi We try to mirror this in guest space, but are mindful that legacy_irq is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't really care what number scheme we use, as long as it doesn't encroach on the MSI space, which is TBD for us. Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin tuples into the correct global gsi space, which we then register with xen. As we now do, we allow for duplicate gsi registrations, in case any hardware shares the same (pic,pin); This enables us to now use the (pic,pin) tuple as the canonical reference for device interrupt addresses, and leave any global mappings to specific code. Thus xen_pic_to_gsi(). Note that this requires separate support for MSI, which I will get around to once things stabilise - however the API change facilitates this nicely. I note that the msi addroute() function does not use the "pin" parameter. This can be made use of, to encode the gsi number, for XEN. This is however TBD. We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS and other cases, and ensure that i8259.c DTRT wrt to route(). This will allow us to use pic->pic_addroute() without needing to worry about pic specific issues. The next step is to consolidate the pic_addroute() XEN related #ifdefs into a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs. This change has functional implications, and there is likely breakage coming especially on bespoke platforms that I haven't been able to test yet. I am especially interested in bug reports from platforms with legacy (esp. i386) and with multiple ioapics.
Revision 1.6 / (download) - annotate - [select for diffs], Sat Oct 6 16:49:54 2018 UTC (4 years, 8 months ago) by cherry
Branch: MAIN
Changes since 1.5: +7 -9
lines
Diff to previous 1.5 (colored)
Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect its actual job. The idea is that we will strip this down until it is as close to idt_vec_alloc() as possible.
Revision 1.5 / (download) - annotate - [select for diffs], Sat Oct 6 16:44:55 2018 UTC (4 years, 8 months ago) by cherry
Branch: MAIN
Changes since 1.4: +3 -7
lines
Diff to previous 1.4 (colored)
Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to intr.c:intr_establish_xname() xen_pirq_alloc() now returns a vector value, as is intended by the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR. This also brings our usage closer to native.
Revision 1.4 / (download) - annotate - [select for diffs], Sat Oct 6 16:37:11 2018 UTC (4 years, 8 months ago) by cherry
Branch: MAIN
Changes since 1.3: +7 -3
lines
Diff to previous 1.3 (colored)
Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.
The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:
i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.
Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.
This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.
Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.
In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.
Revision 1.3 / (download) - annotate - [select for diffs], Sat Feb 17 18:51:53 2018 UTC (5 years, 3 months ago) by maxv
Branch: MAIN
CVS Tags: phil-wifi-base,
pgoyette-compat-base,
pgoyette-compat-0930,
pgoyette-compat-0906,
pgoyette-compat-0728,
pgoyette-compat-0625,
pgoyette-compat-0521,
pgoyette-compat-0502,
pgoyette-compat-0422,
pgoyette-compat-0415,
pgoyette-compat-0407,
pgoyette-compat-0330,
pgoyette-compat-0322,
pgoyette-compat-0315
Branch point for: phil-wifi,
pgoyette-compat
Changes since 1.2: +2 -2
lines
Diff to previous 1.2 (colored)
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the same name, eg: legacy_stubs -> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0 -> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1 ...
Revision 1.2 / (download) - annotate - [select for diffs], Wed Dec 13 16:30:18 2017 UTC (5 years, 5 months ago) by bouyer
Branch: MAIN
Changes since 1.1: +23 -5
lines
Diff to previous 1.1 (colored)
Fixes for physical interrupts on Xen: - do not cast int * to intr_handle_t *, they're not the same size - legacy_irq is not always -1 for ioapic interrupts, test pic_type instead - change irq2port[] to hold (port + 1) so that 0 is an invalid value - add KASSERTs to make sure vect, port or irq values extracted from arrays are valid (or that they are invalid before write) - for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and bind_pirq_to_evtch(). now XEN3_DOM0 boots again
Revision 1.1.2.2 / (download) - annotate - [select for diffs], Sun Dec 3 11:36:51 2017 UTC (5 years, 6 months ago) by jdolecek
Branch: tls-maxphys
Changes since 1.1.2.1: +213 -0
lines
Diff to previous 1.1.2.1 (colored) to branchpoint 1.1 (colored) next main 1.2 (colored)
update from HEAD
Revision 1.1.2.1, Sat Nov 4 09:22:16 2017 UTC (5 years, 7 months ago) by jdolecek
Branch: tls-maxphys
Changes since 1.1: +0 -213
lines
FILE REMOVED
file pintr.c was added on branch tls-maxphys on 2017-12-03 11:36:51 +0000
Revision 1.1 / (download) - annotate - [select for diffs], Sat Nov 4 09:22:16 2017 UTC (5 years, 7 months ago) by cherry
Branch: MAIN
CVS Tags: tls-maxphys-base-20171202
Branch point for: tls-maxphys
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map hardware interrupts to XEN callbacks called 'events'. This function combines both the allocation and the binding. This change is the first part of breaking up that combination into xen_pirq_alloc() and the binding will happen as part of the pic_addroute() callback of a new pseudo PIC_XEN This code will be added later on.