Age | Commit message (Collapse) | Author |
|
|
|
the 12 bits available for it in struct iwm_tfd_tb.hi_n_len.
Patch by Imre Vadasz via tech@
|
|
From Dmitri Alenichev.
|
|
with ACPI.
ok jsg@
|
|
subframes. Helps 11n mode with WPA.
tested by me, tb@, and krw@
|
|
about A-MPDU spacing. Makes BlockAck happy.
tested by me, tb@, krw@, sthen@, and Henrik Friedrichsen
|
|
about A-MPDU spacing. Makes BlockAck happy.
tested by myself and abieber@
|
|
tables in radeondrm(4).
|
|
Follow FreeBSD and schedule the next Tx completion event to fire
when about half of the packet segments scheduled for transmission
are consumed.
|
|
|
|
|
|
|
|
Initial help & testing by jmatthew@
Code review & input by mpi@
Final review & OK by jsg@
|
|
Now we can see rts/cts, ack, blockack etc. in tcpdump(8).
ok kettenis@
|
|
HT protection setting updates. Unbreaks WPA in 11n mode.
ok sthen@
|
|
|
|
Bail out early to prevent a panic from calling bus_space_map(9) with size 0.
|
|
mechanism is used to configure VMs in the VMware vSphere world:
instead of using individual key-value guestinfo.* properties, it uses
the guestinfo.ovfEnv value to pass an enterprise-compliant XML file
that includes key-value properties. This file can be rather large,
especially with comments, but 4k ought to be enough for anybody.
Also change a stack buffer to malloc'ed memory in the ioctl path.
OK mikeb@
|
|
Unfortunately, making this decision in radeondrm_attachhook() is too late
because at that point efifb(4) would have already been attached. This means
that if we decide to bail in radeondrm_attachhook() we may end up without
a glass console. That may happen for example if the firmware package
has not been installed. I'm still looking for a solution for that problem.
ok jsg@
|
|
Nathanael Rensen <nathanael at list ! polymorpheus ! com> came up with
a few improvements to the event watcher and power management interface,
namely:
o Make sure to put our watcher on a list before issuing an XS_WATCH
command since Xen will raise the event right after it's been set up.
o The first time xen_control is called the "control/shutdown" node
may not exist, so skip printing the error message in this case.
o Acknowledge requests by writing back an empty string.
o log(9) reboot and halt requests like vmt(4) does.
Huge thanks!
|
|
|
|
|
|
|
|
At the moment only "poweroff" and "reboot" actions are supported.
Suspend/resume requires additional changes.
|
|
After configuring a watch for the node, XenStore will asynchronously
notify the system when the value of the specified node changes with
an event message.
|
|
Turns out that we want to let devices choose whether they're issuing
XenStore requests to the backend or frontend. This also unifies the
the API somewhat as providing the xen softcore structure is now
mandatory.
|
|
into hid_desc_buf
tested by jsg
|
|
|
|
Remove leftover code that was used to set v2 of Grant Table entries.
From Nathanael Rensen <nathanael at list ! polymorpheus ! com>, thanks!
|
|
|
|
Instead of pre-allocating maximum number of Grant Table frames allotted by
the hypervisor we switch over to allocating them dynamically when the need
arises. At the same time we no longer link metadata entries representing
individual Grant Table frames as a list and use a table instead to speed
up reference lookups when establishing and removing mappings.
|
|
|
|
|
|
in the underlying information store of the host from the OpenBSD-VM's
userspace. OpenBSD did not provide access to these stores before,
mostly because we did not want to add a custom tool and interface for
each hypervisor. The pvbus(4) interface provides backends for
xen(4)'s XenStore and vmt(4)'s VMware Tools "guestinfo". These
information stores are fairly different, XenStore is a "filesystem"
while vmt is a RPC, and the key-value abstraction limits them a bit
but provides the most wanted functionality.
Discussed with many
OK mikeb@
|
|
|
|
Xen doesn't provide transmit fragment chains so initially they were
emulated but amount of grant table entries wasted in the process was
astronomical (9 times more than after this change). So while code
readability was sacrificed a bit, the change comes with a very nice
transmit performance improvement and taxes grant table references
much less than before.
|
|
Setting rxr_ and/or txr_cons_event value allows domU to delay completion
notification for receive and/or transmit ring to specified values of
consumer index. rxr_ and txr_prod_event values are updated by dom0 and
don't seem to hold any significance for us.
|
|
Grant table API is constructed in a way that once allocated grant table
entries are marked as used and cannot be given away again to some other
user. At the same time xen_grant_table_enter and _remove do not operate
on the same grant reference at the same time, so there's no need for a
lock here. Guard flag operations with memory fences to ensure correct
store/load order. This provides some decent performance improvement as
well.
|
|
This debugging check has been helpful in identifying and fixing
a few issues already. Subject to removal in the future however.
|
|
|
|
When executed under the hypervisor we need to make sure that CAS
and other atomic operations are executed while locking the bus.
Problem reported by Imre Oolberg <imre at auul ! pri ! ee>, thanks!
|
|
the generation bit to pass the tx descriptor and mbuf to the "hardware".
This way bpf is not called if vmxnet3_load_mbuf dropped the mbuf.
Tested by me
OK mikeb@
|
|
from richard proctor on bugs@
|
|
diff from richard proctor on bugs@
|
|
|
|
drivers update hardware configuration accordingly.
tested by myself, tb@, deraadt@, abieber@
ok mpi@
|
|
Figured out the hard way by Jonathon Sisson <openbsd at j3z ! org>,
thanks!
|
|
the hardware. This could have resulted in a page fault when the mbuf
has already been freed by the TX interrupt handler on another CPU.
This has the slight drawback that bpf can be called before the packet
is eventually dropped by vmxnet3_load_mbuf() - but I'm getting this
simple and verified fix in before doing further optimizations on the
start handler.
As discussed with mikeb@ jsg@ dlg@
|
|
|
|
the size of the pointer to a struct.
ok mikeb@
|