Libguestfs - Oct 2015 - Re: [PATCH] v2v: virtio-win: include *.dll too

On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld
wrote:
> >   1) tell which devices can be configured
> Not sure that I fully understated your question. but if you are going to
> create some sort of off-line automatic virtio-win drivers update
> utility, then it shouldn't be too complicated.
Roman is talking about what virt-v2v already does.

This is good information:
> First of all you will need
> to obtain the Windows kernel version by reading the following Registry
> key - "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion".
Let's say it
> 6.3, which means that it is Win8.1 or WS2012R2, parsing
"BuildLabEx"
> string from the same hive will give you information about the platform
> bitness. Next you need to go through inf files, and find
"DriverVer"
> string, like this one . taken from from vioscsi.inf
> 
> DriverVer=08/01/2015,62.72.104.10800
> 
> This string contains build time and version stamps. The version stamp
> looks as follow "62.72.104.10800"
> where 62 means a target Windows kernel version multiplied by 10. In this
> case it is 6.2 which means Win8 or WS2012
> 72 - the target host platform version multiplied bu 10 (was RHEL7.2)
> 104 just a magic number, but it can be changed, don't make any
> assumption based on this number.
> 10800 our internal build number (build 108) multiplied by 100
> If you found an inf file with the matching minor OS (6 in our case)
> version and matching or less but close minor version number (2 vs 3)
> then you are in the right directory.
Seems like looking at this field in the .inf file is better than our
current approach of matching path names.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

> On 29 Oct 2015, at 10:28, Richard W.M. Jones <rjones@redhat.com>
wrote:
> 
> On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote:
>>>  1) tell which devices can be configured
>> Not sure that I fully understated your question. but if you are going
to
>> create some sort of off-line automatic virtio-win drivers update
>> utility, then it shouldn't be too complicated.
> 
> Roman is talking about what virt-v2v already does.
> 
> This is good information:
> 
>> First of all you will need
>> to obtain the Windows kernel version by reading the following Registry
>> key - "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion".
Let's say it
>> 6.3, which means that it is Win8.1 or WS2012R2, parsing
"BuildLabEx"
>> string from the same hive will give you information about the platform
>> bitness. Next you need to go through inf files, and find
"DriverVer"
>> string, like this one . taken from from vioscsi.inf
>> 
>> DriverVer=08/01/2015,62.72.104.10800
>> 
>> This string contains build time and version stamps. The version stamp
>> looks as follow "62.72.104.10800"
>> where 62 means a target Windows kernel version multiplied by 10. In
this
>> case it is 6.2 which means Win8 or WS2012
>> 72 - the target host platform version multiplied bu 10 (was RHEL7.2)
>> 104 just a magic number, but it can be changed, don't make any
>> assumption based on this number.
>> 10800 our internal build number (build 108) multiplied by 100
>> If you found an inf file with the matching minor OS (6 in our case)
>> version and matching or less but close minor version number (2 vs 3)
>> then you are in the right directory.
> 
> Seems like looking at this field in the .inf file is better than our
> current approach of matching path names.
You just need to remember that we have binary compatible versions of drivers.
For example virtio-net driver for Windows 2012 (Windows 8) (6.2) will be used
for Windows 2012R2 (Windows 8.1) and Windows Server 2016 (Windows 10). So you
are getting the lowest compatible version of the OS from INF file.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW

On Thu, Oct 29, 2015 at 10:33:57AM +0200, Yan Vugenfirer
wrote:
> > On 29 Oct 2015, at 10:28, Richard W.M. Jones <rjones@redhat.com>
wrote:
> > On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote:
> > 
> > Seems like looking at this field in the .inf file is better than our
> > current approach of matching path names.
> 
> You just need to remember that we have binary compatible versions of
> drivers. For example virtio-net driver for Windows 2012 (Windows 8)
> (6.2) will be used for Windows 2012R2 (Windows 8.1) and Windows Server
> 2016 (Windows 10). So you are getting the lowest compatible version of
> the OS from INF file. 
That seems to match Vadim's description:
> >> If you found an inf file with the matching minor OS (6 in our
case)
> >> version and matching or less but close minor version number (2 vs
3)
> >> then you are in the right directory.
and it's OK as it's an algorithm that can be coded and made to work
reliably.

However, do I get it right that this is just a convention currently
followed in virtio-win drivers?  I.e. there's nothing in the Windows
driver specifications mandating this versioning scheme?  I'm trying to
figure out how dependable it is.

Besides, ATM there's at least one driver -- qemupciserial -- which
doesn't fit in this scheme (or any scheme at all :).

There are other peculiarities which we don't know what to do:

- the netkvm driver directory on virtio-win.iso contains netkvmco.dll
  (I'm assuming it's coinstaller dll).  However, netkvm.inf doesn't
  mention it, and the driver installs just fine without it.

- the balloon driver directory on virtio-win.iso contains blnsvr.exe
  (and .pdb) which is apparently a usermode service to report memory
  stats to host via balloon virtio queue.  However nothing seems to
  automatically trigger installation of that service.

Thanks,
Roman.