| Age | Commit message (Collapse) | Author |
|
it handles the console and 0 otherwise (especially when console=tty0 or
console=pc is present on the command line).
In consinit() fallback to native console selection if xen_pvh_consinit()
returns 0.
|
|
No functional change intended.
|
|
Use membar_acquire and membar_release, not membar_consumer and
membar_producer, out of paranoia -- that better matches Linux's
rmb/wmb (at least for non-I/O loads and stores).
Proposed on port-xen:
https://mail-index.netbsd.org/port-xen/2022/07/13/msg010248.html
|
|
There has been no objection for three years.
https://mail-index.netbsd.org/port-amd64/2019/09/22/msg003012.html
Implemented by nonaka@n.o, updated by me.
|
|
|
|
Basically, in PVH mode (where XENFEAT_auto_translated_physmap is enabled),
the hypervisor will not map foreing ressources in our virtual address
space for us. Instead, we have to pass it an address in our physical
address space (but not mapped to some RAM) where the ressource will show up
and then enter this PA in pour page table.
For this, introduce xenmem_* which manage the PA space. In PVH mode this
is just allocated from the iomem_ex extent.
With this, I can start a PV domU, and the guest's kernel boots (and
the console works). It hangs because the backend driver can't map the
frontend ressources (yet).
Note that, per https://xenbits.xen.org/docs/unstable/support-matrix.html,
dom0 PVH support is still considered experimental by Xen.
|
|
Support up to HVM_MAX_VCPUS (256). This requires resizing a few arrays in
evtchn.c, and using
VCPUOP_register_vcpu_info for vcpuid >= XEN_LEGACY_MAX_VCPUS
Tested with 96 vCPUs.
|
|
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.
|
|
It is needed.
Hopefully fixes kern/56291, kern/56793, kern/55667
|
|
|
|
|
|
reinstantiate it
header is for use by xentools only, which define domid_t themselves,
so it should not be a problem the header doesn't define it per PR port-xen/52874
|
|
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
|
|
PR port-xen/52874
|
|
IOCTL_PRIVCMD_MMAPBATCH_V2
IOCTL_PRIVCMD_MMAP_RESOURCE
IOCTL_GNTDEV_MMAP_GRANT_REF
IOCTL_GNTDEV_ALLOC_GRANT_REF
|
|
pass flags to xpq_update_foreign()
Introduce a pmap MD flag: PMAP_MD_XEN_NOTR, which cause xpq_update_foreign()
to use the MMU_PT_UPDATE_NO_TRANSLATE flag.
make xpq_update_foreign() return the raw Xen error. This will cause
pmap_enter_ma() to return a negative error number in this case, but the
only user of this code path is privcmd.c and it can deal with it.
Add pmap_enter_gnt()m which maps a set of Xen grant entries at the
specified va in the specified pmap. Use the hooks implemented for EPT to
keep track of mapped grand entries in the pmap, and unmap them
when pmap_remove() is called. This requires pmap_remove() to be split
into a pmap_remove_locked(), to be called from pmap_remove_gnt().
|
|
numbers <= NR_EVENT_CHANNELS (2048)
|
|
|
|
event_set_handler() will choose the CPU and bind the event.
If ci is not NULL the caller is responsible for binding the event.
Use a IPI xcall to register the handlers if needed.
pull in a hack from x86 to force pirq handlers to be mpsafe if registered at
a level != IPL_VM. This is for the com at isa interrupt handler, which
registers at IPL_HIGH and has to way to tell it's mpsafe (taking
KERNEL_LOCK at IPL_HIGH causes deadlocks on MP systems).
|
|
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
|
|
This is compiled in with
options XENPVHVM
x86 changes:
- add Xen section and xen pvh entry points to locore.S. Set vm_guest
to VM_GUEST_XENPVH in this entry point.
Most of the boot procedure (especially page table setup and switch to
paged mode) is shared with native.
- change some x86_delay() to delay_func(), which points to x86_delay() for
native/HVM, and xen_delay() for PVH
Xen changes:
- remove Xen bits from init_x86_64_ksyms() and init386_ksyms()
and move to xen_init_ksyms(), used for both PV and PVH
- set ISA no-legacy-devices property for PVH
- factor out code from Xen's cpu_bootconf() to xen_bootconf()
in xen_machdep.c
- set up a specific pvh_consinit() which starts with printk()
(which uses a simple hypercall that is available early) and switch to
xencons when we can use pmap_kenter_pa().
|
|
|
|
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor
|
|
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
|
|
|
|
|
|
|
|
it now fails only if the Xen hypercall fails, in which case the failure
is final
change xbdback to pre-allocate KVA on xbdback attach (and free on detach),
so it has always KVA to map the request pages
remove no longer needed KVA allocation failure handling
|
|
are bound to a different CPU at creation time).
Recent MI changes caused the scheduler to choose a different CPU when
probing and attaching xennet devices (I guess it's the xenbus thread which
runs on a different CPU). This cause the callback to be called on a different
CPU than the one expected by the kernel, and the event is ignored.
It is handled when the clock causes the callback to be called on the right
CPU, which is why xennet still run, but slowly.
Change event_set_handler() to do a EVTCHNOP_bind_vcpu if requested to,
and make sure we don't do it for IPIs and VIRQs (for theses, the op fails).
|
|
devices which don't use autoconfig, remove from attach args
|
|
use bus_dmamap_load_mbuf() et.al.
due to XENPV override, _BUS_BUS_TO_PHYS() dmamap segment ds_addr
gets filled with ma, so value can be directly used for e.g. grant calls
|
|
this brings grant memory v2 support:
- status separated from flags - revoking access needs just memory barrier,
no need for expensive cmpxchg16 any more
- sub-page hypervisor copy-only grants, to be used by xennet(4)
- 64-bit frame, i.e. support for DomU RAM >16TB
the grant table is now always allocated on boot to maximum size, it's now
never grown in runtime; switch back to regular kmem_alloc()/kmem_free()
code now requires v2 support, no compatibility for grant version 1 retained -
Xen v2 support predates all currently supported Xen versions
also interface for baloon changed slightly, code updated
|
|
that call in xenbus_dev_write() wouldn't need to know how it's allocated
|
|
xenbus_directory(), so that caller doesn't need to be aware how the memory
was allocated
|
|
plug memory leak in one xenbus_probe_device_type() error path
when read_backend_details() fails
|
|
|
|
|
|
need to use non-constant path
|
|
size, caller doesn't free(9) the returned value any more
|
|
or "backend"; just use the strings direct
|
|
to underlying event_set_handler()
|
|
|
|
uses it any more
|
|
|
|
simply set the supported csum offload flags to skip the software csum
verification
|
|
checksum; this is used to skip software checksum validation on
xennet Rx side when configured for Rx offloading
in Dom0 assume that checksum is valid when the Tx mbuf has no offload flags
- in that case either it's local packet where checksum has just been
computed in software, or forwarded external packet already
verified when received on Dom0
practical offshot of this is that DomU doesn't re-verify checksum of
packets forwarded from external hosts, e.g. via bridge(4)
|
|
to use in_undefer_cksum() instead of custom code to compute the checksum
for Rx packets, and set csum_data appropriately for eventual hw offloading
make it possible to skip the sw checksum computation by appropriate Rx
flag similarily as we do for Tx
XXX for now, the Rx flag is mostly for testing as it only works for
dom0<->domu, need some further network stack changes to arrange for
the checksum to be eventually computed when packets goes outside xen
|
|
|
|
- Remove all code that should be MI, leaving the bare minimum under arch/.
- Make the required actions very explicit.
- Pass in LWP pointer for convenience.
- When a trap is required on another CPU, have the IPI set it locally.
- Expunge cpu_did_resched().
|
|
|