1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!tag open_issue_hurd open_issue_gnumach]]
# IRC, freenode, #hurd, 2012-07-01
In context of [[DDE]].
<braunr> hm, i haven't looked but, does someone know if virtio is included
in netdde ?
<youpi> braunr: nope, there's an underlying virtio layer needed before
# IRC, freenode, #hurd, 2013-07-24
<teythoon> btw, I'd love to see libvirt support in hurd
<teythoon> I tried to hack up a dde based net translator
<teythoon> afaics they are very much like any other pci device, so the
infrastructure should be there
<teythoon> if anything I expect the libvirt stuff to be more easily
portable
<youpi> what do you mean by "a dde based net translator" ?
<youpi> ah, you mean virtio support in netdde ?
<teythoon> yes
<teythoon> virtio net is present in the kernel version we use for the dde
drivers
<teythoon> so I just copied the dde driver over, but I had no luck
compiling it
<youpi> ok, but what would be the benefice over e1000 & co?
<teythoon> any of the dde drivers btw
<teythoon> youpi: less overhead
<youpi> e1000 is already low overhead actually
<youpi> there are less and less differences in strategies for driving a
real board, and a virtual one
<youpi> we are seeing shared memory request buffer, dma, etc. in real
boards
<youpi> which ends up being almost exactly what virtio does :)
<youpi> ahci, for instance, really looks extremely like a virtio interface
<youpi> (I know, it's a disk, but that's the same idea, and I do know what
I'm talking about here :) )
<teythoon> that would actually be my next wish, a virtio disk driver, and
virt9p ;)
<braunr> on the other hand, i wouldn't spend much time on a virtio disk
driver for now
<braunr> the hurd as it is can't boot on a device that isn't managed by the
kernel
<braunr> we'd need to change the boot protocol
<teythoon> ok, I wasn't planning to, just wanted to see if I can easily
hack up the virtio-net translator
<braunr> well, as youpi pointed, there is little benefit to that as well
<braunr> but if that's what you find fun, help yourself :)
<teythoon> I didn't know that, I assumed there was some value to the virtio
stuff
<braunr> there is
<braunr> but relatively to other improvements, it's low
# IRC, freenode, #hurd, 2013-09-14
<rekado> I'm slowly beginning to understand the virtio driver framework
after reading Rusty's virtio paper and the Linux sources of a few virtio
drivers.
<rekado> Has anyone started working on virtio drivers yet?
<youpi> rekado: nobody has worked on virtio drivers, as I know of
<rekado> youpi: I'm still having a hard time figuring out where virtio
would fit in in the hurd.
<rekado> I'm afraid I don't understand how drivers in the hurd work at all.
Will part of this have to be implemented in Mach?
<youpi> rekado: it could be implemented either as a Mach driver, or as a
userland driver
<youpi> better try the second alternative
<youpi> i.e. as a translator
<youpi> sitting on e.g. /dev/eth0 or /dev/hd0
## IRC, freenode, #hurd, 2013-09-18
<rekado> To get started with virtio I'd like to write a simple driver for
the entropy device which appears as a PCI device when running qemu with
-device virtio-rng-pci .
<braunr> why entropy ?
<rekado> because it's the easiest.
<braunr> is it ?
<braunr> the driver itself may be, but integrating it within the system
probably isn't
<rekado> It uses the virtio framework but only really consists of a
read-only buffer virtqueue
<braunr> you're likely to want something that can be part of an already
existing subsystem like networking
<rekado> All the driver has to do is push empty buffers onto the queue and
pass the data it receives back from the host device to the client
<rekado> The thing about existing subsystems is: I don't really understand
them enough.
<rekado> I understand virtio, though.
<braunr> but isn't your goal understanding at least one ?
<rekado> yes.
<braunr> then i suggest working on virtio-net
<braunr> and making it work in netdde
<rekado> But to write a virtio driver for network I must first understand
how to actually talk to the host virtio driver/device.
<braunr> rekado: why ?
<rekado> There is still a knowledge gap between what I know about virtio
and what I have learned about the Hurd/Mach.
<braunr> are you trying to learn about virtio or the hurd ?
<rekado> both, because I'd like to write virtio drivers for the hurd.
<braunr> hm no
<rekado> with virtio drivers pass buffers to queues and then notify the
host.
<braunr> you may want it, but it's not what's best for the project
<rekado> oh.
<braunr> what's best is reusing existing drivers
<braunr> we're much too far from having enough manpower to maintain our own
<rekado> you mean porting the linux virtio drivers?
<braunr> there already is a virtio-net driver in linux 2.6
<braunr> so yes, reuse it
<braunr> the only thing which might be worth it is a gnumach in-kernel
driver for virtio block devices
<braunr> because currently, we need our boot devices to be supported by the
kernel itself ...
<rekado> when I boot the hurd with qemu and the entropy device I see it as
an unknown PCI device in the output of lspci.
<braunr> that's just the lspci database which doesn't know it
<rekado> Well, does this mean that I could actually talk to the device
already? E.g., through libpciaccess?
<rekado> I'm asking because I don't understand how exactly devices "appear"
on the Hurd.
<braunr> it's one of the most difficult topic currently
<braunr> you probably can talk to the device, yes
<braunr> but there are issues with pci arbitration
* rekado takes notes: "pci arbitration"
<rekado> so, this is about coordinating bus access, right?
<braunr> yes
<braunr> i'm not a pci expert so i can't tell you much more
<rekado> heh, okay.
<rekado> what kind of "issues with pci arbitration" are you referring to,
though?
<rekado> Is this due to something that Mach isn't doing?
<braunr> ideally, mach doesn't know about pci
<braunr> the fact we still need in-kernel drivers for pci devices is a big
problem
<braunr> we may need something like a pci server in userspace
<braunr> on l4 system it's called an io server
<rekado> How do in-kernel drivers avoid these issues?
<braunr> they don't
<rekado> Or rather: why is it they don't have these issues?
<braunr> they do
<rekado> oh.
<braunr> we had it when youpi added the sata driver
<braunr> so currently, all drivers need to avoid sharing common interrupts
for example
<braunr> again, since i'm not an expert about pci, i don't know more about
the details
<Hooligan0> pci arbitrations are made by hardware ... no ?
<braunr> Hooligan0: i don't know
<braunr> i'm not merely talking about bus mastering here
<braunr> simply preventing drivers from mapping the same physical memory
should be enforced somewhere
<braunr> i'm not sure it is
<braunr> same for irq sharing
<Hooligan0> braunr : is the support for boot devices into the kernel is
really needed if a loader put servers into the memory before starting
mach ?
<braunr> Hooligan0: there is a chicken-and-egg problem during boot,
whatever the solution
<braunr> obviously, we can preload from memory, but then you really want
your root file system to use a disk
<braunr> Hooligan0: the problem with preloading from memory is that you
want the root file system to use a real device
<braunr> the same way / refers to one on unix
<braunr> so you have an actual, persistent hierarchy from which the system
can be initialized and translators started
<braunr> you also want to share as much as possible between the early
programs and the others
<braunr> so for example, both the disk driver and the root file system
should be able to use the same libc instance
<braunr> this requires a "switch root" mechanism that needs to be well
defined and robust
<braunr> otherwise we'd just build our drivers and root fs statically
<braunr> (which is currently done with rootfs actually)
<braunr> and this isn't something we're comfortable with
<braunr> so for now, in-kernel drivers
<Hooligan0> humm ... disk driver and libc ... i see
<Hooligan0> in other way ... disk drivers can use only a little number of
lib* functions ; so with a static version, a bit of memory is lots
<Hooligan0> s/lots/lost
<Hooligan0> and maybe the driver can be hot-replaced after boot (ok ok,
it's more simple to say than to write)
<a name="KVM"></a>
# Virtio Drivers for KVM
In context of [[hurd/running/cloud]], *OpenStack*.
Ideally they would be userland. That means getting documentation about how
virtio works, and implement it. The hurdish part is mostly about exposing the
driver interface. The [[hurd/translator/devnode]] translator can be used as a
skeleton.
|
