Age | Commit message (Collapse) | Author |
|
Rather than performing an atomic bit clearing for every encountered
event bit set we can adjust the code to perform an atomic swap of a
single row of the events array and decrease the amount of expensive
atomic operations.
Same optimization as for Hyper-V. From FreeBSD.
|
|
Rather than performing an atomic bit clearing for every encountered
event bit set we can adjust the code to perform an atomic swap of a
single row of the events array and decrease the amount of expensive
atomic operations.
From FreeBSD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change adds a check into the Rx ring completion routine that
schedules an interrupt task to be executed immediately after if
consumer index has already advanced itself. The benefit of doing
this compared to an additional loop after replenishing the ring
(as done in FreeBSD for example) is that first of all this goes
through the loop in the taskqueue thread with a yeild check to
prevent CPU hogging and second is that it triggers Tx completion
as well since interrupt handler runs both.
|
|
Pending event bits are located in a shared memory and are potentially
accessed by multiple CPUs running dom0 and the guest VM. It appears
that a failure to synchronize changes to this shared memory leads to
race conditions resulting in the guest missing out on notifications.
|
|
|
|
|
|
|
|
In the Netfront case it appears that by having scheduler decide when
to run the workload we don't need to involve additional mechanisms
to artificially limit resource availability to achieve better
performance under heavy load. On the contrary, by performing a
single pass through Rx and Tx completion rings and having scheduler
decide when to run the next attempt, we limit the amount of time
spent in the packet processing and achieve system responsiveness.
|
|
Handling receive and transmit for multiple networking interfaces
in a "shared interrupt" within normal interrupt vector code path
introduces too much delay from the hypervisor POV which prevents
it from injecting further completion event interrupts for Rx and
Tx queues.
Additionally, Netfront backend driver includes a mechanism to
detect Rx ring stalls and "turn the carrier off" when the guest
is not replenishing the ring (e.g. due to missing completion
interrupts) that relies on guest waking up periodically and making
sure that the Rx ring completion handling is progressing.
Having tried both task queue + timeout and interrupts + timeout
approaches, it appears that using the task queue is more flexible
and provides superior performance under heavy network load.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ok mikeb@
|
|
|
|
Network VSC is an RNDIS device using NVSP protocol to communicate
with the Hyper-V VMBus via VMBus channels and/or shared memory. The
code was ported from FreeBSD with some API changes and simplifications.
While the Rx path is nearly complete, packet transmition is not
implemented yet.
ok deraadt, mlarkin
|
|
ok mikeb@
|
|
ok mikeb@
|
|
ok mlarkin, deraadt
|
|
ok reyk (a while ago)
|
|
We use an atomic CMPXCHG on first 32 bits of the grant table entry
when revoking access to the memory page. Target domain ID field is
part of these 32 bits, thus shouldn't be masked out for comparison.
This appears to be the last piece of the QubesOS VM chaining puzzle;
tested by Marco Peereboom, thanks!
|
|
This is another piece of the QubesOS "chained VM" puzzle reported by
Marco Peereboom.
|
|
Extend xen_grant_table_enter to take an additional "domain" argument
and extract it from the upper part of the bus_dmamap_load flags (sigh.)
to be able to punch it into the grant table entry.
Issue reported by Marco Peereboom who found that we wouldn't run under
QubesOS that "chains" VMs. He also did the hard work getting the debug
data out of the aforementioned system.
|
|
and pick it up in xnf(4) and print it in the dmesg line for now. We'll
need to pass it down to the Grant Table code.
|
|
is the same for both virtual and physical addresses.
|
|
|
|
Otherwise proc.h & friends pick it up before we manage to perform
our MULTIPROCESSOR dance. This time I've made sure we get LOCK
prefixes with an objdump. Bug reported by Evgeniy Sudyr, thanks!
|
|
Follow FreeBSD and schedule the next Tx completion event to fire
when about half of the packet segments scheduled for transmission
are consumed.
|
|
|
|
|
|
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@
|
|
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.
|
|
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@
|