From nobody Sat Mar 11 16:48:18 2023 X-Original-To: freebsd-hackers@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 4PYplr6gb6z3xqSh for ; Sat, 11 Mar 2023 16:48:56 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PYplr6Fd6z3kLc for ; Sat, 11 Mar 2023 16:48:56 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id r15so5577715edq.11 for ; Sat, 11 Mar 2023 08:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678553335; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DX3L0qJ6QeNoNNdqnrRVwgHunbKjh1ibKRGztUFyAu8=; b=kI33YiWAHl1GfJE5XcrKi9GRToO25lo6JC1X5nuu8bfv7yhqnuvrHj8riF2Xb6S8DC dklDu30vHsFilqAMP6lbrbC7r/U6x/rNMnsWLZmUFZgxxGqTg0CD/MxBG/qhV/8VGMR/ vhp37lTb3KaXflpvX7GXhhbi6gYec4qJyeLkT46x/PlIBFPd+A0RayBrAZCGHKXKsZu0 0yINO90hczAhU+IqbEJSQPQ4vZXcrZx01DkSGC9u9zaQpdE9KqFZ5t3rz/GtTrzKskl+ PGHBXIDnv1u3fZ0PdM4yrOdyUcewZVDxGXIRgfHQBvRmLv6t9Ba78q9znY5IEvU19cCy DkdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678553335; 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=DX3L0qJ6QeNoNNdqnrRVwgHunbKjh1ibKRGztUFyAu8=; b=oW2OJbEzdq1LgIKmYxdaSd4X/Hh08abQsEi4PHdIGIiVWw9lv5fVh5aRlgalylDLt3 DdMYeQpr1psOmT3AHfxwsU9ufMIOWgxxDkx/ucLTEpDJekA3i34/EPMnilnbhii7X7IK 7U4e1KccFghw+gqwMYhH7gY8kVLyQPf17BLWobbFaLU+Dan1AO8UaspFWlABHcfnPb4B tsPmeRDlJjU1Ty06JoaVHFFQrx2c7JXqSV4J82jiTFI2GejXpLwZRg/jD8INN97GxbbJ gh8iMeXG2/XOJduWD5HNgfkTsSxWiWbdBkH0hoGwBupySWhcsZPCF8UCZRqftD3S0f0L 8cXQ== X-Gm-Message-State: AO0yUKXeoZOqTXaQQqYWnCpezR3Q3Qm+8ovAOyA9Nd5rMupwJw/1/3m0 fSpOIgFvSg9LqaSTvzybRBIkAPn4buDQDetU1N5F3zpdhYEPpQ== X-Google-Smtp-Source: AK7set/2rvshYGbF3RpAiT9l8P4x8FttNzfgFxxMaqnkdR5mlfgb3D2tMBrJLE3Coj6Wrdhzqvmuj/D1T0/2s9QkH6Q= X-Received: by 2002:a17:906:6d98:b0:8ab:b606:9728 with SMTP id h24-20020a1709066d9800b008abb6069728mr15016231ejt.5.1678553334871; Sat, 11 Mar 2023 08:48:54 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Sat, 11 Mar 2023 17:48:18 +0100 Message-ID: Subject: Re: quirks To: Souji Thenria Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000042faa705f6a2a7a2" X-Rspamd-Queue-Id: 4PYplr6Fd6z3kLc X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000042faa705f6a2a7a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. Exactly. This is valid even in the scenario that I'm going to explain. I would like to allow the passthru of an nVidia gpu to a Windows VM (virtualized with bhyve). Infact after one month of research we (me,an humble bugs hunter,soft system administrator and developers recruiter) in collaboration with Corvin Kohne and some other developers we have found the technical reasons why a modern nvidia gpu if passed through inside a windows 10 / 11 vm produces the error 43 (actually the error 12 after having added some new features). It happens because it misses "line interrupts support for passed through devices" ; actually there is the need of a massive change inside the bhyve source code. I'm collaborating with one hypervisor developer and a qemu/kvm/haxm advanced developer to reach that goal. To achieve the goal will be a very step forward for bhyve and for all the BSD community. We have an external,affiliated github and all the changes we made go inside it first of all and only later,maybe much later,some of them will go inside the official bhyve source code. But we want to have this experimental feature in a reasonable amount of time,not in many many years.i There is a partial INTx support missing in bhyve and it is an important feature already implemented in qemu a lot of time ago. Bhyve can't miss it. Passing thru an AMD and an NVIDIA modern GPU card inside a Windows VM will expand the number of tasks that can be done in FreeBSD using Windows as an intermediate medium. I'm interested in the development of bhyve. Not only to the passthru. I'm trying to help to improve bhyve trying many combinations and looking for bugs. I would really like it if one nvidia gpu can be passed to a windows 10 vm, First of all because I like challenges. I like to break the limits that do not allow users to freely use many functions connected to the purchased item. And second,I like everything that sounds geek / geekish that I can assemble and disassemble like legos,to understand how it works "inside". Unfortunately I'm not a developer. But I've found some very competent programmers who want to collaborate and I'm trying to find others to start working on this project. On november 2021,with the collaboration of Corvin Kohne and Peter Grehan,we have been able to pass through succesfully an nvidia graphic card inside a linux os,as u can see below,may people demonstrate appreciation : https://twitter.com/bhyve_dev/status/1459298927312662528 On Sat, Mar 11, 2023 at 5:46=E2=80=AFPM Souji Thenria wrote: > On 3/11/23 16:43, void wrote: > > What are 'quirks', how are they applied, why, where can I read up about > > them, are they documented? > > Hey tia, > > I have found this [http://www.root.org/~nate/freebsd/scsi/quirks.html]: > > FreeBSD drivers make every attempt possible to support the standards > behind hardware. Where possible and not in conflict with the standard, > they also attempt to work around hardware which doesn't strictly > conform. However, some devices have flaws which can't be worked around > while keeping the driver compatible with the standard. For these > devices, we have created a quirks mechanism to indicate to the driver > that it must avoid certain commands or use them differently with a > specific model and/or version of hardware. This document focuses on > identifying and committing quirks for storage hardware involving CAM and > UMASS but is applicable to other areas. > > Based on that, quirks are just identifiers for the driver, to compensate > for non-standard hardware implementations. > > -- > Souji Thenria > > > --=20 Mario. --00000000000042faa705f6a2a7a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hello.

Exactly. This is valid even in the s=
cenario that I'm going to explain.
I would like to allow the passthr=
u of an nVidia gpu to a Windows VM (virtualized with bhyve). 
Infact aft=
er one month of research we (me,an humble bugs hunter,soft system=20
administrator and developers recruiter) in collaboration with Corvin=20
Kohne and some other developers we have found the technical reasons why a
modern nvidia gpu if passed through inside a windows 10 / 11 vm=20
produces the error 43 (actually the error 12 after having added some new
features). It happens because it misses "line interrupts support for=
=20
passed through devices" ; actually there is the need of a massive chan=
ge
inside the bhyve source code. I'm collaborating with one hypervisor=20
developer and a qemu/kvm/haxm advanced developer to reach that goal. To=20
achieve the goal will be a very step forward for bhyve and for all the=20
BSD community. We have an external,affiliated github and all the changes
we made go inside it first of all and only later,maybe much later,some=20
of them will go inside the official bhyve source code. But we want to=20
have this experimental feature in a reasonable amount of time,not in=20
many many years.i There is a partial INTx support missing in bhyve and=20
it is an important feature already implemented in qemu a lot of time=20
ago. Bhyve can't miss it. Passing thru an AMD and an NVIDIA modern GPU=
=20
card inside a Windows VM will expand the number of tasks that can be=20
done in FreeBSD using Windows as an intermediate medium. I'm interested=
=20
in the development of bhyve. Not only to the passthru. I'm trying to=20
help to improve bhyve trying many combinations and looking for bugs. 
I =
would really like it if one nvidia gpu can be passed to a windows 10 vm,First of all because I like challenges. I like to break the limits that do=
=20
not allow users to freely use many functions connected to the purchased=20
item. And second,I like everything that sounds geek / geekish that I=20
can assemble and disassemble like legos,to understand how it works=20
"inside". Unfortunately I'm not a developer. But I've fou=
nd some very=20
competent programmers who want to collaborate and I'm trying to find=20
others to start working on this project. On november 2021,with the=20
collaboration of Corvin Kohne and Peter Grehan,we have been able to pass th=
rough=20
succesfully an nvidia graphic card inside a linux os,as u can see=20
below,may people demonstrate appreciation :



<= div class=3D"gmail_quote">
On Sat, Mar= 11, 2023 at 5:46=E2=80=AFPM Souji Thenria <mail@souji-thenria.net> wrote:
On 3/11/23 16:43, void wrote:
> What are 'quirks', how are they applied, why, where can I read= up about
> them, are they documented?

Hey tia,

I have found this [http://www.root.org/~nate/freeb= sd/scsi/quirks.html]:

FreeBSD drivers make every attempt possible to support the standards
behind hardware. Where possible and not in conflict with the standard,
they also attempt to work around hardware which doesn't strictly
conform. However, some devices have flaws which can't be worked around =
while keeping the driver compatible with the standard. For these
devices, we have created a quirks mechanism to indicate to the driver
that it must avoid certain commands or use them differently with a
specific model and/or version of hardware. This document focuses on
identifying and committing quirks for storage hardware involving CAM and UMASS but is applicable to other areas.

Based on that, quirks are just identifiers for the driver, to compensate for non-standard hardware implementations.

--
Souji Thenria




--
Mario.
--00000000000042faa705f6a2a7a2--