25.03.2020 18:50, Stefan Reiter wrote:
backup_clean is only ever called as a handler via job_exit, which
Hmm.. I'm afraid it's not quite correct.
job_clean
job_finalize_single
job_completed_txn_abort (lock aio context)
job_do_finalize
Hmm. job_do_finalize calls
This adds a simple exported helper function which determins if a given
(supposedly) PCI device is actually an NVLink2 device, which has some
special considerations.
Signed-off-by: David Gibson
---
hw/ppc/spapr_pci_nvlink2.c | 5 +
include/hw/pci-host/spapr.h | 1 +
2 files changed, 6
Currently spapr_phb_nvgpu_populate_pcidev_dt() works a little cryptically.
It steps through all the NVLink2 GPUs and NPUs and if they match the device
we're called for, we generate the relevant device tree information.
Make this a little more obvious by introducing helpers to determine it a
given
Currently, attempting to unplug an NVLink2 device will generally
result in the guest crashing. If you're lucky, it instead simply
won't work and remain in a "pending unplug" state indefinitely.
There is code we could we could theoretically improve in qemu to tear
these devices down better.
> From: Liu, Yi L
> Sent: Wednesday, March 25, 2020 9:22 PM
> To: 'Peter Xu'
> Subject: RE: [PATCH v1 20/22] intel_iommu: propagate PASID-based iotlb
> invalidation to host
>
> > From: Peter Xu
> > Sent: Wednesday, March 25, 2020 2:34 AM
> > To: Liu, Yi L
> > Subject: Re: [PATCH v1 20/22]
For various technical reasons we can't currently allow unplug a PCI to PCI
bridge on the pseries machine. spapr_pci_unplug_request() correctly
generates an error message if that's attempted.
But.. if the given errp is not error_abort or error_fatal, it doesn't
actually stop trying to unplug the
Currently, we can't properly handle unplug of NVLink2 devices, because we
don't have code to tear down their special memory resources. There's not
a lot of impetus to implement that. Since hardware NVLink2 devices can't
be hot unplugged, the guest side drivers don't usually support unplug
anyway.
vhost_user_set_mem_table() and vhost_user_set_mem_table_postcopy() have
gotten convoluted, and have some identical code.
This change moves the logic populating the VhostUserMemory struct and
fds array from vhost_user_set_mem_table() and
vhost_user_set_mem_table_postcopy() to a new function,
+-- On Tue, 24 Mar 2020, Jason Wang wrote --+
| > Why here is '>=' instead of '>'. IIUC the total sending length can reach
| > to sizeof(s->rx_frame). Same in the other place in this patch.
|
| Yes, this need to be fixed.
Sent patch v7. Thank you.
--
Prasad J Pandit / Red Hat Product Security
> From: Peter Xu
> Sent: Wednesday, March 25, 2020 11:07 PM
> To: Liu, Yi L
> Cc: qemu-devel@nongnu.org; alex.william...@redhat.com;
> eric.au...@redhat.com; pbonz...@redhat.com; m...@redhat.com;
> da...@gibson.dropbear.id.au; Tian, Kevin ; Tian, Jun J
> ; Sun, Yi Y ; k...@vger.kernel.org;
>
> From: Peter Xu
> Sent: Wednesday, March 25, 2020 10:57 PM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 14/22] intel_iommu: bind/unbind guest page table to
> host
>
> On Wed, Mar 25, 2020 at 12:42:58PM +, Liu, Yi L wrote:
> > > From: Peter Xu
> > > Sent: Wednesday, March 25, 2020 1:47 AM
> >
> From: Peter Xu
> Sent: Wednesday, March 25, 2020 11:12 PM
> To: Liu, Yi L
> Subject: Re: [PATCH v1 17/22] intel_iommu: do not pass down pasid bind for
> PASID
> #0
>
> On Wed, Mar 25, 2020 at 10:42:25AM +, Liu, Yi L wrote:
> > > From: Peter Xu < pet...@redhat.com>
> > > Sent: Wednesday,
Marc-André Lureau wrote:
> Since commit 8c6b0356b53977bcfdea5299db07884915425b0c ("util/async:
> make bh_aio_poll() O(1)"), migration-test reveals a leak:
>
> QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
> tests/qtest/migration-test -p /x86_64/migration/postcopy/recovery
>
(Don't know why my Linux-Evolution missed this mail.)
> -Original Message-
> From: Eric Blake
> Sent: Wednesday, March 25, 2020 20:54
> To: Robert Hoo ; qemu-devel@nongnu.org;
> pbonz...@redhat.com; richard.hender...@linaro.org
> Cc: Hu, Robert
> Subject: Re: [PATCH 2/2]
On 3/25/20 3:44 AM, Aleksandar Markovic wrote:
> May I ask you, Richard, to select this patch for your next TCG-for-5.0 queue,
> so that I don't go through a MIPS queue process for just a single patch?
>
I suppose I could, but at present I have nothing in the tcg queue, so it would
be just the
This will allow to reuse a single generic .bdrv_co_create
implementation for several drivers.
No functional changes.
Signed-off-by: Maxim Levitsky
---
block.c | 3 ++-
block/crypto.c| 3 ++-
block/file-posix.c| 4 +++-
block/file-win32.c| 4 +++-
The recent patches from Max Reitz allowed some block drivers to not
provide the .bdrv_co_create_opts and still allow qemu-img to
create/format images as long as the image is already existing
(that is the case with various block storage drivers like nbd/iscsi/nvme, etc)
However it was found out
Instead of checking the .bdrv_co_create_opts to see if we need the failback,
just implement the .bdrv_co_create_opts in the drivers that need it.
This way we don't break various places that need to know if the underlying
protocol/format really supports image creation, and this way we still
allow
On Wed, Mar 25, 2020 at 08:18:28PM +0100, Philippe Mathieu-Daudé wrote:
> Running the coccinelle script produced:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file
> scripts/coccinelle/object_property_missing_error_propagate.cocci \
>
On Wed, Mar 25, 2020 at 07:13:32PM +0100, Greg Kurz wrote:
> On Thu, 26 Mar 2020 00:29:06 +1000
> Nicholas Piggin wrote:
>
> > Try to be tolerant of FWNMI delivery errors if the machine check had been
> > recovered by the host.
> >
> > Signed-off-by: Nicholas Piggin
> > ---
> >
On Thu, Mar 26, 2020 at 12:29:04AM +1000, Nicholas Piggin wrote:
> Some of the conditions are not as clearly documented as they could be.
> Also the non-FWNMI case does not need a large comment.
>
> Reviewed-by: Greg Kurz
> Signed-off-by: Nicholas Piggin
Applied to ppc-for-5.0.
> ---
>
On Thu, Mar 26, 2020 at 12:29:05AM +1000, Nicholas Piggin wrote:
> Add some messages which explain problems and guest misbehaviour that
> may be difficult to diagnose in rare cases of machine checks.
>
> Signed-off-by: Nicholas Piggin
Applied to ppc-for-5.0.
> ---
> hw/ppc/spapr_events.c | 4
On Thu, Mar 26, 2020 at 12:29:06AM +1000, Nicholas Piggin wrote:
> Try to be tolerant of FWNMI delivery errors if the machine check had been
> recovered by the host.
>
> Signed-off-by: Nicholas Piggin
Applied to ppc-for-5.0.
> ---
> hw/ppc/spapr_events.c | 27 ++-
> 1
On Wed, Mar 25, 2020 at 04:25:30PM +0100, Greg Kurz wrote:
> We currently check if some capability in OV5 was removed by the guest
> since the previous CAS, and we trigger a CAS reboot in that case. This
> was required because it could call for a device-tree property or node
> removal, that we
On Thu, Mar 26, 2020 at 12:41:44AM +1000, Nicholas Piggin wrote:
> This implements the NMI interface for the PNV machine, similarly to
> commit 3431648272d ("spapr: Add support for new NMI interface") for
> SPAPR.
>
> Signed-off-by: Nicholas Piggin
Applied to ppc-for-5.1.
> ---
> hw/ppc/pnv.c
On Tue, Mar 24, 2020 at 05:39:12PM +1100, Alexey Kardashevskiy wrote:
> Coverity detected an issue (CID 1421903) with potential call of clz64(0)
> which returns 64 which make it do "<<" with a negative number.
>
> This checks the mask and avoids undefined behaviour.
>
> In practice pgsizes and
On Thu, Mar 26, 2020 at 12:41:43AM +1000, Nicholas Piggin wrote:
> Rather than have the helper take an optional vector address
> override, instead have its caller modify env->nip itself.
> This is more consistent when adding pnv nmi support, and also
> with mce injection added later.
>
>
On Thu, Mar 26, 2020 at 12:29:03AM +1000, Nicholas Piggin wrote:
65;5803;1c> The KVM FWNMI capability should be enabled with the
"ibm,nmi-register"
> rtas call. Although MCEs from KVM will be delivered as architected
> interrupts to the guest before "ibm,nmi-register" is called, KVM has
>
On Tue, Mar 24, 2020 at 12:12:16PM +, Peter Maydell wrote:
> If qemu_find_file() doesn't find the BIOS it returns NULL; we were
> passing that unchecked through to load_elf(), which assumes a non-NULL
> pointer and may misbehave. In practice it fails with a weird message:
>
> $
On Wed, 25 Mar 2020 02:39:08 +0530
Kirti Wankhede wrote:
> Sequence during _RESUMING device state:
> While data for this device is available, repeat below steps:
> a. read data_offset from where user application should write data.
> b. write data of data_size to migration region from
On Wed, 25 Mar 2020 02:39:07 +0530
Kirti Wankhede wrote:
> Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
> functions. These functions handles pre-copy and stop-and-copy phase.
>
> In _SAVING|_RUNNING device state or pre-copy phase:
> - read pending_bytes. If
On Wed, Mar 25, 2020 at 08:41:44PM +, Dr. David Alan Gilbert wrote:
[...]
> > +enum KVMReaperState {
> > +KVM_REAPER_NONE = 0,
> > +/* The reaper is sleeping */
> > +KVM_REAPER_WAIT,
> > +/* The reaper is reaping for dirty pages */
> > +KVM_REAPER_REAPING,
> > +};
>
>
Hi Zenghui,
On 3/25/20 9:10 AM, Zenghui Yu wrote:
> Hi Eric,
>
> On 2020/3/20 17:24, Eric Auger wrote:
>> Introduce an helper functions to register
>> - a new device, characterized by its device id and the
>> max number of event IDs that dimension its ITT (Interrupt
>> Translation Table).
I know everyone is heads-down working on the 5.0 release, and I realize this is
a lot of code. However, I would really appreciate some feedback on it. Is
there anything I can do to make it easier to review?
Thanks,
Taylor
> -Original Message-
> From: Taylor Simpson
> Sent: Friday,
On Wed, 25 Mar 2020 at 21:03, Niek Linnenbank wrote:
> By the way, is the coverity output of master publically available by any
> chance?
We use the public 'coverity scan' service:
https://scan.coverity.com/projects/qemu
You can create an account and look at the defects if you
like, but we
On Wed, 25 Mar 2020 02:39:06 +0530
Kirti Wankhede wrote:
> Define flags to be used as delimeter in migration file stream.
> Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
> region from these functions at source during saving or pre-copy phase.
> Set VFIO device state
On Tue, Mar 24, 2020 at 10:21 PM Peter Maydell
wrote:
> Coverity points out (CID 1421926) that the read code for
> REG_ADDR_HIGH reads off the end of the buffer, because it does a
> 32-bit read from byte 4 of a 6-byte buffer.
>
> The code also has an endianness issue for both REG_ADDR_HIGH and
>
According to [1], this is still an issue today.
[1]: https://review.coreboot.org/c/coreboot/+/39838/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1693050
Title:
xhci HCIVERSION register read
On Wed, Mar 25, 2020 at 12:28 PM Philippe Mathieu-Daudé wrote:
>
> Running the coccinelle script produced:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file
> scripts/coccinelle/object_property_missing_error_propagate.cocci \
> --keep-comments
On Wed, Mar 25, 2020 at 12:26 PM Philippe Mathieu-Daudé wrote:
>
> Running the coccinelle script produced:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file
> scripts/coccinelle/object_property_missing_error_propagate.cocci \
> --keep-comments
On Wed, Mar 25, 2020 at 12:24 PM Philippe Mathieu-Daudé wrote:
>
> Running the coccinelle script produced:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file
> scripts/coccinelle/object_property_missing_error_propagate.cocci \
> --keep-comments
On Wed, Mar 25, 2020 at 12:22 PM Philippe Mathieu-Daudé wrote:
>
> Patch created mechanically by running:
>
> $ spatch \
> --macro-file scripts/cocci-macro-file.h --include-headers \
> --sp-file
> scripts/coccinelle/object_property_missing_error_propagate.cocci \
> --keep-comments
On 3/25/20 6:50 PM, Marc-André Lureau wrote:
On Mon, Mar 23, 2020 at 12:55 PM Marc-André Lureau
wrote:
On Mon, Mar 23, 2020 at 12:30 PM Philippe Mathieu-Daudé
wrote:
Document that virtqueue_pop() returned memory must be released
with free().
Signed-off-by: Philippe Mathieu-Daudé
On Wed, Mar 25, 2020 at 08:14:03PM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > Add a parameter for size of dirty ring. If zero, dirty ring is
> > disabled. Otherwise dirty ring will be enabled with the per-vcpu size
> > as specified. If dirty ring cannot be
On 3/25/20 7:47 PM, Marc-André Lureau wrote:
If object-add failed, no need to create a return value that may later
be leaked.
Signed-off-by: Marc-André Lureau
---
qom/qom-qmp-cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c
* Peter Xu (pet...@redhat.com) wrote:
> KVM dirty ring is a new interface to pass over dirty bits from kernel
> to the userspace. Instead of using a bitmap for each memory region,
> the dirty ring contains an array of dirtied GPAs to fetch. For each
> vcpu there will be one dirty ring that binds
On Wed, Mar 25, 2020 at 08:00:31PM +, Dr. David Alan Gilbert wrote:
> > @@ -2077,6 +2079,33 @@ static int kvm_init(MachineState *ms)
> > s->memory_listener.listener.coalesced_io_add =
> > kvm_coalesce_mmio_region;
> > s->memory_listener.listener.coalesced_io_del =
> >
* Peter Xu (pet...@redhat.com) wrote:
> Add a parameter for size of dirty ring. If zero, dirty ring is
> disabled. Otherwise dirty ring will be enabled with the per-vcpu size
> as specified. If dirty ring cannot be enabled due to unsupported
> kernel, it'll fallback to dirty logging. By
Public bug reported:
I want to use qemu-arm-static to cross-compile software. The compiler
itself is a native cross-compiler connected via "distcc".
The problem is that a script tries to do some stuff with "git" and with
a "git clone -s" command the whole story reproducibly stops with a
* Peter Xu (pet...@redhat.com) wrote:
> Add a parameter for size of dirty ring. If zero, dirty ring is
> disabled. Otherwise dirty ring will be enabled with the per-vcpu size
> as specified. If dirty ring cannot be enabled due to unsupported
> kernel, it'll fallback to dirty logging. By
On Wed, 25 Mar 2020 02:39:02 +0530
Kirti Wankhede wrote:
> These functions save and restore PCI device specific data - config
> space of PCI device.
> Tested save and restore with MSI and MSIX type.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> ---
> hw/vfio/pci.c
On Wed, Mar 25, 2020 at 8:18 PM Philippe Mathieu-Daudé wrote:
>
> This series is inspired of Peter fix:
> "hw/arm/xlnx-zynqmp.c: fix some error-handling code"
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg691636.html
>
> Add a cocci script to fix the other places.
>
> Based-on:
Running the coccinelle script produced:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --dir hw
[[manual check required: error_propagate() might be
Running the coccinelle script produced:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --dir hw
[[manual check required: error_propagate() might be
Running the coccinelle script produced:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --dir hw
[[manual check required: error_propagate() might be
Running the coccinelle script produced:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --dir hw
[[manual check required: error_propagate() might be
Patch created mechanically by running:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --in-place --dir hw
Signed-off-by: Philippe Mathieu-Daudé
---
Running the coccinelle script produced:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --dir hw
[[manual check required: error_propagate() might be
Running the coccinelle script produced:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --dir hw
[[manual check required: error_propagate() might be
Patch created mechanically by running:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --in-place --dir hw
Signed-off-by: Philippe Mathieu-Daudé
---
Patch created mechanically by running:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --in-place --dir hw
Signed-off-by: Philippe Mathieu-Daudé
---
Patch created mechanically by running:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --in-place --dir hw
Signed-off-by: Philippe Mathieu-Daudé
---
Patch created mechanically by running:
$ spatch \
--macro-file scripts/cocci-macro-file.h --include-headers \
--sp-file scripts/coccinelle/object_property_missing_error_propagate.cocci \
--keep-comments --smpl-spacing --in-place --dir hw
Signed-off-by: Philippe Mathieu-Daudé
---
This series is inspired of Peter fix:
"hw/arm/xlnx-zynqmp.c: fix some error-handling code"
https://www.mail-archive.com/qemu-devel@nongnu.org/msg691636.html
Add a cocci script to fix the other places.
Based-on: <20200324134947.15384-1-peter.mayd...@linaro.org>
Philippe Mathieu-Daud=C3=A9 (12):
In some places in we put an error into a local Error*, but forget
to check for failure and pass it back to the caller.
Add a Coccinelle patch to catch automatically add the missing code.
Inspired-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
On Wed, 25 Mar 2020 10:04:29 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > > +{
> > > +AcpiRsdpData rsdp_data = {
> > > +.revision = 0,
> > > +.oem_id = ACPI_BUILD_APPNAME6,
> > > +.xsdt_tbl_offset = NULL,
> > > +.rsdt_tbl_offset = ,
> >
On Wed, 25 Mar 2020 10:16:36 +0100
Gerd Hoffmann wrote:
> > > mounted. Decided to use the "i8042: PNP: No PS/2 controller found."
> > > line instead for a simple test (just check the kernel log timestamps,
> > > three runs each). The ACPI initialization is already done at that
> > > point, so
Since commit 8c6b0356b53977bcfdea5299db07884915425b0c ("util/async:
make bh_aio_poll() O(1)"), migration-test reveals a leak:
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
tests/qtest/migration-test -p /x86_64/migration/postcopy/recovery
tests/qtest/libqtest.c:140: kill_qemu() tried to
* Peter Xu (pet...@redhat.com) wrote:
> Cache it too because we'll reference it more frequently in the future.
>
> Signed-off-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
> ---
> accel/kvm/kvm-all.c | 1 +
> include/sysemu/kvm_int.h | 1 +
> 2 files changed, 2 insertions(+)
>
>
If object-add failed, no need to create a return value that may later
be leaked.
Signed-off-by: Marc-André Lureau
---
qom/qom-qmp-cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c
index 435193b036..6bd137ccbf 100644
---
Hi,
A small series of leaks spotted by ASAN during "make check".
Marc-André Lureau (3):
migration: fix cleanup_bh leak on resume
qmp: fix leak on callbacks that return both value and error
object-add: don't create return value if failed
migration/migration.c | 7 ++-
* Peter Xu (pet...@redhat.com) wrote:
> kvm_physical_sync_dirty_bitmap() calculates the ramblock offset in an
> awkward way from the MemoryRegionSection that passed in from the
> caller. The truth is for each KVMSlot the ramblock offset never
> change for the lifecycle. Cache the ramblock offset
Direct leak of 4120 byte(s) in 1 object(s) allocated from:
#0 0x7fa114931887 in __interceptor_calloc (/lib64/libasan.so.6+0xb0887)
#1 0x7fa1144ad8f0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x588f0)
#2 0x561e3c9c8897 in qmp_object_add
/home/elmarco/src/qemu/qom/qom-qmp-cmds.c:291
#3
On Wed, 25 Mar 2020 16:03:39 +0100
Gerd Hoffmann wrote:
> On Wed, Mar 25, 2020 at 01:32:12PM +0100, Igor Mammedov wrote:
> > On Thu, 19 Mar 2020 09:01:04 +0100
> > Gerd Hoffmann wrote:
> >
> > > I know that not supporting ACPI in microvm is intentional. If you still
> > > don't want ACPI
On Fri, 6 Mar 2020 17:41:29 +0800
Yan Zhao wrote:
> the start address passing to
> cpu_physical_memory_set_dirty_range() and
> cpu_physical_memory_set_dirty_lebitmap() is the address within the
> ram block plus ram block offset.
>
> it's safe to set this start address to gpa if total memory is
On Wed, Mar 25, 2020 at 05:52:20PM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > Provide a helper kvm_slot_get_dirty_log() to make the function
> > kvm_physical_sync_dirty_bitmap() clearer. We can even cache the as_id
> > into KVMSlot when it is created, so that
On Thu, 26 Mar 2020 00:29:06 +1000
Nicholas Piggin wrote:
> Try to be tolerant of FWNMI delivery errors if the machine check had been
> recovered by the host.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/ppc/spapr_events.c | 27 ++-
> 1 file changed, 22 insertions(+),
I wrote blog post about it: https://marcin.juszkiewicz.com.pl/2020/03/25
/sharing-pcie-cards-across-architectures/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1869006
Title:
PCIe cards
On Tue, Mar 17, 2020 at 9:21 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 13
> target/riscv/insn32.decode | 4
>
On Tue, Mar 17, 2020 at 10:09 AM LIU Zhiwei wrote:
>
> Vector extension is default off. The only way to use vector extension is
> 1. use cpu rv32 or rv64
> 2. turn on it by command line
> "-cpu rv64,x-v=true,vlen=128,elen=64,vext_spec=v0.7.1".
>
> vlen is the vector register length, default value
On Tue, Mar 17, 2020 at 9:11 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 16 +
> target/riscv/insn32.decode | 5 +++
>
* Peter Xu (pet...@redhat.com) wrote:
> Provide a helper kvm_slot_get_dirty_log() to make the function
> kvm_physical_sync_dirty_bitmap() clearer. We can even cache the as_id
> into KVMSlot when it is created, so that we don't even need to pass it
> down every time.
>
> Since at it, remove
On Mon, Mar 23, 2020 at 12:55 PM Marc-André Lureau
wrote:
>
> On Mon, Mar 23, 2020 at 12:30 PM Philippe Mathieu-Daudé
> wrote:
> >
> > Document that virtqueue_pop() returned memory must be released
> > with free().
> >
> > Signed-off-by: Philippe Mathieu-Daudé
>
> Reviewed-by: Marc-André Lureau
Am 25.03.2020 um 18:23 hat Kevin Wolf geschrieben:
> The recent fix didn't actually fix the whole problem. Operations can't
> only wait for themselves, but we can also end up with circular
> dependencies like two operations waiting for each other to complete.
>
> This reverts the first fix and
On Tue, Mar 17, 2020 at 8:51 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 22
> target/riscv/insn32.decode | 7
>
On Wed, Mar 18, 2020 at 3:54 PM Alistair Francis
wrote:
>
> Add support for host and target futex_time64. If futex_time64 exists on
> the host we try that first before falling back to the standard futux
> syscall.
>
> Signed-off-by: Alistair Francis
@Laurent did you see this?
I guess it's a
That's an awkward flaw in the IOMMU design :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1869006
Title:
PCIe cards passthrough to TCG guest works on 2GB of guest memory but
fails on 4GB
* Peter Xu (pet...@redhat.com) wrote:
> Previously we have two places that will create the per KVMSlot dirty
> bitmap:
>
> 1. When a newly created KVMSlot has dirty logging enabled,
> 2. When the first log_sync() happens for a memory slot.
>
> The 2nd case is lazy-init, while the 1st case is
On Tue, Mar 17, 2020 at 8:43 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 33 +
> target/riscv/insn32.decode | 8 ++
> target/riscv/insn_trans/trans_rvv.inc.c | 10 ++
>
On Wed, Feb 05, 2020 at 09:17:41AM -0500, Peter Xu wrote:
> kvm_vm_ioctl() handles the errno trick already for ioctl() on
> returning -1 for errors. Fix this.
>
> Signed-off-by: Peter Xu
> ---
> accel/kvm/kvm-all.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git
On Tue, Mar 17, 2020 at 8:39 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 57 +++
> target/riscv/insn32.decode | 20
>
On 3/25/20 12:23 PM, Kevin Wolf wrote:
mirror_wait_for_free_in_flight_slot() just picks a random operation to
wait for. However, a MirrorOp is already in s->ops_in_flight when
mirror_co_read() waits for free slots, so if not enough slots are
immediately available, an operation can end up waiting
On 3/25/20 12:23 PM, Kevin Wolf wrote:
This reverts commit 7e6c4ff792734e196c8ca82564c56b5e7c6288ca.
The fix was incomplete as it only protected against requests waiting for
themselves, but not against requests waiting for each other. We need a
different solution.
Signed-off-by: Kevin Wolf
On Tue, Mar 17, 2020 at 8:49 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 33 ++
> target/riscv/insn32.decode | 8 +++
>
On Wed, 25 Mar 2020 at 15:56, Paolo Bonzini wrote:
>
> On 25/03/20 03:32, Gavin Shan wrote:
> >>
> >
> > Marc-André, ping. Could you please review when you get a chance? Thanks in
> > advance :)
>
> Or Peter; generally arch-specific changes (as opposed to fixes in
> chardev API usage) are
On Tue, Mar 17, 2020 at 8:47 AM LIU Zhiwei wrote:
>
> Signed-off-by: LIU Zhiwei
> Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/helper.h | 19 +
> target/riscv/insn32.decode | 6 +++
>
mirror_wait_for_free_in_flight_slot() just picks a random operation to
wait for. However, a MirrorOp is already in s->ops_in_flight when
mirror_co_read() waits for free slots, so if not enough slots are
immediately available, an operation can end up waiting for itself, or
two or more operations
On Thu, 26 Mar 2020 00:29:05 +1000
Nicholas Piggin wrote:
> Add some messages which explain problems and guest misbehaviour that
> may be difficult to diagnose in rare cases of machine checks.
>
> Signed-off-by: Nicholas Piggin
> ---
Reviewed-by: Greg Kurz
> hw/ppc/spapr_events.c | 4
This reverts commit 7e6c4ff792734e196c8ca82564c56b5e7c6288ca.
The fix was incomplete as it only protected against requests waiting for
themselves, but not against requests waiting for each other. We need a
different solution.
Signed-off-by: Kevin Wolf
---
block/mirror.c | 21
The recent fix didn't actually fix the whole problem. Operations can't
only wait for themselves, but we can also end up with circular
dependencies like two operations waiting for each other to complete.
This reverts the first fix and implements another approach.
Kevin Wolf (2):
Revert "mirror:
1 - 100 of 356 matches
Mail list logo
