Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is from all the non-PCI parts of the spec.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We were activating them with the virtqueues, and that's not allowed.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Linux doesn't generate these, but it's perfectly valid according to
a close reading of the spec.  I opened virtio spec bug VIRTIO-134 to
make this clearer there, too.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

As a demonstration, the lguest launcher is pretty strict, trying to
catch badly behaved drivers.  Document this precisely.

A good implementation would *NOT* crash the guest when these happened!
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

There are some (optional) parts we don't implement, but this quotes all
the device requirements from the spec (csd 03, but it should be the same
across all released versions).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The next patch will insert many quotes from the virtio 1.0 spec; they
make most sense if we copy the spec.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We were clearing the lower bits when setting the upper bits.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The example launcher doesn't reset the queue_enable like the spec says
we have to.  Plus, we should reset the size in case they negotiated
a different (smaller) one.

This is easy to test by unloading and reloading a virtio module.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This was only used for early console, now we can get rid of it altogether.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This simplifies the early probe.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The VIRTIO_PCI_CAP_PCI_CFG in the PCI virtio 1.0 spec allows access to
the BAR registers without mapping them.  This is a compulsory feature,
and we implement it here.

There are some subtleties involving access widths which we should
note:

4.1.4.7.1 Device Requirements: PCI configuration access capability

...
   Upon detecting driver write access to pci_cfg_data, the device MUST
   execute a write access at offset cap.offset at BAR selected by
   cap.bar using the first cap.length bytes from pci_cfg_data.

   Upon detecting driver read access to pci_cfg_data, the device MUST
   execute a read access of length cap.length at offset cap.offset at
   BAR selected by cap.bar and store the first cap.length bytes in
   pci_cfg_data.

So, for a write, we copy into the pci_cfg_data window, then write from
there out to the BAR.  This works correctly if cap.length != width of
write.  Similarly, for a read, we read into window from the BAR then
read the value from there.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is a magic register which causes a character to be outputted: it can
be used even before the device is configured.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We only support virtio 1.0 now
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The only real change here (other than using the PCI bus) is that we
didn't negotiate VIRTIO_NET_F_MRG_RXBUF before, so the format of the
packet header changed with virtio 1.0; we need TUNSETVNETHDRSZ on the
tun fd to tell it about the extra two bytes.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We remove SCSI support (which was removed for 1.0) and VIRTIO_BLK_F_FLUSH
feature flag (removed too, since it's compulsory for 1.0).

The rest is mainly mechanical.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Otherwise Linux fails to find the bus.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

For each device, We need to include the vendor capabilities to demark
where virtio common, notification and ISR regions are (we put them
all in BAR0).

We need to handle the switching of the virtqueues using the accessors.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This handles ioport 0xCF8 and 0xCFC accesses, which are used to
read/write PCI device config space.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We don't do anything with them yet (emulate_mmio_write and
emulate_mmio_read are stubs), but we decode the instructions and
search for the device they're hitting.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is where we point our PCI BARs, so that we can intercept MMIO
accesses.  We tell the kernel about it so any faults in this area are
directed to us.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This lets us implement PCI.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

While hacking on getting I/O out to the lguest launcher, I noticed
that returning 0xFF for the PS/2 keyboard status made it spin for a
while thinking there was a key pending.  Fix this by returning 1
instead of 0xFF.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We copy 7 bytes at eip for userspace's instruction decode; we have to
carefully handle the case where eip is at the end of a page.  We can't
leave this to userspace since kernel has all the page table decode
logic.

The decode logic moves to userspace, basically unchanged.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is preparation for userspace handling MMIO and ioport accesses.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Theoretical debates aside, now it boots.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We don't care about layout, so advertise that fact.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Somehow a naked u16 slipped into the glibc headers on my Ubuntu machine
(i386 2.17-0ubuntu5), breaking compile:

	In file included from lguest.c:46:0:
	/usr/include/linux/virtio_net.h:188:2: error: unknown type name ‘u16’

We use the kernel-style types anyway, just define them before the includes.
Also remove the advice on adding missing headers: that no longer works.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Lguest guests are UP, but the host is probably SMP, so real barriers are
required in case the device thread and the guest are on different CPUs.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The virtio spec was missing a barrier in example code, so I went back
to look at the lguest code.  Indeed, we need one.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

virtio requests are scatter-gather-style descriptors, but no
assumptions should be made about the layout.  lguest was lazy here,
but saved by the fact that the network device hands all requests to
tun (which does it correctly) and console and random devices simply
use readv and writev.

Block devices, however, are broken: we convert to iovecs internally,
just make sure we handle the correctly.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We usually got away with ->next on the final entry being NULL, but it
finally bit me.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org

This is a better location instead of having it in Documentation.
Signed-off-by: NDavidlohr Bueso <dave@gnu.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (fixed compile)

There are numerous broken references to Documentation files (in other
Documentation files, in comments, etc.). These broken references are
caused by typo's in the references, and by renames or removals of the
Documentation files. Some broken references are simply odd.

Fix these broken references, sometimes by dropping the irrelevant text
they were part of.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The CONFIG_RELOCATABLE code tries to align the unpack destination to
the value of 'kernel_alignment' in the setup_hdr.  If that's 0, it
tries to unpack to address 0, which in fact causes the gunzip code
to call 'error("Out of memory while allocating output buffer")'.

The bootloader (ie. the lguest Launcher in this case) should be doing
setting this field; the normal bzImage is 16M, we can use the same.
Reported-by: NStefanos Geraggelos <sgerag@cslab.ece.ntua.gr>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org

Also removes a long-unused #define and an extraneous semicolon.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We used to notify the Host every time we updated a device's status.  However,
it only really needs to know when we're resetting the device, or failed to
initialize it, or when we've finished our feature negotiation.

In particular, we used to wait for VIRTIO_CONFIG_S_DRIVER_OK in the
status byte before starting the device service threads.  But this
corresponds to the successful finish of device initialization, which
might (like virtio_blk's partition scanning) use the device.  So we
had a hack, if they used the device before we expected we started the
threads anyway.

Now we hook into the finalize_features hook in the Guest: at that
point we tell the Launcher that it can rely on the features we have
acked.  On the Launcher side, we look at the status at that point, and
start servicing the device.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>