When driver installed, run viosocklib-test /i to register (install)
viosock protocol dll. Installation code will be moved to coinstaller or
tools installer helper library at the end of viosock development.
Signed-off-by: Ilya Rudakov <[email protected]>
If the port can't be open (probably opened by vdservice), go to
the next one.
Add ability to increase write buffer size and send
entire buffer filled by characters without getting data from the
console.
This helps testing corner cases of vioser.sys, for example:
configure additional test port port with tcp socket backend,
connect to it with 'nc', press ^Z to suspend the 'nc' and send
several large (512K) buffers.
At some point the write does not return immediately and closing
test application causes cancellation flow.
Another scenarion: if 1M buffer sent, the driver fails the operation
due to too large SG table.
Signed-off-by: Yuri Benditovich <[email protected]>
Handle VIRTIO_F_IOMMU_PLATFORM automatically in the library,
if suggested by the device. The drivers do not need to take
care on that in their code.
Signed-off-by: Yuri Benditovich <[email protected]>
Before this commit each WDF driver called VirtIOWdfSetDriverFeatures
from its PrepareHardware WDF callback. Many drivers do not have any
specific needs for features but needed to make this call in order
just to set VIRTIO_F_VERSION_1 and VIRTIO_F_ANY_LAYOUT properly.
So, even when the call VirtIOWdfSetDriverFeatures is optional in
general, it is mandatory to handle V1 devices.
Current commit moves ack for VIRTIO_F_VERSION_1 and VIRTIO_F_ANY_LAYOUT
features to WDF VirtIO library. If the driver does not call
VirtIOWdfSetDriverFeatures, these features are set properly at time of
queues' initialization. So, drivers need to make this call only if
they need to enable some type-spefific features or if they need to
disable some common features which WDF library handles automatically
(currently VIRTIO_F_VERSION_1, VIRTIO_F_ANY_LAYOUT).
Signed-off-by: Yuri Benditovich <[email protected]>
Command line application that can call RNG function of viorng
provider (or other provider) with different buffer sizes.
Signed-off-by: Yuri Benditovich <[email protected]>
Allocate 2 blocks of 4K. One will be sliced for input events
(8 bytes each, i.e. 512 events, when the queue size is usually 64).
Another one for sporadic output of keyboard reports, 16 bytes
allocated for each.
Signed-off-by: Yuri Benditovich <[email protected]>
The driver uses 2 blocks of 4K: one for MemStats, one for
sending PFN arrays to the host. Now we allocate both in
PrepareHardware and release them as group in ReleaseHardware.
Signed-off-by: Yuri Benditovich <[email protected]>
This is preparation patch for further patch making the driver
to work with VirtIO WDF DMA API. The driver allocates
all virt queues under WDF device lock (which is by default)
spinlock. The change making this lock to be fast mutex.
Signed-off-by: Yuri Benditovich <[email protected]>
The driver uses serialized IO requests (WdfIoQueueDispatchSequential)
so we need just one common buffer for single receive transaction.
We allocate this buffer of D0 entry and free on D0 exit.
Signed-off-by: Yuri Benditovich <[email protected]>
Currently the driver uses memory structure on the stack
as DMA buffer. To be compatible with IOMMU, we change it
to use common DMA buffer. On D0 entry the driver allocates
single 4K block and uses slices from it for control queue
commands. The entry is 8 bytes, so the buffer is enough
for 512 entries. The driver usually uses just one entry
as control commands do not happen often.
Signed-off-by: Yuri Benditovich <[email protected]>
Processing of Write request to ports uses Virtio DMA API
instead of GetPhysicalAddress.
The DMA transaction is built using a copy of write request
buffer. Unfortunately, we can't use original buffers of the
request to build the DMA transaction, as the cancellation
flow is problematic - we're not able to cancel the DMA
transaction in tx virtq. If we discard the transaction
in request cancellation flow, the device will still copy the
data using provided (invalidated) hardware addresses.
So, we pass the request's buffer to the DMA API and it makes
a copy of the data and provides SG list based on this copy.
In order to avoid very complicated flows we mark the request
as cancellable only after we successfully added the buffers.
If the request was cancelled in this very small window (from
the moment it was create to the moment we make it cancellable),
the driver will complet it immediately but the data will be
transmitted.
Signed-off-by: Yuri Benditovich <[email protected]>
Allocate input buffers (on D0Entry) using DMA API for both
main device and port devices, providing unique tag for group
deallocation of these buffers of D0Exit.
Signed-off-by: Yuri Benditovich <[email protected]>
Internally VirtIO-Wdf stops using MmAllocateContiguousMemory
and MmGetPhysical address, so when initializing and using
VirtIO queues, the WDF flawor of VirtIO library uses IOMMU-compatible
way of physical memory allocation and access. All the WDF drivers
still use old methods of obtaining physical addresses of blocks
for transmit and receive (i.e. allocating virtual memory and using
MmGetPhysicalAddress).
Signed-off-by: Yuri Benditovich <[email protected]>
Added and implemented APIs for proper DMA operations.
There are 3 mechanisms suitable for different kinds of
DMA operations:
1. Allocation of common buffers suitable for any kind
of DMA. Intended for allocation of contiguous memory.
Can be used on PASSIVE only. Good for RX queues with
large buffers. It is not recommended to use it with
sizes more than 8K as such blocks might be not available
during run-time.
2. Allocation of single common buffer with possibility to
allocate chunks of predefined size from it. The block
can be allocated only on PASSIVE, but chunks can be
allocated also on DISPATCH. Good for RX and TX queues
with very small buffers.
3. Mapping of existing buffer (from WDF request or not).
Suitable for TX where the source is WDF request, but
requires effort to integrate as the mapping might be
synchronous or asynchronous (does not depend on the
caller) and the callback when SG list is ready is
called on DISPATCH.
This is preparation patch.
Due to 'bLegacyMode' field and LEGACY_DMA_SUPPORTED define
the VirtIO works exactly the same way as before.
Signed-off-by: Yuri Benditovich <[email protected]>
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/413
When logical limits of an absolute device are not default (0..0x7fff),
the device, redirected over input-host, does not function at all
in Windows. Addition of physical limits definition makes it function.
Note that this does not solve completely the problem of touchpads
especially ones that report absolute coordinates like mice do:
they require more effort to function correctly.
Signed-off-by: Yuri Benditovich <[email protected]>
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/385
High resultion mouse often provides values out of range (-127,+127).
Unfortunately the interface of vioinput does not provide any
information about logical limits of relative pointer.
So, let's keep the value inside the range.
Signed-off-by: Yuri Benditovich <[email protected]>
Just a stub for further development. Build is ok, but without packaging
yet, a project set is defined (device driver, Windows Sockets service
provider interface (SPI) client for user mode apps, driver test app).
Device initialization is partially implemented, virtqueues are not
ready, you can only get the CID. The socket service provider client
implemented as a dll, it will handle requests from Windows Socket
subsystem, at the moment this is just a stub for building. Common
read/write requests will be used to communicate with the driver,
connection parameters will be defined with extended file attributes on
open.
Signed-off-by: Ilya Rudakov <[email protected]>
Do not update netkvmmof.h without need, check whether
generated header file is different from existing one,
only then update it.
Signed-off-by: Yuri Benditovich <[email protected]>
_tcsdup is a macro that eventually evaluates to _strdup or a similar
call, which uses malloc() to allocate the required memory. Such pointer
should be released using a call to free(), not operator delete.
Signed-off-by: Michał Janiszewski <[email protected]>
Yuri Benditovich