Removed support for RSC implemented in private qemu patch.
Now the driver supports RSC according to the virtio spec
and upstream qemu code. The RSC feature is supported for
V1 device and for legacy device as well.
Signed-off-by: Yuri Benditovich <[email protected]>
The macro ETH_COMPARE_NETWORK_ADDRESSES_EQ causes unaligned
access exception on ARM64. To solve this, we will use this
macro on non-ARM systems and on ARM64 systems will use
byte-by-byte comparison.
https://bugzilla.redhat.com/show_bug.cgi?id=1666940
Set clear and simple rule for assignment of vectors to queues
and translation of MSIX messages to queues:
in case of one or two vectors they are assigned
to TX/RX queues and CX reuses the last vector. In this case
we do not spawn DPC for CX and process it during regular
RX/TX processing. For case of 3 and more vectors the processing
is the same as before.
Signed-off-by: Yuri Benditovich <[email protected]>
WHCK requires adapter speed to be equal to maximal speed, so
it fails with default run of qemu.
In addition, it is easy to have meaningless speed report
with parameters provided in qemu command line, as there is
almost no validation of values received from the configuration.
Current commit sets following order of assignment and report:
At the beginning we set adapter speed as default=100 Gbps.
We do not assign invalid values from device configuration.
We always use the same value for reports of current speed
and of maximal speed.
Signed-off-by: Yuri Benditovich <[email protected]>
If power on procedure fails, it still must resume the
state machine, otherwise following pause flow never
completes.
Signed-off-by: Yuri Benditovich <[email protected]>
Now that in MSI interrupts we have a separate DPC for CX, we don't need
to check if an interrupt was reported or report an interrupt for any of
the paths as we already used this flag for CX only when MSI interrupts
are used.
For legacy interrupt we always set the report interrupt flag and then
clear it in CX handling, this work is superfluous as we always want to
check if CX has any work to do with legacy interrupts. Setting and
unsetting this flag constantly is a good example of race conditions that
might lead us to miss some interrupts for cx.
These race conditions were initially reported and discussed in the
following pull request:
https://github.com/virtio-win/kvm-guest-drivers-windows/pull/281
Signed-off-by: Sameeh Jubran <[email protected]>
This commit separates the CX path handeling to a standalone DPC, the
motive to do this is that sometimes we can miss Control interrupts due to
the way it is implemented today.
The issue is disscussed in great detail here:
https://github.com/virtio-win/kvm-guest-drivers-windows/pull/281
Signed-off-by: Sameeh Jubran <[email protected]>
The VIRTIO 1.0 spec adds the DEVICE_NEEDS_RESET bit to the device's
status. This commit enables the driver to respods appropriately to
RESET request by the device.
Upon receiving such notification from the device in the control queue we
do the following steps in the following order:
* On Control interrupt read the device status and check that
VIRTIO_CONFIG_S_NEEDS_RESET bit is set and VIRTIO 1.0 is supported.
* Update the state machine that the device needs a reset, the state
machine updates all queues using the obervee/oberver logic that they
can't touch the hardware.
* Lastly the flag bDeviceNeedsReset is set to true. By setting this flag
to true we inform Windows that the ParaNdis6_Reset should be called by
NDIS. This happens beacuse in ParaNdis6_CheckForHang we return the value
of the bDeviceNeedsReset flag which if set instructs Windows to call
reset function. The ParaNdis6_CheckForHang is called periodically by
NDIS every few seconds.
Signed-off-by: Sameeh Jubran <[email protected]>
Signed-off-by: Basil Salman <[email protected]>
In the CX DPC path we execute the GuestAnnounce feature without checking
if CX was actually acked. This commit adds this check.
Signed-off-by: Sameeh Jubran <[email protected]>
In commit e8f319fdc0 the lock free queue was
introduced as an alternative implementation to the previous one which
required acquiring the TX's path lock for NBLs sent by Windows. The
intention for the implementation introduced was that this lock acquirement
would be dropped in favour of scheduling a DPC upon sending an NBL instead.
While this DPC scheduling approach works it does introduce a heavy DPC
scheduling on the environment, the overhead can be as high as executing a
DPC for each NBL sent by Windows in the worst case scenario. In general
Windows should drop duplicate DPCs but it seems that it is not doing so
efficiently or else it is executing a DPC upon each schedule request by us
in a heavy load environment.
An alternative implementation which would probably allow us to keep the
DPC scheduling implementation is adding a mechanism to identify bursts and
forecast when we are receiving a high packet rate and adapt (lower) the
DPC scheduling accordingly.
This commit enables the HCK/HLK 1c_Mini6PerfSend test to pass as it was
stuck due to this heavy DPC load environment.
Signed-off-by: Sameeh Jubran <[email protected]>
VIRTIO_NET_F_STATUS off misbehaviours fixed:
1. Reading the current link state,
fix: ReadLinkState is not to be called in this case.
2. Link state is not initialized,
fix: pContext->bConnected initialized to TRUE.
Signed-off-by: Bishara AbuHattoum <[email protected]>
Background: https://issues.oasis-open.org/browse/VIRTIO-154
According to MS documentation to ensure the usage of IOMMU DMA memory API
should be used. NetKVM driver already uses DMA API for memory allocation
related to data transfer. VIRTIO_F_IOMMU_PLATFORM will be enabled for
Windows 10 and Windows Server 2016
Signed-off-by: Yan Vugenfirer <[email protected]>
Changes following the introduction of virtio's flag, VIRTIO_NET_F_SPEED_DUPLEX,
which allows the host to set the LinkSpeed/Duplex values.
Up until this stage the configurations of LinkSpeed/Duplex used were hardcoded,
with default LinkSpeed=10Gbits/s, Duplex=full.
But uppon the introduction of VIRTIO_NET_F_SPEED_DUPLEX, it'll be more useful to
import them from the host and apply them if the VIRTIO_NET_F_SPEED_DUPLEX is on,
or, use the default configurations if it is off:
(LinkSpeed=10Gbits/s, Duplex=full).
Changes also includes removing the ConnectRate parameter from the inf file as we
never saw that it was used.
Qemu patches:
1. [v4,2/3] qemu: virtio-net: use 64-bit values for feature flags:
https://patchwork.ozlabs.org/patch/856266/
2. [v4,3/3] qemu: add linkspeed and duplex settings to virtio-net:
https://patchwork.ozlabs.org/patch/856226/
Signed-off-by: Bishara AbuHattoum <[email protected]>
The bug was caused by a bug in the backend where the driver allocates more
than one hardqueue and doesn't enable all of the hardqueues which leads the
backend to crash.
When RSS is not enabled in compilation the driver enables one queue only
even though it allocates more. This commit drops MQ support when the
driver has RSS disabled which prevents these unnecessary allocations.
Signed-off-by: jackli <[email protected]>
Signed-off-by: Sameeh Jubran <[email protected]>
virtio 1.0 device
In virtio 1.0 MAC address in virtio configuration space is read-only. For
virtio 1.0 device, If VIRTIO_NET_F_CTRL_MAC_ADDR flag is disabled (setting
MAC address using control queue), the driver shouldn't attempt to use
configuration space to set MAC address.
Signed-off-by: Yan Vugenfirer <[email protected]>
configuration is attempted
VIRTIO_NET_F_CTRL_MAC_ADDR feature depends on control queue availability.
Before the fix control queue was acked after MAC address was initialized.
The behaviour caused the driver to always use MAC configuration through
virtio configuration space (VIRTIO_NET_F_MAC).
Signed-off-by: Yan Vugenfirer <[email protected]>
This bug caused by historical refactoring done in
ParaNdis_InitializeContext function. If PCI resource initialization failed
driver should not continue execution of ParaNdis_InitializeContext
function.
Signed-off-by: Yan Vugenfirer <[email protected]>
This commit integrates wpp tracing into builds higher than Vista as
Windows Vista requires much more configuration for wpp integration,
however, this integration may be introduced in the future.
The old style of Dprintf is still preserved by this commit and can be
enabled by disabling WPP tracing. This can be accomplished by commenting
the following line in WPPTrace.h:
Signed-off-by: Sameeh Jubran <[email protected]>
The function has no effect and will be removed.
Also deleting the defunct "PublishIndices" config entry.
Signed-off-by: Ladi Prosek <[email protected]>
Currently when there are two msi vectors assigned to the device the driver
doesn't run. This bug occured because of the "round towards zero" behaviour of
division in C/C++.
Signed-off-by: Sameeh Jubran <[email protected]>
Regression from commit 976828bd46,
earlier each received packet was tested with recheck of packet
protocol after stripping VLAN tags.
When the result of checksum check has random value, the driver
can erroneously report packet as one with invalid checksum.
If due to some reason the packet was not recognized by the driver
as IP one, it shall report the checksum as not tested.
Signed-off-by: Yuri Benditovich <[email protected]>
The new virtio-net spec introduces a new MAX MTU configuration field to
the device's configuration area. It is used to pass a maximum MTU
from the device to the driver.
Signed-off-by: Sameeh Jubran <[email protected]>
The default value for virtioDebugLevel is 0, it is set to a user defined
level in the function "ReadNicConfiguration". The virtioDebugLevel is set
only after we call to the function "GetConfigurationEntry" several times,
which means that on any debug level other than 0 this print won't be shown.
Signed-off-by: Sameeh Jubran <[email protected]>
This reverts commit 38a60b81d8.
This print is not needed as the VlanId's Maximal value (ulMaximal) is checked
in the function GetConfigurationEntry and a suitable debug message is printed
at the end of the function. The Maximal (ulMaximal) value is initialized to
MAX_VLAN_ID when we initialize the defaultConfiguration array.
Yuri Benditovich