hd_geometry_guess() picks geometry and translation. Callers can get
the geometry directly, via parameters, but for translation they need
to go through the block layer.
Add a parameter for translation, so it can optionally be gotten just
like geometry. In preparation of purging translation from the block
layer, which will happen later in this series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When hd_geometry_guess() picks a geometry, it also picks the
appropriate translation, but only when the prior translation hint is
BIOS_ATA_TRANSLATION_AUTO. Looks wrong, because such a prior
translation would be passed to the BIOS whether it's suitable for the
geometry or not.
Fortunately, that can't happen. There are just two ways for the
translation hint to get set to something other than
BIOS_ATA_TRANSLATION_AUTO: drive_init() on behalf of -drive trans=...,
and hd_geometry_guess(). Both set it only when they also set a valid
geometry hint, i.e. one with a non-zero number of cylinders.
Since hd_geometry_guess() returns right away when it finds a valid
geometry hint, translation can only be BIOS_ATA_TRANSLATION_AUTO in
the remainder of the function.
Assert this, and simplify accordingly.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit f3d54fc4 factored it out of hw/ide.c for reuse. Sensible,
except it was put into block.c. Device-specific functionality should
be kept in device code, not the block layer. Move it to
hw/hd-geometry.c, and make stylistic changes required to keep
checkpatch.pl happy.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
vvfat creates a virtual VFAT filesystem with a certain logical
geometry that depends on its options. It sets the "geometry hint" to
this geometry. It is the only block driver to do this.
The geometry hint is about about *physical* geometry, and used only by
certain hard disk device models.
vvfat's hint is normally invisible for device models, because
bdrv_open() puts a raw format on top of vvfat's fat protocol. That
raw format is where drive_init() puts the user's geometry (if any),
and where the device model gets it from.
Nobody complained, because the default physical geometry is the same
as vvfat's logical geometry:
opts LCHS def. PCHS
1024,16,63 same
:32: 1024,16,63 same
:16: 1024,16,63 same
:12: 64,16,63 same
Except when you specify :floppy:
opts LCHS def. PCHS
:floppy: 80, 2,36 5,16,63
:32:floppy: 80, 2,36 5,16,63
:16:floppy: 80, 2,36 5,16,63
:12:floppy: 80, 2,18 2,16,63
Silly thing to do for use with a hard disk.
However, the "raw" format can be suppressed by adding an
redundant-looking "format=vvfat" to "file=fat:FOO". Then, vvfat's
hint clobbers the user's geometry, i.e. -drive options cyls, heads,
secs get silently ignored. Don't do that.
No change without format=vvfat. With it, the user's hard disk
geometry (-drive options cyls, heads, secs) is now obeyed, and the
default hard disk geometry with :floppy: now matches the one without
format=vvfat.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Unless parameter ":floppy:" is given, vvfat creates a virtual image
with DOS MBR defining a single partition which holds the FAT file
system. The size of the virtual image depends on the width of the
FAT: 32 MiB (CHS 64, 16, 63) for 12 bit FAT, 504 MiB (CHS 1024, 16,
63) for 16 and 32 bit FAT, leaving (64*16-1)*63 = 64449 and
(1024*16-1)*64 = 1032129 sectors for the partition.
However, it screws up the end of the partition in the MBR:
FAT width param. start CHS end CHS start LBA size
:32: 0,1,1 1023,14,63 63 1032065
:16: 0,1,1 1023,14,55 63 1032057
:12: 0,1,1 63,14,55 63 64377
The actual FAT file system nevertheless assumes the partition has
1032129 or 64449 sectors. Oops.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit 5bbdbb46 moved it to block.c because "other geometry guessing
functions already reside in block.c". Device-specific functionality
should be kept in device code, not the block layer. Move it back.
Disk geometry guessing is still in block.c. To be moved out in a
later patch series.
Bonus: the floppy type used in pc_cmos_init() now obviously matches
the one in the FDrive. Before, we relied on
bdrv_get_floppy_geometry_hint() picking the same type both in
fd_revalidate() and in pc_cmos_init().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Only buffers that map to unallocated blocks need to be zeroed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
5726c27fa9 broke
x86 specific options and user emulation specific stdio buffering.
Always enable all log items. They may not be useful for non-x86 targets,
but there's no harm either.
Fix user emulation buffering by passing around a flag.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Let the text cursor blink at 1.875 Hz, the original VGA cursor
frequency. No timer is used, instead we rely on the fact that the
display is updated periodically.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
We want all configure tests pass with -Werror if it is enabled. So we
need to update QEMU_CFLAGS early on to make sure we also pass it in to
all the compile test jobs.
This fixes a warning-became-error bug in nss for me with the default
configuration:
In file included from /usr/include/nss3/pkcs11t.h:1780,
from /usr/include/nss3/keythi.h:41,
from /usr/include/nss3/keyt.h:41,
from /usr/include/nss3/pk11pub.h:43,
from libcacard/vcard_emul_nss.c:21:
/usr/include/nss3/pkcs11n.h:365:26: error: "__GNUC_MINOR" is not defined
Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Now we have TARGET_PRI*PHYS for printing target_phys_addr_t values,
we can use them in monitor.c rather than having duplicate code
in two arms of a TARGET_PHYS_ADDR_BITS ifdef.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Switch a format string from %x to TARGET_PRIxPHYS so that it will
continue to work even if target_phys_addr_t is changed
to 64 bits in the future.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Use the new TARGET_PRIxPHYS macro to avoid the need to define an
OMAP_FMT_plx macro whose expansion depends directly on
TARGET_PHYS_ADDR_BITS.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Define a set of TARGET_PRI*PHYS format specifier macros for working
with target_phys_addr_t types. These follow the standard pattern
for such macros, and are more flexible than TARGET_FMT_plx, which
does not allow specification of field widths.
Suggested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
In our disassembly code, the bfd_vma type is always 64 bits,
even if the target's virtual address width is only 32 bits. This
means that when we print out addresses we need to truncate them
to 32 bits, to avoid odd output which has incorrectly sign-extended
a value to 64 bits, for instance this ARM example:
0x80479a60: e59f4088 ldr r4, [pc, #136] ; 0xffffffff80479a4f
(It would also be possible to truncate before passing the address
to info->print_address_func(), but truncating in the final print
function is the same approach that binutils takes to this problem.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
The PCI version is supported in lots of Operating Systems,
and has been successfully tested on:
- MS DOS 6.22 (using DC390 driver)
- MS Windows 3.11 (using DC390 driver)
- MS Windows 98 SE (using default driver)
- MS Windows NT 3.1 (using DC390 driver)
- MS Windows NT 4.0 (using default driver)
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
The same mechanism is already in place for some select commands.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
* 'target-arm.for-upstream' of git://git.linaro.org/people/pmaydell/qemu-arm:
target-arm: Add support for long format translation table walks
target-arm: Implement TTBCR changes for LPAE
target-arm: Implement long-descriptor PAR format
target-arm: Use target_phys_addr_t in get_phys_addr()
target-arm: Add 64 bit PAR, TTBR0, TTBR1 for LPAE
target-arm: Add 64 bit variants of DBGDRAR and DBGDSAR for LPAE
target-arm: Add AMAIR0, AMAIR1 LPAE cp15 registers
target-arm: Extend feature flags to 64 bits
target-arm: Implement privileged-execute-never (PXN)
ARM: Make target_phys_addr_t 64 bits and physaddrs 40 bits
hw/imx_avic.c: Avoid format error when target_phys_addr_t is 64 bits
target-arm: Fix TCG temp handling in 64 bit cp writes
target-arm: Fix some copy-and-paste errors in cp register names
target-arm: Fix typo that meant TTBR1 accesses went to TTBR0
target-arm: Fix CP15 based WFI
It is not needed, because the 'all' rule does the same.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
As mentioned in http://bugs.debian.org/660154 , finnish keyboard mapping
is kind of broken. Fix it as Timo Sirainen suggests in #660154.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Currently qemu outputs some low-level error in qemu-sockets.c
when failed to start vnc server.
eg. 'getaddrinfo(127.0.0.1,5902): Name or service not known'
Some libvirt users could not know what's happened with this
unclear error message. This patch added a more descriptive
error message.
Signed-off-by: Amos Kong <akong@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Suggested by blue swirl. Patch is on top of Paolo's
scsi-next tree.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Implement the changes to the TTBCR register required for LPAE:
* many fewer bits should be RAZ/WI
* since TTBCR changes can result in a change of ASID, we must
flush the TLB on writes to it
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Implement the different format of the PAR when long descriptor
translation tables are in use. Note that we assume that
get_phys_addr() returns a long-descriptor format DFSR value on
failure if long descriptors are in use; this added subtlety tips
the balance and makes it worth adding a comment documenting the
API to get_phys_addr().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In the implementation of get_phys_addr(), consistently use
target_phys_addr_t to hold the physical address rather than
uint32_t.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Under LPAE, the cp15 registers PAR, TTBR0 and TTBR1 are extended
to 64 bits, with a 64 bit (MRRC/MCRR) access path to read the
full width of the register. Add the state fields for the top
half and the 64 bit access path. Actual use of the top half of
the register will come with the addition of the long-descriptor
translation table format support.
For the PAR we also need to correct the masking applied for
32 bit writes (there are no bits reserved if LPAE is implemented)
and clear the high half when doing a 32 bit result VA-to-PA
lookup.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
LPAE extends the DBGDRAR and DBGDSAR debug registers to 64 bits; we
only implement these as dummy RAZ versions; provide dummies for
the 64 bit accesses as well.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add implementations of the AMAIR0 and AMAIR1 LPAE
Auxiliary Memory Attribute Indirection Registers.
These are implementation defined and we choose to
implement them as RAZ/WI, matching the Cortex-A7
and Cortex-A15.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Extend feature flags to 64 bits, as we've just run out of space
in the 32 bit integer we were using for them.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Implement the privileged-execute-never (PXN) translation table bit.
It is implementation-defined whether this is implemented, so we give
it its own ARM_FEATURE_ flag. LPAE requires PXN, so add also an
LPAE feature flag and the implication logic, as a placeholder
for actually implementing LPAE at a later date.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
