Age | Commit message (Collapse) | Author |
|
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!
|
|
|
|
Figured out the hard way by Jonathon Sisson <openbsd at j3z ! org>,
thanks!
|
|
the size of the pointer to a struct.
ok mikeb@
|
|
Instead of just setting bits that we think we need, do a better job of
figuring out what's supported by the backend and what's not and what do
we really need. The following improvements were implemented:
o fallback for when scatter gather I/O is not supported by Dom0;
o tcp/udp checksum offloading;
o larger mtu up to 9000: an experimental feature;
o stop requesting multicast control feature that we don't support.
|
|
After some experimentation, discussions with Xen folks and pondering Linux
source code, it became clear that most versions of Xen require at least 18
slots available on the receive ring to send an event.
|
|
|
|
membar_* functions are defined only as compiler barriers on !MP
kernels, while we're trying to be conservative in our use of the
barriers. Barriers are placed only where loads and stores might
get reordered and it matters at the same time. Shared info page
operations are using atomic instructions on Linux, so they get
barriers as well.
|
|
Reported by Jonathon Sisson <openbsd at j3z ! org>, thanks!
|
|
|
|
A crash reported by Jonathon Sisson is caused by incorrect calculation
of available descriptors on the tx ring. While here, split the mbuf
chain so that we won't unload the whole thing in the txeof before
removing grant table references from transmit descriptors.
|
|
When testing evtchn_mask bits we need to treat the array as a bit
matrix for an isset macro to test correct bits. Reported by reyk@
some time ago, Wei Liu <wei ! liu2 at citrix !com> figured out how
to reproduce the problem. Thanks!
|
|
|
|
|
|
Reyk has reported an issue that turned out to be an incorrect calculation
of bytes available for reading. This diff also places missed semaphore
releases in the xs_start and makes 'left' a size_t in xs_ring_{get,put}.
|
|
|
|
Xen doesn't provide a way for a guest to decide which model of
the interface is selected in the VM configuration and therefore
there's no simple way for Netfront and emulated devices to co-
exist on the same system. Emulated em(4) or re(4) drivers will
take over if xnf(4) driver is disabled or not compiled in.
Idea and OK reyk
|
|
|
|
|
|
|
|
|
|
We need to ensure that rx and tx fragments do not cross page boundary
since grant table reference can only point to a complete page. Add a
couple of kernel assertions in the dma map loading code to catch these
problems early in the future.
|
|
|
|
After some hair pulling while implementing xnf(4) I've realised that
Xen uses free running producer/consumer indices wrapping with their
type (unsigned 32 bit integer). Later I've confirmed it with free
chapters of the "The Definitive Guide to the Xen Hypervisor" by David
Chisnall available online.
|
|
|
|
xs_intr() but put an empty message in the queue. This prevents
xs_reply() from being stuck in an endless loop because it expectes a
message in the queue to break out of it. Depends on mikeb@'s previous
commit because it would otherwise panic on trying to cleanup the empty
message.
OK mikeb@
|
|
Problem was reported and analyzed by reyk@
|
|
|
|
Encouragement from deraadt@, ok reyk
|
|
In spite of comments in the Xen source code encouraging use of v2
entries in the new code, there's no benefit for us to do so at the
moment. While v1 entries support only full page mappings, they're
half the size of their newer counterparts, increasing the number
of available grant table references from 8000 to 16000 within the
same allotment of grant table frames (up to 32).
|
|
Grant table references don't convey the information about an actual
offset of the data within the page, however Xen needs to know it.
We (ab)use bus_dma_segment's _ds_boundary member to store it and can
get away with not restoring it's original value atm because neither
i386 nor amd64 bus_dmamap_unload(9) code needs it.
|
|
|
|
|
|
|
|
when NULL or zero length value was specified.
|
|
|
|
Mask the event port during xen_intr_establish, but don't set the
masked flag in the intsrc. By providing mask and unmask routines
we allow the device to decide when to perform these actions. The
port will still be unmasked during xen_intr_enable. This allows
netfront to fulfil the intr_barrier pattern requirements fairly
easily and at the same time should be sufficient for diskfront
that doesn't need to fiddle with interrupt masking.
|
|
|