The 'e820entry' and 'e820map' names have various annoyances:

 - the missing underscore departs from the usual kernel style
   and makes the code look weird,

 - in the past I kept confusing the 'map' with the 'entry', because
   a 'map' is ambiguous in that regard,

 - it's not really clear from the 'e820map' that this is a regular
   C array.

Rename them to 'struct e820_entry' and 'struct e820_array' accordingly.

( Leave the legacy UAPI header alone but do the rename in the bootparam.h
  and e820/types.h file - outside tools relying on these defines should
  either adjust their code, or should use the legacy header, or should
  create their private copies for the definitions. )

No change in functionality.

Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Running lguest without arguments or with a wrong argument name
borks the terminal, because the cleanup handler is set up too late
in the initialization process.
Signed-off-by: NDaniel Baluta <daniel.baluta@intel.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@kernel.org>

The paravirt_enabled() check is going away, the area tossed to
the kernel on lguest is not zeroed out, so ensure lguest force
disables tboot and APM just in case the kernel file being read
might have this set for whatever reason.
Signed-off-by: NLuis R. Rodriguez <mcgrof@kernel.org>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: andriy.shevchenko@linux.intel.com
Cc: bigeasy@linutronix.de
Cc: boris.ostrovsky@oracle.com
Cc: david.vrabel@citrix.com
Cc: ffainelli@freebox.fr
Cc: george.dunlap@citrix.com
Cc: glin@suse.com
Cc: jgross@suse.com
Cc: jlee@suse.com
Cc: josh@joshtriplett.org
Cc: julien.grall@linaro.org
Cc: konrad.wilk@oracle.com
Cc: kozerkov@parallels.com
Cc: lenb@kernel.org
Cc: lguest@lists.ozlabs.org
Cc: linux-acpi@vger.kernel.org
Cc: lv.zheng@intel.com
Cc: matt@codeblueprint.co.uk
Cc: mbizon@freebox.fr
Cc: rjw@rjwysocki.net
Cc: robert.moore@intel.com
Cc: tiwai@suse.de
Cc: toshi.kani@hp.com
Cc: xen-devel@lists.xensource.com
Link: http://lkml.kernel.org/r/1460592286-300-8-git-send-email-mcgrof@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Be explicit and make use of X86_SUBARCH_LGUEST directly.
Signed-off-by: NLuis R. Rodriguez <mcgrof@kernel.org>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: andriy.shevchenko@linux.intel.com
Cc: bigeasy@linutronix.de
Cc: boris.ostrovsky@oracle.com
Cc: david.vrabel@citrix.com
Cc: ffainelli@freebox.fr
Cc: george.dunlap@citrix.com
Cc: glin@suse.com
Cc: jgross@suse.com
Cc: jlee@suse.com
Cc: josh@joshtriplett.org
Cc: julien.grall@linaro.org
Cc: konrad.wilk@oracle.com
Cc: kozerkov@parallels.com
Cc: lenb@kernel.org
Cc: lguest@lists.ozlabs.org
Cc: linux-acpi@vger.kernel.org
Cc: lv.zheng@intel.com
Cc: matt@codeblueprint.co.uk
Cc: mbizon@freebox.fr
Cc: rjw@rjwysocki.net
Cc: robert.moore@intel.com
Cc: tiwai@suse.de
Cc: toshi.kani@hp.com
Cc: xen-devel@lists.xensource.com
Link: http://lkml.kernel.org/r/1460592286-300-4-git-send-email-mcgrof@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Ours uses a u32 for the data, since we ensure it's always
aligned and it's x86 so it doesn't matter anyway.

  lguest.c:128:8: error: redefinition of ‘struct virtio_pci_cfg_cap’
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: 3121bb02 ("virtio: define virtio_pci_cfg_cap in header.")
Signed-off-by: NIngo Molnar <mingo@kernel.org>

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>

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>