Windows POC

CONNECTIVITY_TESTING.md

@@ -0,0 +1,204 @@
+# VirtGPU Backend Service Connectivity Testing
+
+This document explains how to test connectivity between WSL and the Windows VirtGPU Backend Service.
+
+## Overview
+
+The VirtGPU Backend Service runs on Windows (port 4660) and needs to be accessible from WSL2 environments. Two test scripts are provided to verify connectivity and troubleshoot issues.
+
+## Test Scripts
+
+### 1. Windows Firewall Test (`test-windows-firewall.ps1`)
+
+**Run this on the Windows host** to check firewall configuration and service status.
+
+```powershell
+# Basic test
+.\test-windows-firewall.ps1
+
+# Test specific port
+.\test-windows-firewall.ps1 -Port 4661
+
+# Automatically fix firewall rules (run as Administrator)
+.\test-windows-firewall.ps1 -Fix
+```
+
+**What it checks:**
+- ✅ Service is running
+- ✅ Port is listening
+- ✅ Windows Firewall rules
+- ✅ Local connectivity
+- ✅ Network profile settings
+
+### 2. WSL Connectivity Test (`test-wsl-connectivity.sh`)
+
+**Run this from WSL** to test connectivity to the Windows host.
+
+```bash
+# Auto-detect Windows host IP and test
+./test-wsl-connectivity.sh
+
+# Test specific Windows host IP
+./test-wsl-connectivity.sh 192.168.1.100
+```
+
+**What it checks:**
+- ✅ Windows host reachability
+- ✅ Port 4660 accessibility
+- ✅ Shared memory directory (`/mnt/c/temp`)
+- ✅ Basic service API communication
+
+## Common Issues and Solutions
+
+### Issue: Port 4660 Access Denied (Error 10048)
+
+**Cause:** Another service is already using port 4660
+
+**Solution:**
+```powershell
+# Check what's using the port
+netstat -ano | findstr :4660
+
+# Kill the process if needed
+tasklist /FI "PID eq <process_id>"
+taskkill /F /PID <process_id>
+```
+
+### Issue: WSL Cannot Connect to Windows Host
+
+**Cause:** Windows Firewall blocking connections
+
+**Solution:**
+```powershell
+# Run as Administrator to fix firewall
+.\test-windows-firewall.ps1 -Fix
+
+# Or manually create rule
+New-NetFirewallRule -DisplayName "VirtGPU Backend Service" -Direction Inbound -Protocol TCP -LocalPort 4660 -Action Allow
+```
+
+### Issue: Network Profile is Public
+
+**Cause:** Windows network set to Public (more restrictive)
+
+**Solution:**
+1. Go to Settings > Network & Internet
+2. Select your network connection (Ethernet/WiFi)
+3. Change Network profile to "Private"
+
+### Issue: Shared Memory Directory Not Accessible
+
+**Cause:** WSL cannot access Windows `C:\temp` directory
+
+**Solution:**
+```cmd
+# Create directory on Windows
+mkdir C:\temp
+
+# Test from WSL
+ls -la /mnt/c/temp
+echo "test" > /mnt/c/temp/test.txt
+```
+
+## Testing Workflow
+
+1. **Start the Windows service:**
+   ```powershell
+   .\VirtGPUWindowsBackend.exe console
+   ```
+
+2. **Test Windows-side configuration:**
+   ```powershell
+   .\test-windows-firewall.ps1
+   ```
+
+3. **Test from WSL:**
+   ```bash
+   ./test-wsl-connectivity.sh
+   ```
+
+4. **Fix issues as needed:**
+   ```powershell
+   # Fix firewall (run as Administrator)
+   .\test-windows-firewall.ps1 -Fix
+   ```
+
+5. **Verify end-to-end connectivity:**
+   ```bash
+   # From WSL - should work after fixes
+   ./test-wsl-connectivity.sh
+   ```
+
+## Expected Output
+
+### Successful Windows Test:
+```
+=== Windows Firewall Test for VirtGPU Backend Service ===
+
+1. Checking if VirtGPU Backend Service is running...
+   [PASS] Service process found: VirtGPUWindowsBackend (PID: 1234)
+
+2. Checking if port 4660 is listening...
+   [PASS] Port 4660 is listening (PID: 1234)
+
+3. Checking Windows Firewall rules for port 4660...
+   [INFO] Found firewall rules for port 4660
+
+4. Testing local connectivity to port 4660...
+   [PASS] Can connect to localhost:4660
+
+[SUCCESS] VirtGPU Backend Service appears to be running correctly
+```
+
+### Successful WSL Test:
+```
+=== WSL to Windows VirtGPU Backend Connectivity Test ===
+
+1. Detecting Windows host IP from WSL...
+   [INFO] Windows host IP detected: 192.168.1.100
+
+2. Testing basic connectivity to Windows host...
+   [PASS] Windows host is reachable via ping
+
+3. Testing TCP connection to port 4660...
+   [PASS] Port 4660 is open and accessible
+
+4. Testing shared memory directory access...
+   [PASS] Shared directory /mnt/c/temp exists
+   [PASS] Can write to shared directory
+
+5. Testing VirtGPU service communication...
+   [PASS] Service responds correctly to JSON API calls
+
+[SUCCESS] VirtGPU Windows Backend Service is accessible from WSL
+          WSL clients can connect to: 192.168.1.100:4660
+```
+
+## Manual Testing Commands
+
+### Windows (Command Prompt):
+```cmd
+# Test local connection
+telnet localhost 4660
+
+# Check listening ports
+netstat -ano | findstr :4660
+
+# Check firewall rules
+netsh advfirewall firewall show rule name="VirtGPU Backend Service"
+```
+
+### WSL (Bash):
+```bash
+# Get Windows host IP
+ip route show | grep default | awk '{print $3}'
+
+# Test TCP connection
+nc -z <windows_host_ip> 4660
+
+# Test with timeout
+timeout 5 nc -z <windows_host_ip> 4660 && echo "Connected" || echo "Failed"
+
+# Manual telnet test
+telnet <windows_host_ip> 4660
+```

ggml/src/ggml-virtgpu/BACKEND_NAMING.md

@@ -0,0 +1,163 @@
+# ✅ Backend Naming & Structure
+
+## 🏷️ **New File Organization**
+
+Following the user's request to make the backend naming more descriptive, we've reorganized the files to clearly reflect their purpose:
+
+### **Linux Backend: `virtgpu.c/h`**
+- **Purpose**: Linux DRM VirtGPU implementation
+- **Transport**: Direct Linux DRM kernel interface
+- **Files**:
+  - `virtgpu.c` - Linux backend implementation
+  - `virtgpu.h` - Linux backend header and data structures
+
+### **Windows Backend: `winApiRmt.c/h`**
+- **Purpose**: Windows API Remoting implementation
+- **Transport**: TCP + JSON protocol over shared memory
+- **Files**:
+  - `winApiRmt.c` - Windows backend implementation
+  - `winApiRmt.h` - Windows backend header and data structures
+
+### **Common Infrastructure**
+- `virtgpu-interface.h` - Common interface that both backends implement
+- `virtgpu-common.cpp` - Dispatch layer that routes calls to backends
+- `apir-minimal.h` - Minimal APIR encoder/decoder functions
+
+## 📂 **File Structure Overview**
+
+```
+ggml-virtgpu/
+├── Core Interface
+│   ├── virtgpu-interface.h    # Common backend interface
+│   ├── virtgpu-common.cpp     # Dispatch implementation
+│   └── apir-minimal.h         # APIR encoder/decoder
+│
+├── Linux Backend (virtgpu)
+│   ├── virtgpu.c              # Linux DRM implementation
+│   └── virtgpu.h              # Linux structures & constants
+│
+├── Windows Backend (winApiRmt)
+│   ├── winApiRmt.c            # Windows client implementation
+│   ├── winApiRmt.h            # Windows structures & constants
+│   └── ggml-winapi-client.c   # Standalone Windows client
+│
+├── Testing & Documentation
+│   ├── test-backend-refactor.cpp
+│   ├── BACKEND_REFACTORING.md
+│   └── BACKEND_NAMING.md (this file)
+│
+└── Legacy (for migration reference)
+    ├── virtgpu.cpp            # Original mixed implementation
+    └── virtgpu-linux-original.cpp
+```
+
+## 🎯 **Naming Rationale**
+
+### **`virtgpu.c/h` (Linux)**
+- ✅ **Clear**: Immediately identifies as the original VirtGPU implementation
+- ✅ **Historical**: Matches the Linux DRM subsystem naming
+- ✅ **Concise**: Short and well-known in the VirtGPU community
+- ✅ **Descriptive**: Directly relates to Linux VirtGPU drivers
+
+### **`winApiRmt.c/h` (Windows)**
+- ✅ **Descriptive**: Clearly indicates Windows API Remoting
+- ✅ **Distinct**: Different from Linux, avoiding confusion
+- ✅ **Accurate**: Reflects the actual transport mechanism
+- ✅ **Expandable**: Can accommodate future Windows transport variations
+
+## 🔧 **Backend Interface**
+
+Both backends implement the same interface defined in `virtgpu-interface.h`:
+
+```cpp
+typedef struct {
+    const char* name;
+
+    /* Lifecycle */
+    virtgpu* (*create)(void);
+    void (*destroy)(virtgpu* gpu);
+
+    /* Core APIR functions */
+    apir_encoder* (*remote_call_prepare)(...);
+    uint32_t (*remote_call)(...);
+    void (*remote_call_finish)(...);
+
+    /* Shared memory operations */
+    int (*shmem_create)(...);
+    void (*shmem_destroy)(...);
+    void* (*shmem_get_ptr)(...);
+} virtgpu_backend_ops;
+```
+
+## 📋 **Backend Registration**
+
+Each backend provides a registration function:
+
+```cpp
+/* From virtgpu.h */
+const virtgpu_backend_ops* virtgpu_backend_linux_drm_get_ops(void);
+
+/* From winApiRmt.h */
+const virtgpu_backend_ops* virtgpu_backend_windows_winapi_get_ops(void);
+```
+
+## 🚀 **Usage Examples**
+
+### **Explicit Backend Selection:**
+```cpp
+#include "virtgpu-interface.h"
+
+// Use Windows API Remoting
+virtgpu* gpu = virtgpu_create_with_backend(VIRTGPU_BACKEND_WINDOWS_WINAPI);
+
+// Use Linux DRM VirtGPU
+virtgpu* gpu = virtgpu_create_with_backend(VIRTGPU_BACKEND_LINUX_DRM);
+```
+
+### **Auto-Detection (Default):**
+```cpp
+// Uses platform-appropriate backend automatically
+virtgpu* gpu = create_virtgpu();
+```
+
+### **Direct Backend Access:**
+```cpp
+#include "winApiRmt.h"
+#include "virtgpu.h"
+
+// Get specific backend operations
+const virtgpu_backend_ops* win_ops = virtgpu_backend_windows_winapi_get_ops();
+const virtgpu_backend_ops* linux_ops = virtgpu_backend_linux_drm_get_ops();
+```
+
+## ✅ **Benefits of New Naming**
+
+1. **Clarity** - File names immediately indicate purpose
+2. **Separation** - Clear boundaries between Linux and Windows code
+3. **Maintenance** - Easy to locate backend-specific issues
+4. **Documentation** - Self-documenting file organization
+5. **Development** - Teams can work on backends independently
+
+## 📊 **Implementation Status**
+
+| Backend | Implementation | Header | Registration | Status |
+|---------|---------------|---------|-------------|---------|
+| **Linux (virtgpu)** | `virtgpu.c` | `virtgpu.h` | ✅ Ready | ⚠️ Stub |
+| **Windows (winApiRmt)** | `winApiRmt.c` | `winApiRmt.h` | ✅ Complete | ✅ Complete |
+| **Common Interface** | `virtgpu-common.cpp` | `virtgpu-interface.h` | ✅ Complete | ✅ Ready |
+
+## 🔄 **Migration Status**
+
+- ✅ **File Renaming**: Complete
+- ✅ **Header Structure**: Complete
+- ✅ **Interface Registration**: Complete
+- ✅ **Windows Implementation**: Complete
+- ⚠️ **Linux Implementation**: Ready for migration from original code
+- ✅ **Build System**: Updated in CMakeLists.txt
+- ✅ **Testing Framework**: Updated and ready
+
+## 🎉 **Result**
+
+**Perfect naming scheme that clearly distinguishes between the Linux VirtGPU implementation (`virtgpu.c/h`) and Windows API Remoting implementation (`winApiRmt.c/h`) while maintaining a clean common interface!**
+
+The refactored architecture is ready for development with clear, maintainable, and descriptive naming.