- 19 4月, 2019 1 次提交
-
-
由 Markus Armbruster 提交于
Cc: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190417190641.26814-8-armbru@redhat.com> Acked-by: NAlex Williamson <alex.williamson@redhat.com>
-
- 18 4月, 2019 4 次提交
-
-
由 Markus Armbruster 提交于
Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190417190641.26814-7-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com> Message-Id: <20190417190641.26814-6-armbru@redhat.com>
-
由 Markus Armbruster 提交于
Cc: Paul Burton <pburton@wavecomp.com> Cc: Aleksandar Rikalo <arikalo@wavecomp.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190417190641.26814-5-armbru@redhat.com>
-
由 Markus Armbruster 提交于
load_fit() reports errors with error_printf() instead of error_report(). Worse, it even reports errors it actually recovers from, in fit_cfg_compatible() and fit_load_fdt(). Messed up in initial commit 51b58561. Convert the helper functions for load_fit() to Error. Make sure each failure path sets an error. Fix fit_cfg_compatible() and fit_load_fdt() not to report errors they actually recover from. Convert load_fit() to error_report(). Cc: Paul Burton <pburton@wavecomp.com> Cc: Aleksandar Rikalo <arikalo@wavecomp.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190417190641.26814-4-armbru@redhat.com>
-
- 17 4月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
The ObjectInfo struct has a variable length array containing the UTF-16 encoded filename. The number of characters of trailing data is given by the 'length' field in the struct and this must be validated against the size of the data packet received from the guest. Since the data is UTF-16, we must convert the byte count we have to a character count before validating. This must take care to truncate if a malicious guest sent an odd number of bytes. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NBandan Das <bsd@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 12 4月, 2019 1 次提交
-
-
由 Greg Kurz 提交于
Recent commit 5cf0d326 fixed a regression which was preventing the guest to access the extended config space of a PCIe device. This was done by introducing a new PCI bus subtype for PAPR. The original fix was causing PCI busses to be named "spapr-pci-host-bridge-root-bus.N" instead of "pci.N", which was making upper layers unhappy of course. This got worked around by hardcoding the PCI bus name to "pci.0", but this only works for the default PHB. And we're now hitting: # qemu-system-ppc64 \ -device spapr-pci-host-bridge,index=1 \ -device e1000e,bus=pci.0 \ -device e1000e,bus=pci.1 qemu-system-ppc64: -device e1000e,bus=pci.1: Bus 'pci.1' not found David already posted some patches [1] to control PCI extended config space accesses with a new flag in the base PCI bus class instead of subtyping. These patches are a bit more intrusive though, and are targetted for 4.1. When no name is passed to pci_register_bus(), the core device code generates a lowercase name based on the QOM typename. The typename for the base PCI bus class is "PCI", hence the "pci.0", "pci.1" bus names. Rename the type of the PAPR PCI bus to "pci", so that the QOM code can generate proper names. This is a hack but it is enough to fix the regression. And all this will be reworked properly in 4.1. [1] https://patchwork.ozlabs.org/project/qemu-devel/list/?series=100486 Fixes: 5cf0d326Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155500034416.646888.1307366522340665522.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 10 4月, 2019 1 次提交
-
-
由 Thomas Huth 提交于
QEMU currently crashes when you try to hot-plug an "nvdimm" device on older machine types: $ qemu-system-x86_64 -monitor stdio -M pc-1.1 QEMU 3.1.92 monitor - type 'help' for more information (qemu) device_add nvdimm,id=nvdimmn1 qemu-system-x86_64: /home/thuth/devel/qemu/util/error.c:57: error_setv: Assertion `*errp == ((void *)0)' failed. Aborted (core dumped) The call to hotplug_handler_pre_plug() in pc_memory_pre_plug() has been added recently before the check whether nvdimm is enabled. It should be done after the check. And while we're at it, also check the errp after the hotplug_handler_pre_plug(), otherwise errors are silently ignored here. Fixes: 9040e6dfSigned-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <20190407092314.11066-1-thuth@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 09 4月, 2019 2 次提交
-
-
由 Greg Kurz 提交于
The PAPR PHB acts as a legacy PCI bus but it allows PCIe extended config space accesses anyway (for pseries-2.9 and newer machine types). Introduce a specific PCI bus subtype to inform the common PCI code about that. Fixes: c2077e2cSigned-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155414130834.574858.16502276132110219890.stgit@bahia.lan> [dwg: Apply fix so we don't rename the default pci bus, breaking everything] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Some PHB implementations, eg. PAPR used on pseries machine, act like a regular PCI bus rather than a PCIe bus, but allow access to the PCIe extended config space anyway. Introduce a new PCI bus class method to modelize this behaviour and use it when adjusting the config space size limit during accesses. No behaviour change for existing PCI bus types. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155414130271.574858.4253514266378127489.stgit@bahia.lan> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 05 4月, 2019 3 次提交
-
-
由 Alistair Francis 提交于
Instead of using error_report() to print guest errors let's use qemu_log_mask(LOG_GUEST_ERROR,...) to log the error. Signed-off-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
-
由 Alistair Francis 提交于
This patch fixes four different things, to maintain bisectability they have been merged into a single patch. The following fixes are below: sifive_plic: Fix incorrect irq calculation The irq is incorrectly calculated to be off by one. It has worked in the past as the priority_base offset has also been set incorrectly. We are about to fix the priority_base offset so first first the irq calculation. sifive_u: Fix PLIC priority base offset and numbering According to the FU540 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. The same manual also specifies that the PLIC only has 53 source priorities. Fix these two incorrect header files. We also need to over extend the plic_gpios[] array as the PLIC sources count from 1 and not 0. riscv: sifive_e: Fix PLIC priority base offset According to the FE31 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. riscv: virt: Fix PLIC priority base offset Update the virt offsets based on the newly updated SiFive U and SiFive E offsets. Signed-off-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
-
由 Paul Durrant 提交于
The Xen blkif protocol requires that sector based quantities should be interpreted strictly as multiples of 512 bytes. Specifically: "first_sect and last_sect in blkif_request_segment, as well as sector_number in blkif_request, are always expressed in 512-byte units." Commit fcab2b46 "xen: add header and build dataplane/xen-block.c" incorrectly modified behaviour to use the block device logical_block_size property as the scale, instead of correctly shifting values by the hardcoded BDRV_SECTOR_BITS (and hence scaling them to 512 byte units). This patch undoes that change and restores compliance with the spec. Furthermore, this patch also restores the original xen_disk behaviour of advertizing a hardcoded 'sector-size' value of 512 in xenstore and scaling 'sectors' accordingly. The realize() method is also modified to fail if logical_block_size is set to anything other than 512. Signed-off-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com> Message-Id: <20190401121719.27208-1-paul.durrant@citrix.com> Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
-
- 04 4月, 2019 1 次提交
-
-
由 Paul Durrant 提交于
...and properly enable it when synthesizing a drive. The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants to enable discard on a specified image. The code in xen_block_drive_create() correctly parses this and uses it to set 'discard' to 'unmap' for the file_layer, but fails to do the same for the driver_layer (which effectively disables it). Meanwhile the code in xen_block_realize() advertizes discard support to the frontend in the default case (because conf->discard_granularity defaults to -1), even when the underlying image may not handle it. This patch adds the missing option to the driver_layer in xen_block_driver_create() and checks whether BDRV_O_UNMAP is actually set on the block device before advertizing discard to the frontend. In the case that discard is supported it also makes sure that the granularity is set to the physical block size. Signed-off-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com> Message-Id: <20190320142825.24565-1-paul.durrant@citrix.com> Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
-
- 03 4月, 2019 4 次提交
-
-
由 Daniel P. Berrangé 提交于
Compiling with GCC 9 complains hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’: hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 81 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ This local variable is only present to save a little bit of typing when setting the field later. Get rid of this to avoid the warning about unaligned accesses. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-15-berrange@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Daniel P. Berrangé 提交于
Compiling with GCC 9 complains hw/s390x/ipl.c: In function ‘s390_ipl_set_boot_menu’: hw/s390x/ipl.c:256:25: warning: taking address of packed member of ‘struct QemuIplParameters’ may result in an unaligned pointer value [-Waddress-of-packed-member] 256 | uint32_t *timeout = &ipl->qipl.boot_menu_timeout; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ This local variable is only present to save a little bit of typing when setting the field later. Get rid of this to avoid the warning about unaligned accesses. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-14-berrange@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NFarhan Ali <alifm@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Daniel P. Berrangé 提交于
The GCC 9 compiler complains about many places in s390 code that take the address of members of the 'struct SCHIB' which is marked packed: hw/s390x/css.c: In function ‘sch_handle_clear_func’: hw/s390x/css.c:698:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer val\ ue [-Waddress-of-packed-member] 698 | PMCW *p = &sch->curr_status.pmcw; | ^~~~~~~~~~~~~~~~~~~~~~ hw/s390x/css.c:699:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer val\ ue [-Waddress-of-packed-member] 699 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ ...snip many more... Almost all of these are just done for convenience to avoid typing out long variable/field names when referencing struct members. We can get most of this convenience by taking the address of the 'struct SCHIB' instead, avoiding triggering the compiler warnings. In a couple of places we copy via a local variable which is a technique already applied elsewhere in s390 code for this problem. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-13-berrange@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Daniel P. Berrangé 提交于
The GCC 9 compiler complains about many places in s390 code that take the address of members of the 'struct SCHIB' which is marked packed: hw/vfio/ccw.c: In function ‘vfio_ccw_io_notifier_handler’: hw/vfio/ccw.c:133:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value \ [-Waddress-of-packed-member] 133 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ hw/vfio/ccw.c:134:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value \ [-Waddress-of-packed-member] 134 | PMCW *p = &sch->curr_status.pmcw; | ^~~~~~~~~~~~~~~~~~~~~~ ...snip many more... Almost all of these are just done for convenience to avoid typing out long variable/field names when referencing struct members. We can get most of this convenience by taking the address of the 'struct SCHIB' instead, avoiding triggering the compiler warnings. In a couple of places we copy via a local variable which is a technique already applied elsewhere in s390 code for this problem. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-12-berrange@redhat.com> Reviewed-by: NEric Farman <farman@linux.ibm.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Reviewed-by: NFarhan Ali <alifm@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
- 02 4月, 2019 8 次提交
-
-
由 Peter Xu 提交于
VTD_RTADDR_RTT is dropped even by the VT-d spec, so QEMU should probably do the same thing (after all we never really implemented it). Since we've had a field for that in the migration stream, to keep compatibility we need to fill the hole up. Please refer to VT-d spec 10.4.6. Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <20190329061422.7926-3-peterx@redhat.com> Reviewed-by: NLiu, Yi L <yi.l.liu@intel.com> Acked-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Peter Xu 提交于
When introducing the initial support for scalable mode we added a new field into vmstate however we blindly migrate that field without notice. That'll break migration no matter forward or backward. The normal way should be that we use something like VMSTATE_UINT32_TEST() or subsections for the new vmstate field however for this case of vt-d we can even make it simpler because we've already migrated all the registers and it'll be fairly simple that we re-generate root_scalable field from the register values during post load of the device. Fixes: fb43cf73 ("intel_iommu: scalable mode emulation") Reviewed-by: NYi Sun <yi.y.sun@linux.intel.com> Signed-off-by: NPeter Xu <peterx@redhat.com> Message-Id: <20190329061422.7926-2-peterx@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Yuval Shaia 提交于
Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com> Message-Id: <20190321161832.10533-1-yuval.shaia@oracle.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Alex Williamson 提交于
If we try to use the intel-iommu device with vfio-pci devices without caching mode enabled, we're told: qemu-system-x86_64: We need to set caching-mode=1 for intel-iommu to enable device assignment with IOMMU protection. But to enable caching mode, the option is actually "caching-mode=on". Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Message-Id: <155364147432.16467.15898335025013220939.stgit@gimli.home> Reviewed-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NLaurent Vivier <laurent@vivier.eu> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Williamson <<a href="mailto:alex.williamson@redhat.com" target="_blank" rel="noreferrer">alex.williamson@redhat.com</a>><br> Reviewed-by: NEric Auger <eric.auger@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Liam Merwick 提交于
The callers to bios_linker_find_file() assert that the file entry returned is not NULL, except for those in bios_linker_loader_add_pointer(). Add two asserts in that case for completeness and to facilitate static code analysis. Signed-off-by: NLiam Merwick <liam.merwick@oracle.com> Message-Id: <1553199229-25318-1-git-send-email-liam.merwick@oracle.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Daniel P. Berrangé 提交于
Watch IDs are allocated from incrementing a int counter against the QFileMonitor object. In very long life QEMU processes with a huge amount of USB MTP activity creating & deleting directories it is just about conceivable that the int counter can wrap around. This would result in incorrect behaviour of the file monitor watch APIs due to clashing watch IDs. Instead of trying to detect this situation, this patch changes the way watch IDs are allocated. It is turned into an int64_t variable where the high 32 bits are set from the underlying inotify "int" ID. This gives an ID that is guaranteed unique for the directory as a whole, and we can rely on the kernel to enforce this. QFileMonitor then sets the low 32 bits from a per-directory counter. The USB MTP device only sets watches on the directory as a whole, not files within, so there is no risk of guest triggered wrap around on the low 32 bits. Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Bandan Das 提交于
This function is used in the delete path only and can be replaced by a call to usb_mtp_object_free. Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NBandan Das <bsd@redhat.com> Message-Id: <20190401211712.19012-3-bsd@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Bandan Das 提交于
Spotted by Coverity: CID 1399414 mtp delete allows the return status of delete succeeded, partial_delete or readonly - when none of the objects could be deleted. Give more meaningful names to return values of the delete function. Some initiators recurse over the objects themselves. In that case, only READ_ONLY can be returned. Signed-off-by: NBandan Das <bsd@redhat.com> Message-Id: <20190401211712.19012-2-bsd@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 01 4月, 2019 2 次提交
-
-
由 Peter Maydell 提交于
In usb_mask_to_str() we convert a mask of USB speeds into a human-readable string (like "full+high") for use in tracing and error messages. However the conversion code doesn't do anything to the string buffer if the passed in speedmask doesn't match any of the recognized speeds, which means that the tracing and error messages will end up with random garbage in them. This can happen if we're doing USB device passthrough. Handle the "unrecognized speed" case by using the string "unknown". Fixes: https://bugs.launchpad.net/qemu/+bug/1603785Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20190328133503.6490-1-peter.maydell@linaro.org Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
This reverts commit bd56d378. Turned out it isn't that simple as the device needs the pit object link. So "-device isa-pcspk" isn't going wo work anyway. We are in freeze, so just reverting the thing is the best way to handle this for now, trying to come up with something better can be done in the 4.1 devel cycle. Also add a comment noting the object link. Reported-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190328071121.21147-1-kraxel@redhat.com
-
- 29 3月, 2019 4 次提交
-
-
由 yuchenlin 提交于
Due to too early RCT0 interrput, win10x32 may hang on booting. This problem can be reproduced by doing power cycle on win10x32 guest. In our environment, we have 10 win10x32 and stress power cycle. The problem will happen about 20 rounds. Below shows some log with comment: The normal case: 22831@1551928392.984687:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928392.985655:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928392.985801:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.056710:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.077548:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 2, ICR 0, IMR 0 e1000: set_ics 2, ICR 2, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.102974:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928393.103267:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle RX now e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt e1000: RCTL: 255, mac_reg[RCTL] = 0x48002 e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work! ... The bad case: 27744@1551930483.117766:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 27744@1551930483.118398:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.198063:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.218675:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 2, ICR 0, IMR 0 e1000: set_ics 2, ICR 2, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.241768:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 27744@1551930483.241979:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle RX now e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting RCTL) e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 0x82&0x9d != 0 generate interrupt, hang on here... To workaround this problem, simply delay flush queue. Also stop receiving when timer is going to run. Tested on CentOS, Win7SP1x64 and Win10x32. Signed-off-by: Nyuchenlin <yuchenlin@synology.com> Reviewed-by: NDmitry Fleytman <dmitry.fleytman@gmail.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Cédric Le Goater 提交于
On non-P9 machines, the XIVE interrupt mode is not advertised, see spapr_dt_ov5_platform_support(). Add a couple of checks on the machine configuration to filter bogus setups and prevent OS failures : Interrupt modes CPU/Compat XICS XIVE dual P8/P8 OK QEMU failure (1) OK (3) P9/P8 OK QEMU failure (2) OK (3) P9/P9 OK OK OK (1) CPU exception model is incompatible with XIVE and the presenters will fail to realize. (2) CPU exception model is compatible with XIVE, but the XIVE CAS advertisement is dropped when in POWER8 mode. So we could ended up booting with the XIVE DT properties but without the HCALLs. Avoid confusing Linux with such settings and fail under QEMU. (3) force XICS in machine init Remove the check on XIVE-only machines in spapr_machine_init(), which has now become redundant. Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20190328100044.11408-1-clg@kaod.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
27461d69 "ppc: add host-serial and host-model machine attributes (CVE-2019-8934)" introduced 'host-serial' and 'host-model' machine properties for spapr to explicitly control the values advertised to the guest in device tree properties with the same names. The previous behaviour on KVM was to unconditionally populate the device tree with the real host serial number and model, which leaks possibly sensitive information about the host to the guest. To maintain compatibility for old machine types, we allowed those props to be set to "passthrough" to take the value from the host as before. Or they could be set to "none" to explicitly omit the device tree items. Special casing specific values on what's otherwise a user supplied string is very ugly. So, this patch simplifies things by implementing the backwards compatibility in a different way: we have a machine class flag set for the older machines, and we only load the host values into the device tree if A) they're not set by the user and B) we have that flag set. This does mean that the "passthrough" functionality is no longer available with the current machine type. That's ok though: if a user or management layer really wants the information passed through they can read it themselves (OpenStack Nova already does something similar for x86). It also means the user can't explicitly ask for the values to be omitted on the old machine types. I think that's an acceptable trade-off: if you care enough about not leaking the host information you can either move to the new machine type, or use a dummy value for the properties. For the new machine type, this also removes an odd inconsistency between running on a POWER and non-POWER (or non-Linux) hosts: if the host information couldn't be read from where we expect (in the host's device tree as exposed by Linux), we'd fallback to omitting the guest device tree items. While we're there, improve some poorly worded comments, and the help text for the properties. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
We use PPC_SEGMENT_64B in various places to guard code that is specific to 64-bit server processors compliant with arch 2.x. Consolidate the logic in a helper macro with an explicit name. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155327783157.1283071.3747129891004927299.stgit@bahia.lan> Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 26 3月, 2019 5 次提交
-
-
由 BALATON Zoltan 提交于
Coverity (CID 1399700) found that this was wrong so instead of trying to do it by hand use existing access functions that should work better. Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190318223842.427CB7456B2@zero.eik.bme.hu Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Laurent Vivier 提交于
Stop processing the descriptor list instead. The next frame timer tick will resume the work Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705Suggested-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NLaurent Vivier <lvivier@redhat.com> Message-id: 20190321085212.10796-1-lvivier@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Alex Bennée 提交于
We disabled code to limit device sizes to 8, 16, 32 or 64MiB more than a decade ago in commit 95d1f3ed and c8b153d7, v0.9.1. Bury. Signed-off-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> [Extracted from a larger patch, extended to pflash_cfi02.c] Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190319163551.32499-3-armbru@redhat.com>
-
由 Markus Armbruster 提交于
We reject undersized backends with a rather enigmatic "failed to read the initial flash content" error. For instance: $ qemu-system-ppc64 -S -display none -M sam460ex -drive if=pflash,format=raw,file=eins.img qemu-system-ppc64: Initialization of device cfi.pflash02 failed: failed to read the initial flash content We happily accept oversized images, ignoring their tail. Throwing away parts of firmware that way is pretty much certain to end in an even more enigmatic failure to boot. Require the backend's size to match the device's size exactly. Report mismatch like this: qemu-system-ppc64: Initialization of device cfi.pflash01 failed: device requires 1048576 bytes, block backend provides 512 bytes Improve the error for actual read failures to "can't read block backend". To avoid duplicating even more code between the two pflash device models, do all that in new helper blk_check_size_and_read_all(). The error reporting can still be confusing. For instance: qemu-system-ppc64 -S -display none -M taihu -drive if=pflash,format=raw,file=eins.img -drive if=pflash,unit=1,format=raw,file=zwei.img qemu-system-ppc64: Initialization of device cfi.pflash02 failed: device requires 2097152 bytes, block backend provides 512 bytes Leaves the user guessing which of the two -drive is wrong. Mention the issue in a TODO comment. Suggested-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190319163551.32499-2-armbru@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
-
由 Markus Armbruster 提交于
Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/qobject.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir hw/block --in-place Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20190313174433.12966-1-armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Acked-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com>
-
- 25 3月, 2019 1 次提交
-
-
由 Paolo Bonzini 提交于
Some drivers do I2C bitbanging by keeping the output to 0 and flipping the GPIO direction between input and output (see for example in Linux gpio_set_open_drain_value_commit, in drivers/gpio/gpiolib.c). When the GPIO is set to input, the pull-up resistor brings the output to 1, while when the GPIO is set to output, the output driver brings the output to 0. Implement this for the nRF51 GPIO device model. First, if both input and output are floating, and there is a pull-up or pull-down resistor configured, do not just set s->in, but also make any devices listening on the output qemu_irq receive that value. Second, if the pin is driven both internally (output pin) and externally you don't get a short circuit if both sides drive the pin to the same value. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Acked-by: NStefan Hajnoczi <stefanha@redhat.com> Message-id: 20190317141001.3346-1-pbonzini@redhat.com [PMM: wrapped long line] Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 23 3月, 2019 2 次提交
-
-
由 Markus Armbruster 提交于
Some trace points are attributed to the wrong source file. Happens when we neglect to update trace-events for code motion, or add events in the wrong place, or misspell the file name. Clean up with help of cleanup-trace-events.pl. Same funnies as in the previous commit, of course. Manually shorten its change to linux-user/trace-events to */signal.c. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-id: 20190314180929.27722-6-armbru@redhat.com Message-Id: <20190314180929.27722-6-armbru@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Markus Armbruster 提交于
Tracked down with cleanup-trace-events.pl. Funnies requiring manual post-processing: * block.c and blockdev.c trace points are in block/trace-events. * hw/block/nvme.c uses the preprocessor to hide its trace point use from cleanup-trace-events.pl. * include/hw/xen/xen_common.h trace points are in hw/xen/trace-events. * net/colo-compare and net/filter-rewriter.c use pseudo trace points colo_compare_udp_miscompare and colo_filter_rewriter_debug to guard debug code. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Message-id: 20190314180929.27722-5-armbru@redhat.com Message-Id: <20190314180929.27722-5-armbru@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-