From nobody Fri May 31 04:03:25 2024 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vr8hm4S2Sz5M57G for ; Fri, 31 May 2024 04:07:20 +0000 (UTC) (envelope-from emil@etsalapatis.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vr8hm22FWz451H for ; Fri, 31 May 2024 04:07:20 +0000 (UTC) (envelope-from emil@etsalapatis.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2c19e6dc3dcso1325199a91.3 for ; Thu, 30 May 2024 21:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20230601.gappssmtp.com; s=20230601; t=1717128437; x=1717733237; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=X+DXyudVfE5WtO+8iYYlBDeaVut+4WojwSIhooh6fLg=; b=141AHBEGhn1cd9FFA7I8GByFR66nZHXnuHOfh47G1qDtqG6zGT1Ij1LHep1Hirm+fc 8ncZKtb4LKTbeyqShfIF6XR3PbhOw3hAXmeVT1ui/tN6/ThWOHKMh6bpvHGdzx8UDpbm ate1qmJGaOmcw4V8WEIbi0aKlioztCW9Rzh097v49+VSSayY/laQ+idPdLYVhqEKCKeD THOr+WHJ/vavgaTbqwCid30/Va405nZ+cW2AePIBKpa30ypLpboZuXNFIAw45qJz5dNW f5W+wy0Xj88TNXc0jfh14yHeSA1hBI/QCeVPXj7tmwBQk0n+0g25Qxy8pywwWFr3x2sG LRIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717128437; x=1717733237; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X+DXyudVfE5WtO+8iYYlBDeaVut+4WojwSIhooh6fLg=; b=u67fI13Vgwequ7IgusknluPHNHBGxFIuVnjN9Dmdggd+aFQYZjXQwYv2JyMtG7b++K DyfEEfBv5UzTep9FgBDeRjl8C2qg4KYwFn3C0eOBTP6itpBixBRWu3GxPVGoBP5txrR3 l5SJe8UD2YY8AwISNZwc3mGF7617mZo0++xBp22sM/8uB2iT//dq3CoZwq5mRKlq7AUK NygufoKhixGazt4kfkvlvvYPxapnEGDlI+2j/jY3dNbfmK0LlN9emgS0ocJPS2lM3jmm feHRK/koUW4YtkpAbFu4OOJHtQSZe6WZdSvUMfclfTA56IS6OPVIWTNRvwTUsPwB2l0D K4nA== X-Forwarded-Encrypted: i=1; AJvYcCXl/styt5y2/qFyZ28eUda6OJCU/GKe8nsKItHGihhVUK6Dd0pCUeB4oEvfytjGTLgkrmTF71zpe+THetkX1XXRs2JrgtrmbhjBYFwwLLYJo9bR X-Gm-Message-State: AOJu0Ywyznpjo5GA0pfX8YHax87syj3JKURpapFXtuOjQQp9VmnGcebe VOinsRePwUSOe0Ud13Kc2ram6x9LH6V8nXgPD0DCzrgRXAOzWKZ64+ars4ukqEFjXVN4A9RUaIY PoECoIFt0HHKaK/GOf8Jvz0gEYp1kFpfED8AuyA== X-Google-Smtp-Source: AGHT+IE+ZNG4FQp+8Hxqzq5AgQq9oamkZsMaHn1qDPouSYcA7fROmv2LmaNLEaCTl7kcoAp77OppwIaglsFbmJqOJbU= X-Received: by 2002:a17:90a:d513:b0:2bf:7ccb:b8c0 with SMTP id 98e67ed59e1d1-2c1dc58eb8amr678098a91.26.1717128436788; Thu, 30 May 2024 21:07:16 -0700 (PDT) List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Emil Tsalapatis Date: Fri, 31 May 2024 00:03:25 -0400 Message-ID: Subject: Re: [RFC] virtio testing framework To: Mario Marietto Cc: Tomek CEDRO , Virtualisation on FreeBSD Content-Type: multipart/alternative; boundary="0000000000008251b30619b81e45" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Vr8hm22FWz451H --0000000000008251b30619b81e45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not sure about the followup, but the patch I describe in the original post allows us to write and run tests for virtio drivers inside a VM. I originally wrote this because we have tests for the virtiofs paravirt device where we need to run both the paravirt driver and the device emulation in the same machine. The virtio stack is not designed for this - it expects the virtio driver to be running in the guest, and device emulation to be running in the host. This patchset introduces a way to emulate a virtio device in the guest for the purpose of running these virtiofs tests. The links in the original email describe the design in more detail, but just to reiterate, the code in this patch makes no functional changes to existing code. --Emil On Thu, May 30, 2024 at 6:19=E2=80=AFPM Mario Marietto wrote: > Can someone explain to me what the purpose of what you are talking about = ? > > > On Thu, May 30, 2024 at 10:38=E2=80=AFPM Tomek CEDRO w= rote: > >> Awesome!! Congrats :-) >> >> Here is some example of running NuttX RTOS on RV in a web browser using >> TinyEMU + VirtIO :-) >> >> https://github.com/lupyuen/nuttx-tinyemu >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> >> On Thu, May 30, 2024, 22:16 Emil Tsalapatis wrote= : >> >>> Hi everyone, >>> >>> while developing a virtiofs kernel driver I have written a debug >>> virtio transport to test virtio drivers inside a VM without requiring >>> nested virtualization or support from the host. The transport allows >>> paravirt devices to be emulated in local userspace instead of a host, s= o we >>> can create paravirt devices and test them as necessary. For virtiofs in >>> particular, it allows us to reuse the existing FUSE tests since we can = now >>> run both the virtiofs driver and the FUSE server (which is normally in = the >>> host) in a single machine. >>> >>> I have uploaded the WIP code [here = ], >>> and an overview of the design [here >>> ]. The >>> patch has a ways to go, and currently only supports virtio-blk device >>> emulation as a PoC, but feedback is welcome and appreciated. Please als= o >>> let me know if there is interest in using this for testing other virtio >>> devices apart from virtiofs. >>> >>> --Emil >>> >> > > -- > Mario. > --0000000000008251b30619b81e45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not sure about the followup, but the patch I describe= in the original post allows us to write and run tests for virtio drivers i= nside a VM. I originally wrote this because we have tests for the virtiofs = paravirt device where we need to run both the paravirt driver and the devic= e emulation in the same machine. The virtio stack is not designed for this = - it expects the virtio driver to be running in the guest, and device emula= tion to be running in the host. This patchset introduces a way to emulate a= virtio device in the guest for the purpose of running these virtiofs tests= . The links in the original email describe the design in more detail, but j= ust to reiterate, the code in this patch makes no functional changes to exi= sting code.

--Emil

On Thu, May 30, 20= 24 at 6:19=E2=80=AFPM Mario Marietto <marietto2008@gmail.com> wrote:
Can someone explain to me what the purpose of what you are talking about = ?


On Thu, May 30, 2024 at 1= 0:38=E2=80=AFPM Tomek CEDRO <tomek@cedro.info> wrote:
Awesome!! Congrats :-)

Here is some example of r= unning NuttX RTOS on RV in a web browser using TinyEMU + VirtIO :-)


--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Thu, May 30, 2024, 22:16 Emil Tsalapatis <emil@etsalapatis.com> wrote:
= Hi everyone,

=C2=A0 =C2=A0 while developing a virtiofs kernel driver= I have written a debug virtio transport to test virtio drivers inside a VM= without requiring nested virtualization or support from=20 the host. The transport allows paravirt devices to be emulated in local=20 userspace instead of a host, so we can create paravirt devices and test=20 them as necessary. For virtiofs in particular, it allows us to reuse the existing FUSE tests since we can now run both the virtiofs driver and=20 the FUSE server (which is normally in the host) in a single machine.

I have uploaded the WIP code [here], and an o= verview of the design [here]. The patch has a ways to go, and currently only supports virtio-blk=20 device emulation as a PoC, but feedback is welcome and appreciated.=20 Please also let me know if there is interest in using this for testing=20 other virtio devices apart from virtiofs.

= --Emil


--
Mario.
--0000000000008251b30619b81e45--