Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 04 12月, 2012 3 次提交
  3. 03 12月, 2012 1 次提交
  5. 30 11月, 2012 2 次提交
  7. 29 11月, 2012 5 次提交
  9. 28 11月, 2012 3 次提交
    • D
      virtio-scsi: Fix subtle (guest) endian bug · 863d1050
      由 David Gibson 提交于 
      The virtio-scsi config space is, by specification, in guest endian (which
is ill-defined, but there you go).  In virtio_scsi_get_config() we set up
all the fields in there, using stl_raw().  Which is a problem for the
max_channel and max_target fields, which are 16-bit, not 32-bit.  For
little-endian targets we get away with it by accident, since the first
two bytes will still be correct, and the extra two bytes written (with
zeroes) will be overwritten correctly by the next store.

But for big-endian guests, this means the max_target field ends up as zero,
which means the guest will only recognize a single disk on the virtio-scsi
bus.  This patch fixes the problem.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul 'Rusty' Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      863d1050
    • D
      virtio-scsi: Fix some endian bugs with virtio-scsi · 474ee55a
      由 David Gibson 提交于 
      The virtio-scsi specification does not specify the correct endianness for
fields in the request structure.  It's therefore best to assume that it is
"guest native" endian since that's the (stupid and poorly defined) norm in
virtio.

However, the qemu device for virtio-scsi has no byteswaps at all, and so
will break if the guest has different endianness from the host.  This patch
fixes it by adding tswap() calls for the sense_len and resid fields in
the request structure.  In theory status_qualifier needs swaps as well,
but that field is never actually touched.  The tag field is a uint64_t, but
since its value is completely arbitrary, it might as well be uint8_t[8]
and so it does not need swapping.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul 'Rusty' Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      474ee55a
    • A
      rtc: Only call rtc_set_cmos when Register B SET flag is disabled. · 02c6ccc6
      由 Alex Horn 提交于 
      This bug occurs when the SET flag of Register B is enabled. When an RTC
data register (i.e. any of the ten time/calender CMOS bytes) is set, the
data is (as expected) correctly stored in the cmos_data array. However,
since the SET flag is enabled, the function rtc_set_time is not invoked.
As a result, the field base_rtc in RTCState remains uninitialized. This
causes a problem on subsequent writes which can end up overwriting data.
To see this, consider writing data to Register A after having written
data to any of the RTC data registers; the following figure illustrates
the call stack for the Register A write operation:

 +- cmos_io_port_write
 +-- check_update_timer
 +---- get_next_alarm
 +------ rtc_update_time

In rtc_update_time, get_guest_rtc calculates the wrong time and
overwrites the previously written RTC data register values.
Signed-off-by: NAlex Horn <alex.horn@cs.ox.ac.uk>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      02c6ccc6
  11. 27 11月, 2012 12 次提交
  13. 26 11月, 2012 13 次提交
  15. 21 11月, 2012 1 次提交
    • H
      usb-redir: Don't handle interrupt output packets async · 723aedd5
      由 Hans de Goede 提交于 
      Instead report them as successfully completed directly on submission, this
has 2 advantages:

1) This matches the timing of interrupt output packets on real hardware,
with the previous async handling, if an ep has an interval of say 500 ms,
then there would be 500+ ms between the submission and the guest seeing the
completion, as we wont do the write back until the qh gets polled again. And
in the mean time the guest may very well have timed out, as the guest can
reasonable expect a much quicker completion.

2) This fixes interrupt output packets potentially getting send twice
surrounding a migration. As we delay the writeback to guest memory until
the qh gets polled again, there is a window between completion and writeback
where migration can happen, in this case the destination will not know
about the completion, and it will execute the packet *again*

But it does also come with a disadvantage:

1) If the actual interrupt out to the real usb device fails, there is no
way to report this back to the guest.

This patch assumes however that interrupt outs in practice never fail, as
they are only used by specialized drivers, which are unlikely to issue illegal
requests (unlike general class drivers which often issue requests which some
devices don't implement). And that thus the advantages outway the disadvantage.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      723aedd5