Paul Durrant [Mon, 6 Aug 2018 12:11:39 +0000 (13:11 +0100)]
Don't bump the receiver event counter if the poller is going to retry
There is little point in bumping rsp_event (to trigger a new event from
the backend) if the poller is going to retry, so we can save modifying the
shared ring in this case.
This patch also adds extra debug code to the poller to make sure it never
exits from the main loop until either there are no retries pending or
the instance has been disabled.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
CL emits a warning about every place that will get spectre mitigation
when compiled with /Qspectre. Even if this option is already used. This
breaks the build if warnings are treated as errors.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Also disable the same warning in the co-installer build.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Ben Chalmers [Tue, 10 Jul 2018 10:09:59 +0000 (11:09 +0100)]
Replace uses of MmAllocatePagesForMdlEx in __AllocatePage
Windows appears to have an edge case bug in which zeroing
memory using MmAllocatePAgesForMdlEx (which in Win 10 1803
happens even if you specify MM_DONT_ZERO_ALLOCATION) can cause
a BSOD 139 1e.
This commit uses MmAllocateContinguousMemorySpecifyCache
to allocate memory instead, then builds and Mdl to wrap
it up.
__AllocatePages is left unchanged (as we don't want
to allocate multiple contiguous pages). This issue
has not been seen outside of xenvif calls to
__AllocatePage and we expect a fix to the underlying
Windows problem in the near future
Chris Patterson [Wed, 21 Feb 2018 09:54:57 +0000 (09:54 +0000)]
poller: fix event channels when backends do not support multi-queue
The event channels for rx & tx are written to a multi-queue formatted
path even when multiple queues are not supported. This results in a hung
VM with the following logs:
XENBUS|EvtchnWait: TIMED OUT: Count = 00000001 Channel->Count = 00000000
...
This can be reproduced by having a Linux VM network backend with 1 vCPU.
If FrontendGetNumQueues() is 1 and multiple queues are not supported,
the following paths are used for the poller event channel:
device/vif/1/queue-0/event-channel-[rx|tx]
However, the proper xenstore path in this case is:
device/vif/1/event-channel-[rx|tx]
PollerInstanceInitialize() sets its path using FrontendFormatPath(),
which assumes a multi-queue path layout. This is done in a fashion
similar to the transmitter and receiver rings. However, the tx/rx rings
check for the mutually supported number of queues to determine the
actual path written to xenstore, using FrontendGetNumQueues(). See
__TransmitterRingStoreWrite() and __ReceiverRingStoreWrite(). This patch
adds a similar procedure for the poller to write to the appropriate path
in xenstore.
Paul Durrant [Fri, 26 Jan 2018 15:08:15 +0000 (15:08 +0000)]
Don't use KTIMERs in receive path
They appear to always defer by at least one timer tick, which is about 16ms
by default... just too long.
Instead, to avoid DPC watchdog issues in the MPE_Ethernet test, use a
threaded DPC. This is a real-time thread that can be pre-empted by normal
DPCs but not by standard system threads.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 24 Jan 2018 14:40:53 +0000 (14:40 +0000)]
Fix NDISTest6.5 CheckConnectivity and others
Commit e5e64b57 "Don't try to __FreePages() with local copy of MDL"
introduced subtle breakage into the receive path.
Prior to this patch, for the MDLs embedded in receiver packets, it was
always true that Mdl->MappedSystemVa == Mdl->StartVa + Mdl->ByteOffset.
However, after the commit, Mdl->StartVa was left as NULL in the assumption
that Mdl->MappedSystemVa would always be used to access the buffer. Sadly
this appears not to always be the case and in fact, wdm.h carries this
comment:
// Notice that while in the context of the subject thread, the base virtual
// address of a buffer mapped by an MDL may be referenced using the
// following:
//
// Mdl->StartVa | Mdl->ByteOffset
//
So the the previous setting of StartVa is indeed documented, and clearly
something in the network tests is relying on it.
This patch modifies the MDL allocator code in util.h to alwasy set StartVa,
and modifies the receiver code to carry this field forward into the
embedded MDLs. It also removes some code duplication in ReceiverPacketCtor()
and __ReceiverRingPutPacket().
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Fri, 20 Oct 2017 17:14:28 +0000 (18:14 +0100)]
Make use of possible XENBUS_EVTCHN Unmask failure
Bump up to the latest version of XENBUS_EVTCHN and specify the option
to Unmask that allows it to fail. In this circumstance it is possible to
avoid dropping out of the DPC and thus avoid a context switch and re-queue.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 18 Oct 2017 14:02:52 +0000 (15:02 +0100)]
Move the Receiver and Transmitter event and DPC processing...
...into the new Poller sub-system.
For efficiency it is desirable to have a single DPC handle both Receiver
and Transmitter polling, even if there are separate event channels for
the shared rings.
This patch moves all the basic event and DPC code into the Poller
subsystem, which calls back into the Transmitter and Receiver sub-systems
(to poll the shared rings) from its single per-CPU DPC.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Mon, 16 Oct 2017 10:20:17 +0000 (11:20 +0100)]
Add the boilerplate for a new Poller sub-system
The intention is that the separate Receiver and Transmitter event and DPC
handling be combined into a single sub-system. This patch lays the ground-
work for that to be done.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Mon, 8 May 2017 16:10:48 +0000 (17:10 +0100)]
Reboot request keys should be volatile
When a driver makes a reboot request it should use a volatile registry key.
The monitor service will explicitly remove the key prior to reboot but,
if the reboot is initiated in some other way and the key is non-volatile,
the monitor service will then needlessly prompt for a second reboot.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Tue, 10 Jan 2017 16:53:08 +0000 (16:53 +0000)]
Don't use Packet->Offset when stripping VLAN tags
The WHQL tests have always been buggy when dealing with packet data that
is offset into the NET_BUFFER MDL chain. Instead, adjust the MappedSystemVa
of the initial MDL.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Tue, 10 Jan 2017 10:29:53 +0000 (10:29 +0000)]
Don't try to __FreePages() with local copy of MDL
The XENVIF_RECEIVER_PACKET structure contains an embedded MDL so that
multi-fragment packets can be properly chained together. However this
structure should not be passed to __FreePages() as:
a) It appears to create problems with system PTE tracking
b) It results in memory corruption now that __FreePages() calls
ExFreePool()
This patch therefore extends the packet structure with a pointer to the
original system MDL such that it can be passed to __FreePages() when the
packet destructor is called.
The patch also bypasses some calls to MmGetSystemAddressForMdlSafe() since
we can ASSERT that the MDL is already mapped to a system address.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 15 Dec 2016 14:00:42 +0000 (14:00 +0000)]
Remove unnecessary complexity from the controller frontend
The controller ring is driven much like the store ring in XENBUS for
request/response but, unlike the store ring, there are no asynchronous
events (like watches) so we really don't need a DPC and an asynchronous
poll, or a watchdog.
This patch removes that code, and also shortens the poll timeout when
waiting for a response since use of XENBUS_EVTCHN(...Wait...) is
inherently racey.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 14 Dec 2016 15:52:52 +0000 (15:52 +0000)]
Fixes for VS2015/WDK10 build
The package build was not working correctly and caused the overall build
to fail.
At least part of the reason for this is that Microsoft, in their infinite
wisdom, have removed the DIFx redist from WDK10. This patch makes use of
a new environment variable 'DPINST_REDIST' to find the copy of dpinst.exe
to package such that this can be pointed at an older WDK or alternative
location where dpinst.exe can be found.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Mon, 12 Dec 2016 16:31:50 +0000 (16:31 +0000)]
Add support for building under VS2015/WDK10
Moving to the new toolchain also threw up a few new warnings, which this
patch either fixes or squashes. Also, SDV appears to be fragile in new
ways (and whinge about some new things) so there are fixes for that too.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Mon, 7 Nov 2016 11:35:09 +0000 (11:35 +0000)]
Provide registry override for disabling RSS
For diagnostic purposes it is useful to be able to simulate the situation
where XENVIF does not support RSS (because the backend does not support
it).
This patch adds code to check a REG_DWORD value called
'FrontendDisableToeplitz' and will not allow the Toeplitz hash algorithm
to be configured if the value is non-zero. This prevents XENNET from
advertizing the RSS capability to the network stack.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Fri, 4 Nov 2016 16:15:09 +0000 (16:15 +0000)]
Add more diagnostic messages
Log a message at start and end of both transmitter and receiver
ring enable and disable functions. Testing has thrown up some hangs
that appear to be in one of these functions.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Fri, 4 Nov 2016 15:13:25 +0000 (15:13 +0000)]
Add registry override to disable multicast control
The patch adds a registry parameter 'TransmitterDisableMulticastControl'.
This is a REG_DWORD which, if set to a non-zero value, will prevent
XENVIF from using the dynamic-multicast-control feature of the backend.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Fri, 4 Nov 2016 10:51:54 +0000 (10:51 +0000)]
Always select queue using the packet hash algorithm
There may be a mismatch between the configured receive hash algorithm
and the actual algorithm present in a transmit-side packet.
E.g. Toeplitz may be configured but a transmitted packet may have no
hash information.
It makes no sense to use a hash mapping table configured for a Toeplitz
hash if the packet hash is not Toeplitz, therefore the code should pass
the actual packet hash algorithm into the FrontendGetQueue(). This patch
makes the that change.
Suggested-by: Owen Smith <owen.smith@citrite.net>
This patch also makes sure we cannot attempt to indirect through a zero-
sized mapping table (thereby incurring a divide-by-zero exception).
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 3 Nov 2016 09:48:23 +0000 (09:48 +0000)]
Change where transmitter packet cache is created
The transmitter packet cache suffers from a similar issue as the
receiver packet cache did before commit 0dda5aa8 "Partially revert
commit ab655bb1...". If the VM goes through a suspend/resume cycle
with queued transmits then the cache would be torn down before all
objects had been freed, leading to ASSERTion failures in checked
builds and memory corruption in free builds.
This patch moves creation of the packet cache from the 'connect'
phase to the 'initialization' phase to avoid this problem.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 2 Nov 2016 12:02:37 +0000 (12:02 +0000)]
Log how many packets are aborted
When the transmitter rings are shut down, packets in the queues are
aborted. This patch adds a log line saying how many packets were
aborted in each queue.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 2 Nov 2016 11:51:54 +0000 (11:51 +0000)]
Add an extra transmitter ring poll
If we are trying to post fragments into the ring and find it full then
do a single poll to try to free up the space, rather than bailing and
waiting for the DPC to run.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Not all interfaces need to be released (since they don't all depend on
Xen) and crucially the receiver packet caches CANNOT be destroyed (and
hence the CACHE interface CANNOT be released) because there may be packets
outstanding in the stack... not necessarily in an S4 transtion, but
across a suspend/resume (which involves the same frontend state
transitions).
This patch also increases the log level of a couple of messages
emitted during frontend state transtions from 'trace' to 'info'.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Mon, 3 Oct 2016 14:10:38 +0000 (15:10 +0100)]
Incorporate revision ids from staging-8.1
Since it should be possible to upgrade from an 8.1 version of XENVIF
to an 8.2 version, at least the release revision of the 8.1 version
(0x0800000A) should be present in the 8.2 revision table, otherwise
driver upgrade will be vetoed by the co-installer if an 8.1 XENNET
is bound.
This patch incorporates all missing 8.1 revision ids.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Owen Smith [Mon, 3 Oct 2016 12:03:37 +0000 (13:03 +0100)]
Avoid possible NULL pointer dereference
If the packet cache is exhausted and unable to allocate more items, fail
before attempting to use the pointer. Moves the check to after
attempting to get a packet cache item.
Signed-off-by: Owen Smith <owen.smith@citrix.com>
Slight re-structuring of the error check.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Ben Chalmers [Wed, 28 Sep 2016 15:05:34 +0000 (16:05 +0100)]
Remove watchdog affinitisation on Windows 2008
Despite the presence of a compatability library, the
Windows 2008 calls to affinitise the watchdog thread
to a particular processor group are leading to lockups.
So detect if we are running on a version prior to
Windows 7 (or 2008 R2), and don't try to affinitise if
we are.
Signed-off-by: Ben Chalmers <ben.chalmers@citrix.com>
Paul Durrant [Wed, 21 Sep 2016 12:46:14 +0000 (13:46 +0100)]
Fix a couple of issues picked up by Windows 10 verifier
- It's possible for MmAllocatePagesForMdlEx() not to satisfy the
full allocation request, but not fail. Thus AllocatePage() should
check that the completed allocation actually matches what it
asks for.
- RegistryCreateKey() has a memory leak.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
The ASSERTion fix in this commit was wrong and lead to NIC unplugs being
missed. This fix simply makes sure the PDO flag is set to FALSE to
avoid tripping over the zero-memory ASSERTion later on in PdoDestroy().
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Owen Smith [Tue, 20 Sep 2016 17:06:14 +0000 (18:06 +0100)]
Step through hardware revision list in reverse order
Windows treats the HardwareID list as a decending order of specialization
where the first entry is the most specific, and last entry is least
specific. This can lead to install issues when the newer driver has a
less-specific HardwareID, as the older ("more-specific") HardwareID is
used for the match. Reordering the HardwareID list, so that the newest
revision is first, will stop Windows selecting the wrong driver package
to install.
Signed-off-by: Owen Smith <owen.smith@citrix.com>
Re-factored slightly for code consistency.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Tue, 20 Sep 2016 16:43:27 +0000 (17:43 +0100)]
Add statistics for checksum validation
For the transmit side this also entails added code to perform checksum
validation. However, since this may affect performance, validation is
only performed if the registry parameter TransmitterValidateChecksums
(REG_DWORD) is present and set a non-zero value.
Since the index values of the statistics used by XENNET are left
unchanged by this patch, there is no need to bump the XENVIF_VIF
interface version.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Tue, 20 Sep 2016 13:15:06 +0000 (14:15 +0100)]
Pass the receive queue index to XENNET
Update the XENVIF_VIF interface to version 8 to include an extra 'Index'
parameter to the XENVIF_RECEIVER_QUEUE_PACKET callback. This means
XENNET no longer has to use current CPU to decide which queue is which.
This patch also fixes a couple of ASSERTion failures seen in debugging.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 8 Sep 2016 10:09:17 +0000 (11:09 +0100)]
Don't restore settings from emulated device more than once
If, for some reason, the VM boots with emulated networking then network
settings will be saved from the emulated network device. Then, when the
VM reboots with PV networking, those settings are restored to the PV
network device regardless of whether it was freshly installed or has
been around for some time.
This patch makes sure that settings are restored only to a freshly
installed PV device.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 7 Sep 2016 15:25:52 +0000 (16:25 +0100)]
Revert all settings stealing patches
Windows has completely defeated me. There appears to be no way to
duplicate the stack binding of the emulated device without that binding
being removed if XENNET is un-installed, despite clearing all the
relevant registry keys in the DIF_REMOVE pre-process phase.
So, this patch reverts the code back to using the settings copy
mechanism employed in the 8.1 source.
Paul Durrant [Mon, 15 Aug 2016 13:06:30 +0000 (14:06 +0100)]
Add batching support
If a NET_BUFFER_LIST comprising multiple NET_BUFFERs is handled by XENNET
then this will result in multiple calls to VifTransmitterQueuePacket().
There is no need to attempt to process the transmit queue after every single
one of these calls, it suffices to just do it after the last of them. Hence
this patch adds an extra argument such that XENNET can notify XENVIF when
the last call of a batch is made.
Similarly on the receive side, it is useful notify XENNET when the last of
a batch of calls to the XENVIF_RECEIVER_QUEUE_PACKET callback is made, since
XENNET can then batch received packet indications to the NDIS stack.
These changes are made in XENVIF_VIF_INTERACE version 7.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 11 Aug 2016 10:03:42 +0000 (11:03 +0100)]
Advertise MAC address information in the registry
Because XENNET's co-installer is again taking responsibility for messing
with network settings it needs to be able to figure out which VIF instance
corresponds to which emulated device, and the only way it can do that is
by MAC address.
This patch therefore restores the old 'Addresses' subkey under XENVIF's
service key and populates it with REG_SZ values named with PDO names and
containing hex encoded ':' separated MAC address octets.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 10 Aug 2016 12:51:22 +0000 (13:51 +0100)]
Remove settings code
Unfortunately, after extensive testing of different scenarios, it seems to
be impossible to properly steal and restore network stack bindings from
within the XENVIF driver. Windows has already sampled some of the values
we need to modify and thus we cannot successfully modify them.
It appears the only way we can successfully use settings from an emulated
device is to do what the settings code was attempting to do, but do it
in XENNET's co-installer during the pre-install and pre-removal phases.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Tue, 9 Aug 2016 13:01:19 +0000 (14:01 +0100)]
Use new monitor request key
The monitor service now uses a request key in registry under HKLM/SOFTWARE.
This patch modifies __DriverRequestReboot() to use the new key, which is
now set as a parameter by the INF file.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Mon, 8 Aug 2016 12:03:25 +0000 (13:03 +0100)]
Re-work identity stealing code
The change introduced by patch 04c391d9 "Replace copying network
settings with identity stealing" had a flaw...
If a PV device that aliases an emulated device is installed then it
will only steal linkage if that emulated device is operational at the
time. This works on initial driver install, but not if the PV network
device driver is removed and then re-installed without an interim
reboot (which would make the emulated device operational). Instead,
after re-installation, the PV device has a brand new stack binding and
thus any network settings changes that were previously made are
apparently lost.
To fix this problem, this patch breaks the process of stealing the
emulated device's stack binding into two phases:
1) Discovery: When the PV device driver is installed, if an aliasing
emulated device is operational, a DWORD value called "VIF" is
created under the emulated devices software key. The value is set
to the PV device instance.
2) Theft: When the PV device is being brought online, the registry is
checked to see if any network device has a software key containing
a "VIF" value that patches the PV device instance.
If such an entry is found then the stack binding is stolen from
that device. Since the "VIF" value is in the *emulated* device's
software key, it will not be removed if the PV device driver is
removed and re-installed and so the problem described above will
not occur.
Because this patch avoids stealing the emulated device's stack bindings
if it is actually operational (i.e. we're in phase 1) this results in the
class installer building a new set of stack bindings for the PV device
during initial installation.
These are then restored any time a PV device with a stolen stack binding
is offlined. So, when a PV device is offline there is no evidence that
any stack binding has been stolen and hence, during driver removal, there
is no risk of an emulated device's stack binding being torn down.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 28 Jul 2016 09:04:44 +0000 (10:04 +0100)]
Make sure the NICS unplug count does not run away
In a tight loop of network attach/detach it's possible for a mismatch in
the number of unplug requests and revocations to occur, leading to a
run-away unplug count.
This patch adjusts the location of the requests and revocations to make
sure this does not happen.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 28 Jul 2016 09:00:51 +0000 (10:00 +0100)]
Make sure we don't end up with duplicate PDOs
In a tight loop of network attach/detach it's possible to end up with
duplicate PDOs because, as soon as a PDO gets set to 'missing' a new one
with the same name can be created. This leads to races in accessing the
vif areas in xenstore and things can get very confused.
This patch makes sure that a new PDO cannot be created until a previous
incarnation is in the 'deleted' state, which means there will definitely
be no conflict in interactions with xenstore.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 27 Jul 2016 12:33:56 +0000 (13:33 +0100)]
Fix locking and teardown bugs in controller frontend
If the backend does not implement the control ring then the frontend will
eventually deadlock. Also, by inspection, the teardown code does not
release interfaces if the control ring was not present.
This patch fixes both issues.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 18 May 2016 15:23:51 +0000 (16:23 +0100)]
Avoid transmitting on the wrong CPU
The transmit and receive rings have DPCs and event channels affinitized
to a particular CPU. Thus, when XENNET queues a new packet at the
transmit side, make sure the packet is prepared and posted from the
CPU to which the DPC and event channel are bound to avoid lock contention.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Re-introduce mistakenly dropped frontend state logic...
...from commit c9b6e56e "Cope with unexpected initial backend states" to
handle a backend that is already connected (for cases where Windows is
booted via iSCSI).
Signed-off-by: Eytan Heidingsfeld <eytanh@gmail.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 7 Jan 2016 15:06:48 +0000 (15:06 +0000)]
Send transmit side hash value to the backend
Backends capable of supporting packet hashing on the guest receive side
are also capable of accepting hash values in an extra info fragment on
the guest transmit side. This patch adds code to construct and send the
extra info fragment if the packet metadata contains hash information and
the backend is able to process it.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Fri, 20 Nov 2015 16:56:49 +0000 (16:56 +0000)]
Add frontend code for the new netif control ring
My recent patches to Xen's netif.h specify a control ring that can be
used by a frontend driver to configure packet hashing and steering in
a backend.
This patch adds the necessary code to XENVIF to drive this new ring,
however the rest of the code to link this up to new VIF interface
functionality (so that it may be used by XENNET) is deferred to a
subsequent patch.
This patch also pulls in an updated EVTCHN interface from XENBUS and
corrects the PDO binding.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Fri, 6 May 2016 08:51:30 +0000 (09:51 +0100)]
Make sure transmitter DPC does not try to unmask non-existent evtchn
In the case where the backend does not support split event channels (one
for RX and one for TX) then the transmitter code in XENVIF does not open
the combined channel; it is handled by the receiver code. So, the
transmitter DPC should not make any attempt to unmask the event channel at
the end of processing.
This patch adds the necessary check for FrontendIsSplit before doing the
unmask and also removes an unnecessary check for FrontendIsSplit in the
transmitter ring enable function.
Paul Durrant [Wed, 2 Mar 2016 16:35:47 +0000 (16:35 +0000)]
Replace copying network settings with identity stealing
It is becoming increasingly hard to find all the places in the registry
that Windows uses to stash network settings and copy them from the
emulated NIC to the new PV device when it is first installed.
So, rather than fighting a losing battle, steal the identity of emulated
devices instead, The identity information is essentially contained in two
values stored in the 'software'registry key of a NIC (under Control/Class/
<NET GUID>): NetCfgInstanceId and the NET_LUID, made up of *IfType and
NetLuidIndex. By copying these values and the contents of the Linkage subkey
we can effectively impersonate the emulated NIC once it is unplugged after
reboot.
This patch amends the settings code accordingly and also does some tidying
in pdo.c and registry.c.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 30 Mar 2016 10:58:58 +0000 (11:58 +0100)]
BootFlags should be a parameter, not a subkey
A misplaced comma in the INF file means that BootFlags is being created as
a subkey under the service key with a default DWORD value, rather than a
DWORD value with the name 'BootFlags'.
This patch moves the comma and fixes the problem.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 23 Mar 2016 14:06:27 +0000 (14:06 +0000)]
Avoid ASSERTion failure on VIF plug
If the backend is not fast enough then it's possible that the frontend
code sees the backend in state Initialising rather than InitWait. This
causes an ASSERT to be hit.
This patch simply whitelists the Initialising state to avoid the problem.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Wed, 23 Mar 2016 11:50:35 +0000 (11:50 +0000)]
Prevent VIF from being incorrectly considered offline...
...one resume from suspend.
My previous reversion of 765b7a6a exposed the original reason the
reverted patch.
On resume from suspend, the backend will have been re-created by the
toolstack and hence the frontend detects it as being offline. This
causes the frontend to request ejection of the disk (thinking that
the reason for the backend going offline is because the VIF is being
unplugged).
This patch works around this problem by introducing an early suspend
callback to note that the frontend has actually gone offline, which
will prevent the ejection from being requested.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Tue, 22 Mar 2016 11:29:37 +0000 (11:29 +0000)]
Remove erroneous code to re-acquire backend path on resume
Commit 765b7a6a added code to release and re-acquire the backend
path (and domid) on resume from suspend. That code falsely
assumes that the frontend is not in a closed state at the time.
It's also not clear why it was added in the first place so
this patch removes it again, as it causes a BSOD when the
frontend is in the closed state.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Paul Durrant [Thu, 21 Jan 2016 09:23:27 +0000 (09:23 +0000)]
Dynamic multicast control
Only use the multicast control feature of the backend if it supported
"feature-dynamic-multicast-control" otherwise attempts to enable the 'all
multicast' filter level in XENVIF will have no effect and the NDISTest 6.5
MultiCast Address test will fail.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
projects / pvdrivers / win / xenvif.git / log