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>

The general documentation we have for pv_ops is currenty present
on the IA64 docs, but since this documentation covers IA64 xen
enablement and IA64 Xen support got ripped out a while ago
through commit d52eefb4 present since v3.14-rc1 lets just
simplify, generalize and move the pv_ops documentation to a
shared place.

Cc: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Alok Kataria <akataria@vmware.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xenproject.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Disappointing, as this was kind of neat (especially getting to use RCU
to manage the address -> eventfd mapping).  But now the devices are PCI
handled in userspace, we get rid of both the NOTIFY hypercall and
the interface to connect an eventfd.
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 involves manually checking the console device (which is always in
slot 1 of bus 0) and using the window in VIRTIO_PCI_CAP_PCI_CFG to
program it (as we can't map the BAR yet).

We could in fact do this much earlier, but we wait for the first
write from the virtio_cons_early_init() facility.
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>

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

The demonstration launcher now uses PCI entirely.
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>

We want to use the local kernel headers, but -I../../include/uapi leads us into
a world of hurt.  Instead we create a dummy include/ dir with symlinks.

If we just use #include "../../include/uapi/linux/virtio_blk.h" we get:

	../../include/uapi/linux/virtio_blk.h:31:32: fatal error: linux/virtio_types.h: No such file or directory
	 #include <linux/virtio_types.h>
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 deliver interrupts for our emulated PCI devices using our
dumb PIC, and not emulate an 8259 and PCI irq mapping tables or whatever.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Once we add PCI, it starts trying to manage our interrupts.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

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

This no longer speeds up boot (IDE got better, I guess), but it does stop
us probing for a PCI bus.
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>

We normally abort the guest unconditionally when it gives us a bad address,
but in the next patch we want to copy some bytes which may not be mapped.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This is required for instruction emulation to move to userspace.
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>

We use the ptrace API struct, and we currently don't let them set
anything but the normal registers (we'd have to filter the others).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

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

Strictly, it's only needed when we have features (size or multiport).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>