- 11 Feb, 2015 25 commits
-
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Otherwise Linux fails to find the bus. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
This handles ioport 0xCF8 and 0xCFC accesses, which are used to read/write PCI device config space. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Once we add PCI, it starts trying to manage our interrupts. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
This lets us implement PCI. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
This no longer speeds up boot (IDE got better, I guess), but it does stop us probing for a PCI bus. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
This is required for instruction emulation to move to userspace. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
This is preparation for userspace handling MMIO and ioport accesses. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Theoretical debates aside, now it boots. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Strictly, it's only needed when we have features (size or multiport). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Since PCI is little endian, 8-bit access might work, but the spec section is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the “natural” access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
-
Rusty Russell authored
The VIRTIO_F_ANY_LAYOUT and VIRTIO_F_NOTIFY_ON_EMPTY features are pre-1.0 only. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
-
Rusty Russell authored
This allows modern implementations to ensure they don't use legacy feature bits or SCSI commands (which are not used in v1.0 non-legacy). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
-
Rusty Russell authored
This provides backdoor access to the device MMIOs, and every device should have one. From the virtio 1.0 spec (CS03): 4.1.4.7.1 Device Requirements: PCI configuration access capability The device MUST present at least one VIRTIO_PCI_CAP_PCI_CFG capability. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Michael S. Tsirkin <mst@redhat.com>
-
Tetsuo Handa authored
The virtqueue_add() calls START_USE() upon entry. The virtqueue_kick() is called if vq->num_added == (1 << 16) - 1 before calling END_USE(). The virtqueue_kick_prepare() called via virtqueue_kick() calls START_USE() upon entry, and will call panic() if DEBUG is enabled. Move this virtqueue_kick() call to after END_USE() call. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 23 Jan, 2015 1 commit
-
-
Pawel Moll authored
This patch add a support for second version of the virtio-mmio device, which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" specification. Main changes: 1. The control register symbolic names use the new device/driver nomenclature rather than the old guest/host one. 2. The driver detect the device version (version 1 is the pre-OASIS spec, version 2 is compatible with fist revision of the OASIS spec) and drives the device accordingly. 3. New version uses direct addressing (64 bit address split into two low/high register) instead of the guest page size based one, and addresses each part of the queue (descriptors, available, used) separately. 4. The device activity is now explicitly triggered by writing to the "queue ready" register. 5. Whole 64 bit features are properly handled now (both ways). Signed-off-by: Pawel Moll <pawel.moll@arm.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 21 Jan, 2015 14 commits
-
-
Michael S. Tsirkin authored
release function in modern driver is unused: it's a left-over from when each driver had to have its own release. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-
Michael S. Tsirkin authored
If set, try legacy interface first, modern one if that fails. Useful to work around device/driver bugs, and for compatibility testing. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
Useful for testing device virtio 1 compatibility. Based on patch by Rusty - couldn't resist putting that flying car joke in there! Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
The ABI *is* stable, and has been for a while now. Drop Kconfig warning saying that it's not guaranteed to work. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
This drivers -> this driver. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
makes code look a bit prettier. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
Most of our code has struct foo { } Fix one instances where ring is inconsistent. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
Most of our code has struct foo { } Fix two instances where blk is inconsistent. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
Most of our code has struct foo { } Fix two instances where balloon is inconsistent. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
Virtio 1.0 spec lists device config as optional. Set get/set callbacks to NULL. Drivers can check that and fail gracefully. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Michael S. Tsirkin authored
We don't know the # of VQs that drivers are going to use so it's hard to predict how much memory we'll need to map. However, the relevant capability does give us an upper limit. If that's below a page, we can reduce the number of required mappings by mapping it all once ahead of the time. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
QEMU wants it, so why not? Trust, but verify. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-
Michael S. Tsirkin authored
Lightly tested against qemu. One thing *not* implemented here is separate mappings for descriptor/avail/used rings. That's nice to have, will be done later after we have core support. This also exposes the PCI layout to userspace, and adds macros for PCI layout offsets: QEMU wants it, so why not? Trust, but verify. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-
Rusty Russell authored
Based on patches by Michael S. Tsirkin <mst@redhat.com>, but I found it hard to follow so changed to use structures which are more self-documenting. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-