Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 20 11月, 2017 1 次提交
  3. 13 11月, 2017 1 次提交
  5. 29 9月, 2017 1 次提交
    • G
      virtio-input: send rel-wheel events for wheel buttons · f4924974
      由 Gerd Hoffmann 提交于 
      qemu uses wheel-up/down button events for mouse wheel input, however
linux applications typically want REL_WHEEL events.

This fixes wheel with linux guests. Tested with X11/wayland, and
windows virtio-input driver.

Based on a patch from Marc.
Added property to enable/disable wheel axis.

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 20170926113243.26081-1-kraxel@redhat.com
      f4924974
  7. 08 9月, 2017 1 次提交
  9. 31 8月, 2017 1 次提交
  11. 28 6月, 2017 3 次提交
  13. 09 6月, 2017 1 次提交
  15. 26 5月, 2017 2 次提交
  17. 18 5月, 2017 1 次提交
  19. 21 4月, 2017 1 次提交
  21. 23 3月, 2017 1 次提交
  23. 16 3月, 2017 5 次提交
  25. 01 2月, 2017 1 次提交
  27. 27 1月, 2017 1 次提交
    • P
      pflash_cfi01: fix per-device sector length in CFI table · feb0b1aa
      由 Peter Maydell 提交于 
      For configurations of the pflash_cfi01 device which set it up with a
device-width not equal to the width (ie where we are emulating
multiple narrow flash devices wired up in parallel), we were giving
incorrect values in the CFI data table:

(1) the sector length entry should specify the sector length for a
    single device, not the length for the overall collection of
    devices
(2) the number of blocks per device must not be divided by the
    number of devices because the resulting device size would not
    match the overall size
(3) this then means that the overall write block size must be
    modified depending on the number of devices because the entry is
    per device and when the guest writes into the flash it
    calculates the write size by using the CFI entry (write size
    per device) multiplied by the number of chips.
    (It would alternatively be possible to modify the write
    block size in the CFI table (currently hardcoded at 2048) and
    leave the overall write block size alone.)

This commit corrects these bugs, and adds a hw-compat property
to retain the old behaviour on 2.8 and earlier versions. (The
only board we have which uses this sort of flash config and
has machine versioning is the "virt" board -- the PC uses a
single flash device and so behaviour is unaffected whether
using old-multiple-chip-handling or not.)

Here is a configuration example from the vexpress board:

VEXPRESS_FLASH_SIZE = 64M
VEXPRESS_FLASH_SECT_SIZE 256K
num-blocks = VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE = 256
sector-length = 256K
width = 4
device-width = 2

The code will fill the CFI entry with the following entries:
  num-blocks = 256
  sector-length = 128K
  writeblock_size = 2048

This results in two chips, each with 256 * 128K = 32M device size and
a write block size of 2048.

A sector erase will be sent to both chips, thus 256K must be erased.
When the guest sends a block write command, it will write 4096 bytes
data at once (2048 per device).
Signed-off-by: NDavid Engraf <david.engraf@sysgo.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
[PMM: cleaned up and expanded commit message]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      feb0b1aa
  29. 19 1月, 2017 1 次提交
    • L
      fw-cfg: bump "x-file-slots" to 0x20 for 2.9+ machine types · a5b3ebfd
      由 Laszlo Ersek 提交于 
      More precisely, the "x-file-slots" count is bumped for all machine types
that:
(a) use fw_cfg, and
(b) are not versioned (hence migration is not expected to work for them
    across QEMU releases anyway), or have version 2.9.

This affects machine types implemented in the following source files:

- "hw/arm/virt.c". The "virt-*" machine type is versioned, and the <= 2.8
  versions already depend on HW_COMPAT_2_8 (see commit e353aac5).
  Therefore adding the "x-file-slots" compat values to HW_COMPAT_2_8
  suffices.

- "hw/i386/pc.c". The "pc-i440fx-*" (including "pc-*") and "pc-q35-*"
  machine types are versioned. Modifying HW_COMPAT_2_8 is sufficient here
  too (see commit "pc: Add 2.9 machine-types"). The "isapc" machtype is
  not versioned. The "xenfv" machine type, which uses fw_cfg for direct
  kernel booting, is also not versioned.

- "hw/ppc/mac_newworld.c". The "mac99" machine type is not versioned.

- "hw/ppc/mac_oldworld.c". The "g3beige" machine type is not versioned.

- "hw/sparc/sun4m.c". None of the 9 machine types defined in this file
  appear versioned.

- "hw/sparc64/sun4u.c". None of the 3 machine types defined in this file
  appear versioned.

Cc: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Artyom Tarasenko <atar4qemu@gmail.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NGabriel Somlo <somlo@cmu.edu>
Tested-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
      a5b3ebfd
  31. 27 12月, 2016 1 次提交
  33. 15 12月, 2016 1 次提交
  35. 18 10月, 2016 1 次提交
    • R
      intel_iommu: reject broken EIM · fb506e70
      由 Radim Krčmář 提交于 
      Cluster x2APIC cannot work without KVM's x2apic API when the maximal
APIC ID is greater than 8 and only KVM's LAPIC can support x2APIC, so we
forbid other APICs and also the old KVM case with less than 9, to
simplify the code.

There is no point in enabling EIM in forbidden APICs, so we keep it
enabled only for the KVM APIC;  unconditionally, because making the
option depend on KVM version would be a maintanance burden.

Old QEMUs would enable eim whenever intremap was on, which would trick
guests into thinking that they can enable cluster x2APIC even if any
interrupt destination would get clamped to 8 bits.
Depending on your configuration, QEMU could notice that the destination
LAPIC is not present and report it with a very non-obvious:

  KVM: injection failed, MSI lost (Operation not permitted)

Or the guest could say something about unexpected interrupts, because
clamping leads to aliasing so interrupts were being delivered to
incorrect VCPUs.

KVM_X2APIC_API is the feature that allows us to enable EIM for KVM.

QEMU 2.7 allowed EIM whenever interrupt remapping was enabled.  In order
to keep backward compatibility, we again allow guests to misbehave in
non-obvious ways, and make it the default for old machine types.

A user can enable the buggy mode it with "x-buggy-eim=on".
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NPeter Xu <peterx@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      fb506e70
  37. 10 10月, 2016 1 次提交
  39. 27 9月, 2016 1 次提交
  41. 10 9月, 2016 1 次提交
  43. 05 9月, 2016 1 次提交
  45. 29 7月, 2016 2 次提交
  47. 14 7月, 2016 1 次提交
    • L
      virtio-mmio: format transport base address in BusClass.get_dev_path · f58b39d2
      由 Laszlo Ersek 提交于 
      At the moment the following QEMU command line triggers an assertion
failure (minimal reproducer by Cole):

  qemu-system-aarch64 \
    -machine virt-2.6,accel=tcg \
    -nodefaults \
    -no-user-config \
    -nographic -monitor stdio \
    -device virtio-scsi-device,id=scsi0 \
    -device virtio-scsi-device,id=scsi1 \
    -drive file=foo.img,format=raw,if=none,id=d0 \
    -device scsi-hd,bus=scsi0.0,drive=d0 \
    -drive file=foo.img,format=raw,if=none,id=d1 \
    -device scsi-hd,bus=scsi1.0,drive=d1

  qemu-system-aarch64: migration/savevm.c:615:
  vmstate_register_with_alias_id:
  Assertion `!se->compat || se->instance_id == 0' failed.

The reason is that the vmstate sections for the two scsi-hd devices are
not uniquely identifiable by name.

The direct parent buses of the scsi-hd devices -- scsi0.0 and scsi1.0 --
support the BusClass.get_dev_path member function. scsibus_get_dev_path()
formats a device path prefix with the help of its topologically parent
bus, and then appends the chan:id:lun triplet to it. For both scsi-hd
devices, this triplet is 0:0:0.

(Here we use "device path" in the QEMU migration sense, for vmstate
section identification, not in the OFW or UEFI device path senses.)

The virtio-scsi HBA is plugged into the virtio-mmio bus (implemented by
the internal VirtIOMMIOProxy device). This bus class
(TYPE_VIRTIO_MMIO_BUS) inherits, as its get_dev_path() member function,
the virtio_bus_get_dev_path() method from its parent class
(TYPE_VIRTIO_BUS).

virtio_bus_get_dev_path() does not format any kind of device address on
its own; "virtio addresses" are transport-specific. Therefore
virtio_bus_get_dev_path() asks the topologically parent bus of the proxy
object (implementing the specific virtio transport) to format the address
of the proxy object.

(For virtio-pci devices (where the proxy is an instance of VirtIOPCIProxy,
plugged into a PCI bus), this ends up in pcibus_get_dev_path().)

However, VirtIOMMIOProxy is usually (in practice: always) plugged into
"main-system-bus", the singleton TYPE_SYSTEM_BUS object. This BusClass
does not support formatting QEMU vmstate device paths at all (as
SysBusDevice objects can have zero or more IO ports and zero or more MMIO
regions). Hence the formatting request delegated from
virtio_bus_get_dev_path() gets answered with NULL.

The end result is that the two scsi-hd devices end up with the same device
path "0:0:0", which triggers the assert.

We can solve this by recognizing that virtio-mmio transports are
distinguished from each other by their base addresses in MMIO address
space. Implement virtio_mmio_bus_get_dev_path() as follows:

(1) The virtio device whose devpath is to be formatted resides on a
    virtio-mmio bus that is implemented by a VirtIOMMIOProxy object. Ask
    the parent bus of VirtIOMMIOProxy to format the device path of
    VirtIOMMIOProxy, as a path prefix. (This is identical to what
    virtio_bus_get_dev_path() does.)

(2) Append the base address of VirtIOMMIOProxy to the device path, such
    as:
    - virtio-mmio@000000000a003e00,
    - virtio-mmio@000000000a003c00.

Given that these device paths are placed in the migration stream, step (2)
above, if done unconditionally, would break migration. So make that step
conditional on a new VirtIOMMIOProxy property, which is enabled for 2.7
machine types and later.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Kevin Zhao <kevin.zhao@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Tom Hanson <thomas.hanson@linaro.org>
Reported-by: NKevin Zhao <kevin.zhao@linaro.org>
Reviewed-by: NAndrew Jones <drjones@redhat.com>
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1467739394-28357-1-git-send-email-lersek@redhat.com
Fixes: https://bugs.launchpad.net/qemu/+bug/1594239Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      f58b39d2
  49. 17 5月, 2016 1 次提交
  51. 26 2月, 2016 1 次提交
  53. 26 1月, 2016 1 次提交
    • J
      fdc: change auto fallback drive for ISA FDC to 288 · 4812fa27
      由 John Snow 提交于 
      The 2.88 drive is more suitable as a default because
it can still read 1.44 images correctly, but the reverse
is not true.

Since there exist virtio-win drivers that are shipped on
2.88 floppy images, this patch will allow VMs booted without
a floppy disk inserted to later insert a 2.88MB floppy and
have that work.

This patch has been tested with msdos, freedos, fedora,
windows 8 and windows 10 without issue: if problems do
arise for certain guests being unable to cope with 2.88MB
drives as the default, they are in the minority and can use
type=144 as needed (or insert a proper boot medium and omit
type=144/288 or use type=auto) to obtain different drive types.

As icing, the default will remain auto/144 for any pre-2.6
machine types, hopefully minimizing the impact of this change
in legacy hw to basically zero.
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Message-id: 1453495865-9649-13-git-send-email-jsnow@redhat.com
      4812fa27
  55. 16 1月, 2016 1 次提交
  57. 11 1月, 2016 2 次提交
  59. 23 12月, 2015 2 次提交