Possible mistake on Virtio page

adrianmay · **Joined:** Sun Aug 12, 2018 1:48 am **Posts:** 3

Hi All,

It says on OSDev's virtio page that the Subsystem ID field in the PCI Configuration Space should be 2 for a block device. This is a bit ambiguous because on the PCI page we see fields called Subsystem Vendor ID and Subsystem Device ID, but neither was 2 in my experiment, namely, starting qemu with:

qemu-system-x86_64 -S -gdb tcp::9000 --nographic --enable-kvm -cpu host -m 8192 -drive id=c,file=hard.disk,format=raw,if=none -device virtio-blk-pci,drive=c -fda floppy.img
(or with the simpler form "-drive file=hard.disk,format=raw,if=virtio" and no -device)

and hunting through the PCI devices for anything with vendor ID 1AF4 using the code at the bottom. I find just this one:

Base (i.e. what I shove into 0xCF8 after adding the register number): 0x80002000
Register 2 (class code, subclass, prog if, revision): 0x01000000
Register 0 (device id, vendor id): 0x10011af4
Register 0x10 (subsystem): 0x01100009 (Plan 9 according to your page?)

Reading through the virtio specs linked from the bottom of your page, I see that the 1001 (just before the 1af4) confirms this as a block device.

So what's the story on the subsystem codes. Did they change something?

Here's that PCI scanning code in nasm:

Code:

BITS 64
SECTION .text
GLOBAL PciFindVirtio
GLOBAL PciSearchResults
GLOBAL PciSearchResultsCount

%define PCI_C 0xCF8
%define PCI_D 0xCFC
%macro PCI_READ 1
   mov eax, ecx 
   add eax, %1
   mov  dx, PCI_C
   out  dx, eax 
   mov  dx, PCI_D
   in  eax, dx
%endmacro

PciFindVirtio:
   mov R8, PciSearchResults
   mov R9, PciSearchResultsEnd
   ; Top bit enables, middle is bus and slot:function, low byte is register
   mov ecx, 0x80000000
.loop:
   PCI_READ 0 ;Vendor
   mov ebp, eax 
   PCI_READ 0x40 ;Subsystem
   mov esi, eax 
   PCI_READ 8 ;Class
   mov ebx, eax 
   and eax, 0xff000000
   cmp eax, 0x01000000 ; block device
   je .relevant
   mov eax, ebp
   and eax, 0x0000ffff
   cmp eax, 0x00001AF4 ;virtio vendor
   je .relevant
   jmp .irrel
.relevant:   
   mov [R8], ecx 
   mov [R8+4], ebx 
   mov [R8+8], ebp 
   mov [R8+12], esi 
   ; inc and bail if out of space
   add R8, 16
   cmp R8, R9
   je .done
.irrel:
   ; next slot
   add ecx, 0x100
   cmp ecx, 0x80ffff00
   jne .loop
.done:
   sub R8, PciSearchResults
   shr R8, 3
   mov [PciSearchResultsCount], R8
   ret

SECTION .data

PciSearchResultsCount:
   dq 0
PciSearchResults:
   times 16 dq 0, 0
PciSearchResultsEnd:

SpyderTL · **Joined:** Sun Sep 19, 2010 10:05 pm **Posts:** 1074

Since I did most of the work on that wiki page, I feel responsible for it's accuracy.

That being said, most of the guys here would agree that I'm not terribly focused on details, at least initially. So that page is my first-pass interpretation of the specs, and my limited experience testing in a few of the more popular VMs.

In this case, the VirtIO documentation and implementations are pretty difficult to nail down. There is the pre-release version of the specs (0.9.5), which is what everyone seems to use, and the "official" 1.0 specs, which I'm not sure if anyone has started using or not. I can't find anything on google stating if/when QEMU ever moved to 1.0, but I did find some notes (https://wiki.qemu.org/ChangeLog/2.5#virtio) about "virtio 1 mode", which may or may not mean that you can enable the 1.0 interface.

Also, there are apparently 3 different storage device options: virtio-9p, virtio-blk and virtio-scsi.

The only option that I've ever gotten configured to show up in any VM is virtio-9p (which is more of a "file system" interface rather than a block device), so I don't have a lot of information on the other two. When I get some time, I'll try to refresh my information and update the wiki, but feel free to make changes if you happen to figure out how it all works before I get around to it.

EDIT: Alright, according to the latest specifications (1.0 Committee Specification 04):

Quote:

4.1.2.3 Legacy Interfaces: A Note on PCI Device Discovery
Transitional devices MUST have a PCI Revision ID of 0. Transitional devices MUST have the PCI Subsystem
Device ID matching the Virtio Device ID, as indicated in section 5. Transitional devices MUST have the
Transitional PCI Device ID in the range 0x1000 to 0x103f.
This is to match legacy drivers.

Using your command line in QEMU, I get a SCSI device on the PCI bus with a Vendor ID of 1AF4, a Device ID of 1001, and a Subsystem ID of 2.

The Subsystem ID is field 0x0B in the PCI configuration space, not 10. It should be the high 16 bits of the 32-bit value at offset 0x2C.

Assuming your Subsystem ID is 2, I believe that everything should be working properly. The Device ID only matters for non-legacy VirtIO devices. For legacy devices, it can be any value between 0x1000 and 0x103f. For non-legacy devices, it will have a value between 0x1040 and 0x107f.

The 0.9.5 specs actually say:

Quote:

Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000 through 0x103F
inclusive is a virtio device. (The actual value within this range is ignored)

So, depending on which specs you are dealing with, the Device ID may or may not not be a reliable indicator of the device type, although QEMU does at least seem to match the 1.0 "legacy" specs.

Hope this helps.

OSDev.org

Possible mistake on Virtio page

Who is online