If auto margins are present, we need to turn them off or enter
an insert mode to "push" the character we want into the corner.
If pushing a wide character of greater than one cell, we need something
more than ich1, othewise the bottom right corner will remain blank.
Follow on fix for PR# 30978.
OK jdc@
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.
This man-page first appeared before porting all the features to NetBSD and
actually Pad ones were never ported. Keeping it in the documentation is
misleading and actually caused bugs in handling of these functions in 3rd
party software.
(which has redirects, and so is included in -x output) use the -x/+x
setting that existed when the comoound started, so if the state of
xtrace changes during the command we don't end up with just half of
the -x output (either the intro, or the conclusion, depending on
which way the change happened). [this also happens to avoid a core
dump in the previous code, but that could have been done other ways,
this way actually simplifies things (less code)]
Fix a few endian bugs and check the main core version before trying to
read the hardware feature mask. Only read the hardware feature register
if core version reported is >= 3.5 (all my older hardware reports 0).
With some hints and patches from jared, and ok from aymeric
When eval'ing RESTARTCMD don't field split it, only to join the words
again (by eval) - that converts newlines and tabs to spaces, and the
first of those causes sh syntax errors with the way that the various
RESTARTCMDs are now written (but it was always dangerous, as filename
expansions could also have happened, which is not wanted, I believe.)
Also correct a translation error.
The sharing is accomplished by demultiplexing the port event of the first
bind. This is accomplished in intr.c:intr_establish_xname()
Note that the pic_delroute() is buggy (commented suitably) for the shared
gsi case, since it will unbind reset it unconditionally, leaving the other
shared callbacks stranded.
This problem will go awaywhen we unify further with native code, as this
case is taken care of appropriately in that case.
Restore old behaviour to flush pages only when usage exceeds 1MB.
No longer use PGO_SYNCIO, regular writes to the device do not require
the data to reach stable storage, the DIOCCACHESYNC ioctl is used
for that.
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.
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.
