virtfs: error out gracefully when mandatory suboptions are missing
We internally convert -virtfs to -fsdev/-device. If the user doesn't
provide the path or security_model suboptions, and the fsdev backend
requires them, we hit an assertion when populating the internal -fsdev
option:
Let's test the suboption presence on the command line before trying
to set it in the internal -fsdev option, and let the backend code
error out gracefully (ie, like it already does when the user passes
-fsdev on the command line).
Reported-by: Thomas Huth <email address hidden>
Signed-off-by: Greg Kurz <email address hidden>
Reviewed-by: Thomas Huth <email address hidden>
(cherry picked from commit 32b6943699948f7adc35ada233fbd25daffad5e9)
Signed-off-by: Michael Roth <email address hidden>
For "ldp x0, x1, [x0]", if the second load is on a second page and
the second page is unmapped, the exception would be raised with x0
already modified. This means the instruction couldn't be restarted.
Cc: <email address hidden>
Cc: <email address hidden>
Reported-by: Andrew <email address hidden>
Signed-off-by: Richard Henderson <email address hidden>
Message-id: <email address hidden>
Fixes: https://bugs.launchpad.net/qemu/+bug/1713066
Signed-off-by: Richard Henderson <email address hidden>
[PMM: tweaked comment format]
Reviewed-by: Peter Maydell <email address hidden>
Signed-off-by: Peter Maydell <email address hidden>
(cherry picked from commit 3e4d91b94ce400326fae0850578d9e9f30a71adb)
Signed-off-by: Michael Roth <email address hidden>
Commit 04bf2526ce87f21b32c9acba1c5518708c243ad0 (exec: use
qemu_ram_ptr_length to access guest ram) start using qemu_ram_ptr_length
instead of qemu_map_ram_ptr, but when used with Xen, the behavior of
both function is different. They both call xen_map_cache, but one with
"lock", meaning the mapping of guest memory is never released
implicitly, and the second one without, which means, mapping can be
release later, when needed.
In the context of address_space_{read,write}_continue, the ptr to those
mapping should not be locked because it is used immediatly and never
used again.
The lock parameter make it explicit in which context qemu_ram_ptr_length
is called.
Signed-off-by: Anthony PERARD <email address hidden>
Message-Id: <email address hidden>
Reviewed-by: Stefano Stabellini <email address hidden>
Signed-off-by: Paolo Bonzini <email address hidden>
(cherry picked from commit f5aa69bdc3418773f26747ca282c291519626ece)
Signed-off-by: Michael Roth <email address hidden>
2f64063...
by
Stefano Stabellini <email address hidden>
xen/mapcache: store dma information in revmapcache entries for debugging
The Xen mapcache is able to create long term mappings, they are called
"locked" mappings. The third parameter of the xen_map_cache call
specifies if a mapping is a "locked" mapping.
>From the QEMU point of view there are two kinds of long term mappings:
[a] device memory mappings, such as option roms and video memory
[b] dma mappings, created by dma_memory_map & friends
After certain operations, ballooning a VM in particular, Xen asks QEMU
kindly to destroy all mappings. However, certainly [a] mappings are
present and cannot be removed. That's not a problem as they are not
affected by balloonning. The *real* problem is that if there are any
mappings of type [b], any outstanding dma operations could fail. This is
a known shortcoming. In other words, when Xen asks QEMU to destroy all
mappings, it is an error if any [b] mappings exist.
However today we have no way of distinguishing [a] from [b]. Because of
that, we cannot even print a decent warning.
This patch introduces a new "dma" bool field to MapCacheRev entires, to
remember if a given mapping is for dma or is a long term device memory
mapping. When xen_invalidate_map_cache is called, we print a warning if
any [b] mappings exist. We ignore [a] mappings.
Mappings created by qemu_map_ram_ptr are assumed to be [a], while
mappings created by address_space_map->qemu_ram_ptr_length are assumed
to be [b].
The goal of the patch is to make debugging and system understanding
easier.
Signed-off-by: Stefano Stabellini <email address hidden>
Acked-by: Paolo Bonzini <email address hidden>
Acked-by: Anthony PERARD <email address hidden>
(cherry picked from commit 1ff7c5986a515d2d936eba026ff19947bbc7cb92)
Signed-off-by: Michael Roth <email address hidden>
When accessing guest's ram block during DMA operation, use
'qemu_ram_ptr_length' to get ram block pointer. It ensures
that DMA operation of given length is possible; And avoids
any OOB memory access situations.
Reported-by: Alex <email address hidden>
Signed-off-by: Prasad J Pandit <email address hidden>
Message-Id: <email address hidden>
Signed-off-by: Paolo Bonzini <email address hidden>
(cherry picked from commit 04bf2526ce87f21b32c9acba1c5518708c243ad0)
Signed-off-by: Michael Roth <email address hidden>
xhci: only update dequeue ptr on completed transfers
The dequeue pointer should only be updated in case the transfer
is actually completed. If we update it for inflight transfers
we will not pick them up again after migration, which easily
triggers with HID devices as they typically have a pending
transfer, waiting for user input to happen.
vl.c/exit: pause cpus before closing block devices
There's a rare exit seg if the guest is accessing
IO during exit.
It's always hitting the atomic_inc(&bs->in_flight) with a NULL
bs. This was added recently in 99723548 but I don't see it
as the cause.
Flip vl.c around so we pause the cpus before closing the block devices,
that way we shouldn't have anything trying to access them when
they're gone.
Previous submodule commit contained some unused files with comments
that made redistribution requirements unclear, and the submodule commit
should really match the blob we're shipped anyway.
Suggested-by: Peter Maydell <email address hidden>
Signed-off-by: Michael Roth <email address hidden>
