fix -net user checks by reordering checks

reorder slirp config options. first check the dns-server-address,
then check the first-dhcp-address. the original code was comparing
the first-dhcp-address with the default dns-server-address, not
the configured dns-server-address.

Signed-off-by: Bas van Sisseren <bas@quarantainenet.nl>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
make user networking hostfwd work with restrict=y

This patch allows the hostfwd option to override the restrict=y setting in
the user network stack, as explicitly stated in the documentation on the
restrict option:

     restrict=on|off
         If this option is enabled, the guest will be isolated, i.e. it
         will not be able to contact the host and no guest IP packets
         will be routed over the host to the outside. This option does
         not affect any explicitly set forwarding rules.

Qemu bug tracker:
https://bugs.launchpad.net/qemu/+bug/829455

Signed-off-by: Gertjan Halkes <qemu@ghalkes.nl>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
vl: Clean up parsing of -boot option argument

Commit 3d3b8303 threw in some QemuOpts parsing without replacing the
existing ad hoc parser, resulting in a confusing mess.  Clean it up.

Two user-visible changes:

1. Invalid options are reported more nicely.  Before:

        qemu: unknown boot parameter 'x' in 'x=y'

   After:

        qemu-system-x86_64: -boot x=y: Invalid parameter 'x'

2. If -boot is given multiple times, options accumulate, just like for
   -machine.  Before, only options order, once and menu accumulated.
   For the other ones, all but the first -boot in non-legacy syntax
   got simply ignored.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1371208516-7857-2-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-option: check_params() is now unused, drop it

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1371208516-7857-3-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
vl: Fix -boot order and once regressions, and related bugs

Option "once" sets up a different boot order just for the initial
boot.  Boot order reverts back to normal on reset.  Option "order"
changes the normal boot order.

The reversal is implemented by reset handler restore_boot_devices(),
which takes the boot order to revert to as argument.
restore_boot_devices() does nothing on its first call, because that
must be the initial machine reset.  On its second call, it changes the
boot order back, and unregisters itself.

Because we register the handler right when -boot gets parsed, we can
revert to an incorrect normal boot order, and multiple -boot can
interact in funny ways.

Here's how things work without -boot once or order:

* boot_devices is "".

* main() passes machine->boot_order to to machine->init(), because
  boot_devices is "".  machine->init() configures firmware
  accordingly.  For PC machines, machine->boot_order is "cad", and
  pc_cmos_init() writes it to RTC CMOS, where SeaBIOS picks it up.

Now consider -boot order=:

* boot_devices is "".

* -boot order= sets boot_devices to "" (no change).

* main() passes machine->boot_order to to machine->init(), because
  boot_devices is "", as above.

  Bug: -boot order= has no effect.  Broken in commit e4ada29e.

Next, consider -boot once=a:

* boot_devices is "".

* -boot once=a registers restore_boot_devices() with argument "", and
  sets boot_devices to "a".

* main() passes boot_devices "a" to machine->init(), which configures
  firmware accordingly.  For PC machines, pc_cmos_init() writes the
  boot order to RTC CMOS.

* main() calls qemu_system_reset().  This runs reset handlers.

  - restore_boot_devices() gets called with argument "".  Does
    nothing, because it's the first call.

* Machine boots, boot order is "a".

* Machine resets (e.g. monitor command).  Reset handlers run.

  - restore_boot_devices() gets called with argument "".  Calls
    qemu_boot_set("") to reconfigure firmware.  For PC machines,
    pc_boot_set() writes it into RTC CMOS.  Reset handler
    unregistered.

    Bug: boot order reverts to "" instead of machine->boot_order.  The
    actual boot order depends on how firmware interprets "".  Broken
    in commit e4ada29e.

Next, consider -boot once=a -boot order=c:

* boot_devices is "".

* -boot once=a registers restore_boot_devices() with argument "", and
  sets boot_devices to "a".

* -boot order=c sets boot_devices to "c".

* main() passes boot_devices "c" to machine->init(), which configures
  firmware accordingly.  For PC machines, pc_cmos_init() writes the
  boot order to RTC CMOS.

* main() calls qemu_system_reset().  This runs reset handlers.

  - restore_boot_devices() gets called with argument "".  Does
    nothing, because it's the first call.

* Machine boots, boot order is "c".

  Bug: it should be "a".  I figure this has always been broken.

* Machine resets (e.g. monitor command).  Reset handlers run.

  - restore_boot_devices() gets called with argument "".  Calls
    qemu_boot_set("") to reconfigure firmware.  For PC machines,
    pc_boot_set() writes it into RTC CMOS.  Reset handler
    unregistered.

    Bug: boot order reverts to "" instead of "c".  I figure this has
    always been broken, just differently broken before commit
    e4ada29e.

Next, consider -boot once=a -boot once=b -boot once=c:

* boot_devices is "".

* -boot once=a registers restore_boot_devices() with argument "", and
  sets boot_devices to "a".

* -boot once=b registers restore_boot_devices() with argument "a", and
  sets boot_devices to "b".

* -boot once=c registers restore_boot_devices() with argument "b", and
  sets boot_devices to "c".

* main() passes boot_devices "c" to machine->init(), which configures
  firmware accordingly.  For PC machines, pc_cmos_init() writes the
  boot order to RTC CMOS.

* main() calls qemu_system_reset().  This runs reset handlers.

  - restore_boot_devices() gets called with argument "".  Does
    nothing, because it's the first call.

  - restore_boot_devices() gets called with argument "a".  Calls
    qemu_boot_set("a") to reconfigure firmware.  For PC machines,
    pc_boot_set() writes it into RTC CMOS.  Reset handler
    unregistered.

  - restore_boot_devices() gets called with argument "b".  Calls
    qemu_boot_set("b") to reconfigure firmware.  For PC machines,
    pc_boot_set() writes it into RTC CMOS.  Reset handler
    unregistered.

* Machine boots, boot order is "b".

  Bug: should really be "c", because that came last, and for all other
  -boot options, the last one wins.  I figure this was broken some
  time before commit 37905d6a, and fixed there only for a single
  occurence of "once".

* Machine resets (e.g. monitor command).  Reset handlers run.

  - restore_boot_devices() gets called with argument "".  Calls
    qemu_boot_set("") to reconfigure firmware.  For PC machines,
    pc_boot_set() writes it into RTC CMOS.  Reset handler
    unregistered.

    Same bug as above: boot order reverts to "" instead of
    machine->boot_order.

Fix by acting upon -boot options order, once and menu only after
option parsing is complete, and the machine is known.  This is how the
other -boot options work already.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1371208516-7857-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
vl: Rename *boot_devices to *boot_order, for consistency

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1371208516-7857-5-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
pc: Make -no-fd-bootchk stick across boot order changes

Option -no-fd-bootchk asks the BIOS to attempt booting from a floppy
even when the boot sector signature isn't there, by setting a bit in
RTC CMOS.  It was added back in 2006 (commit 52ca8d6a).

Two years later, commit 0ecdffbb added monitor command boot_set.
Implemented by new function pc_boot_set().  It unconditionally clears
the floppy signature bit in CMOS.

Commit e0f084bf added -boot option once to automatically change the
boot order on first reset.  Reuses pc_boot_set(), thus also clears the
floppy signature bit.  Commit d9346e81 took care to preserve this
behavior.

Thus, -no-fd-bootchk applies to any number of boots.  Except it
applies just to the first boot with -boot once, and never after
boot_set.  Weird.  Make it stick instead: set the bit according to
-no-fd-bootchk in pc_boot_set().

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1371208516-7857-6-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
doc: Drop ref to Bochs from -no-fd-bootchk documentation

Manual page and qemu-doc on talk about "Bochs BIOS".  We use SeaBIOS,
and it implements the feature.  Replace by just "BIOS", and drop the
TODO line wondering about the Bochs reference.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1371208516-7857-7-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
exec.c: address_space_translate: handle access to addr 0 of 2^64 sized region

The memory API allows a MemoryRegion's size to be 2^64, as a special
case (otherwise the size always fits in a 64 bit integer). This meant
that attempts to access address zero in a 2^64 sized region would
assert in address_space_translate():

  #3  0x00007ffff3e4d192 in __GI___assert_fail#(assertion=0x555555a43f32
    "!a.hi", file=0x555555a43ef0 "include/qemu/int128.h", line=18,
    function=0x555555a4439f "int128_get64") at assert.c:103
  #4  0x0000555555877642 in int128_get64 (a=...)
    at include/qemu/int128.h:18
  #5  0x00005555558782f2 in address_space_translate (as=0x55555668d140,
   /addr=0, xlat=0x7fffafac9918, plen=0x7fffafac9920, is_write=false)
    at exec.c:221

Fix this by doing the 'min' operation in 128 bit arithmetic
rather than 64 bit arithmetic (we know the result of the 'min'
definitely fits in 64 bits because one of the inputs did).

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
memory: Introduce address_space_lookup_region

This introduces a wrapper for phys_page_find (before we complicate
address_space_translate with IOMMU translation).  This function will
also encapsulate locking and reference counting when we introduce
BQL-free dispatching.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
memory: move private types to exec.c

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: Allow unaligned address_space_rw

This will be needed for some corner cases with para-virtual I/O ports.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: Resolve subpages in one step except for IOTLB fills

Except for the case of setting the IOTLB entry in TCG mode, we can avoid
the subpage dispatching handlers and do the resolution directly on
address_space_lookup_region. An IOTLB entry describes a full page, not
only the region that the first access to a sub-divided page may return.

This patch therefore introduces a special translation function,
address_space_translate_for_iotlb, that avoids the subpage resolutions.
In contrast, callers of the existing address_space_translate service
will now always receive the terminal memory region section. This will be
important for breaking the BQL and for enabling unaligned memory region.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: Implement subpage_read/write via address_space_rw

This will allow to add support for unaligned memory regions: the subpage
container region can activate unaligned support unconditionally because
the read/write handler will now ensure that accesses are split as
required by calling address_space_rw. We can furthermore drop the
special handling of RAM subpages, address_space_rw takes care of this
already.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: return MemoryRegion from address_space_translate

Only address_space_translate_for_iotlb needs to return the section.
Every caller of address_space_translate now uses only section->mr,
return it directly.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Revert "memory: limit sections in the radix tree to the actual address space size"

This reverts commit 86a8623692b1b559a419a92eb8b6897c221bca74.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Revert "s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62"

This reverts commit 311f83ca08c011b048c063c2fd3038a8957970bc.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
exec: reorganize mem_add to match Int128 version

When adding support for 2^64-byte sections, we will have to change
the structure of mem_add to avoid failures in int128_get64.
Reorganize the code now before introducing Int128.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
memory: make section size a 128-bit integer

So far, the size of all regions passed to listeners could fit in 64 bits,
because artificial regions (containers and aliases) are eliminated by
the memory core, leaving only device regions which have reasonable sizes

An IOMMU however cannot be eliminated by the memory core, and may have
an artificial size, hence we may need 65 bits to represent its size.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
memory: iommu support

Add a new memory region type that translates addresses it is given,
then forwards them to a target address space.  This is similar to
an alias, except that the mapping is more flexible than a linear
translation and trucation, and also less efficient since the
translation happens at runtime.

The implementation uses an AddressSpace mapping the target region to
avoid hierarchical dispatch all the way to the resolved region; only
iommu regions are looked up dynamically.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi.kivity@gmail.com>
[Modified to put translation in address_space_translate; assume
 IOMMUs are not reachable from TCG. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>