This macro is used by various commands (compare, convert, rebase) but it
is defined somewhere in the middle of the file. I'm going to use it in
the new checksum command so lets clean up a bit before that.
---
qemu-img.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/qemu-img
Extend the test finder to find tests with format (*.out.qcow2) or cache
specific (*.out.nocache) out file. This worked before only for the
numbered tests.
---
tests/qemu-iotests/findtests.py | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/findtests
Add simple tests computing a checksum for image with all kinds of
extents in raw and qcow2 formats.
The test can be extended later for other formats, format options (e..g
compressed qcow2), protocols (e.g. nbd), and image with a backing chain,
but I'm not sure this is really needed.
To help debug
Since blkhash is available only via copr now, the new command is added as
optional feature, built only if blkhash-devel package is installed.
Changes since v1 (Hanna):
- Move IO_BUF_SIZE to top of the file
- Extend TestFinder to support format or cache specific out files
- Improve online help (not
Add coroutine based loop inspired by `qemu-img convert` design.
Changes compared to `qemu-img convert`:
- State for the entire image is kept in ImgChecksumState
- State for single worker coroutine is kept in ImgChecksumworker.
- "Writes" are always in-order, ensured using a queue.
- Calling bl
The checksum command compute a checksum for disk image content using the
blkhash library[1]. The blkhash library is not packaged yet, but it is
available via copr[2].
Example run:
$ ./qemu-img checksum -p fedora-35.qcow2
6e5c00c995056319d52395f8d91c7f84725ae3da69ffcba4de4c7d22cff713a5
f
On Monday, November 28, 2022 11:18:48 AM CET Markus Armbruster wrote:
> Greg Kurz writes:
>
> > On Mon, 28 Nov 2022 08:35:22 +0100
> > Markus Armbruster wrote:
> >
> >> Greg Kurz writes:
> >>
> >> > The qemu_v9fs_synth_mkdir() and qemu_v9fs_synth_add_file() functions
> >> > currently return a
This is a dump of all minor coroutine-related fixes found while looking
around and testing various things in the QEMU block layer.
Patches aim to:
- add missing coroutine_fn annotation to the functions
- simplify to avoid the typical "if in coroutine: fn()
// else create_coroutine(fn)" already p
We know that the string will stay around until the function
returns, and the parameter of drv->bdrv_co_create_opts is const char*,
so it must not be modified either.
Suggested-by: Kevin Wolf
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievs
Call two different functions depending on whether bdrv_create
is in coroutine or not, following the same pattern as
generated_co_wrapper functions.
This allows to also call the coroutine function directly,
without using CreateCo or relying in bdrv_create().
Signed-off-by: Emanuele Giuseppe Esposi
bdrv_common_block_status_above() is a g_c_w, and it is being called by
many "wrapper" functions like bdrv_is_allocated(),
bdrv_is_allocated_above() and bdrv_block_status_above().
Because we want to eventually split the coroutine from non-coroutine
case in g_c_w, create duplicate wrappers that take
Right now, we take the first parameter of the function to get the
BlockDriverState to pass to bdrv_poll_co(), that internally calls
functions that figure in which aiocontext the coroutine should run.
However, it is useless to pass a bs just to get its own AioContext,
so instead pass it directly, a
These functions end up calling bdrv_*() implemented as generated_co_wrapper
functions.
In addition, they also happen to be always called in coroutine context,
meaning all callers are coroutine_fn.
This means that the g_c_w function will enter the qemu_in_coroutine()
case and eventually suspend (or
This new annotation starts just a function wrapper that creates
a new coroutine. It assumes the caller is not a coroutine.
It will be the default annotation to be used in the future.
This is much better as c_w_mixed, because it is clear if the caller
is a coroutine or not, and provides the advanta
These functions end up calling bdrv_create() implemented as generated_co_wrapper
functions.
In addition, they also happen to be always called in coroutine context,
meaning all callers are coroutine_fn.
This means that the g_c_w function will enter the qemu_in_coroutine()
case and eventually suspend
bdrv_can_store_new_dirty_bitmap and bdrv_remove_persistent_dirty_bitmap
check if they are running in a coroutine, directly calling the
coroutine callback if it's the case.
Except that no coroutine calls such functions, therefore that check
can be removed, and function creation can be offloaded to
c
These functions end up calling bdrv_common_block_status_above(), a
generated_co_wrapper function.
In addition, they also happen to be always called in coroutine context,
meaning all callers are coroutine_fn.
This means that the g_c_w function will enter the qemu_in_coroutine()
case and eventually s
Avoid mixing bdrv_* functions with blk_*, so create blk_* counterparts
for bdrv_block_status_above and bdrv_is_allocated_above.
Note that since blk_co_block_status_above only calls the g_c_w function
bdrv_common_block_status_above and is marked as coroutine_fn, call
directly bdrv_co_common_block_s
It is always called in coroutine_fn callbacks, therefore
it can directly call bdrv_co_create().
Rename it to bdrv_co_create_file too.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
include/block/block-global-state.h | 3 ++-
blo
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> We compile pci-hmp-cmds.c always, but pci-qmp-cmds.c only when
> >> CONFIG_PCI. hw/pci/pci-stub.c keeps the linker happy when
> >> !CONFIG_PCI. Build pci-h
Extend the regex to cover also return type, pointers included.
This implies that the value returned by the function cannot be
a simple "int" anymore, but the custom return type.
Therefore remove poll_state->ret and instead use a per-function
custom "ret" field.
Signed-off-by: Emanuele Giuseppe Esp
In preparation to the incoming new function specifiers,
rename g_c_w with a more meaningful name and document it.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
docs/devel/block-coroutine-wrapper.rst | 6 +--
block/coroutines.h | 4
This function is never called in coroutine context, therefore
instead of manually creating a new coroutine, delegate it to the
block-coroutine-wrapper script, defining it as co_wrapper.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
-
Thomas Huth writes:
> These #includes are not required anymore (the likely got superfluous
> with commit da76ee76f7 - "hmp-commands-info: move info_cmds content
> out of monitor.c").
>
> Signed-off-by: Thomas Huth
Appreciated!
Reviewed-by: Markus Armbruster
From: Gregory Price
Remove usage of magic numbers when accessing capacity fields and replace
with CXL_CAPACITY_MULTIPLIER, matching the kernel definition.
Signed-off-by: Gregory Price
Reviewed-by: Davidlohr Bueso
Signed-off-by: Jonathan Cameron
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl
Changes in this version
* Minor bug fixes spotted by J. Cameron
* Whitespace changes to docs and tests moved ahead of patch
* Address Space access to pmem region is now as(dpa-vmem_len)
Note: Submitted as an extention to the CDAT emulation because the CDAT DSMAS
entry concerns memory m
Defines are starting to exceed line length limits, align them for
cleanliness before making modifications.
Signed-off-by: Gregory Price
---
tests/qtest/cxl-test.c | 99 +++---
1 file changed, 54 insertions(+), 45 deletions(-)
diff --git a/tests/qtest/cxl-tes
From: Gregory Price
This commit enables each CXL Type-3 device to contain one volatile
memory region and one persistent region.
Two new properties have been added to cxl-type3 device initialization:
[volatile-memdev] and [persistent-memdev]
The existing [memdev] property has been deprecated
> @@ -228,7 +230,7 @@ static void qxl_unpack_chunks(void *dest, size_t size,
> PCIQXLDevice *qxl,
> if (offset == size) {
> return;
> }
> -chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id);
> +chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_
On Mon, 28 Nov 2022 at 08:53, Philippe Mathieu-Daudé wrote:
>
> Have qxl_get_check_slot_offset() return false if the requested
> buffer size does not fit within the slot memory region.
>
> Similarly qxl_phys2virt() now returns NULL in such case, and
> qxl_dirty_one_surface() aborts.
>
> This avoid
On Mon, 28 Nov 2022 at 08:50, Philippe Mathieu-Daudé wrote:
>
> Since v1:
> - Addressed Marc-André review comments
> - Moved overrun check in qxl_get_check_slot_offset()
>
> memory_region_get_ram_ptr() returns a host pointer for a
> MemoryRegion. Sometimes we do offset calculation using this
> poi
On 28/11/22 16:16, Stefan Hajnoczi wrote:
On Mon, 28 Nov 2022 at 08:53, Philippe Mathieu-Daudé wrote:
Have qxl_get_check_slot_offset() return false if the requested
buffer size does not fit within the slot memory region.
Similarly qxl_phys2virt() now returns NULL in such case, and
qxl_dirty_o
On Mon, 28 Nov 2022 at 10:25, Philippe Mathieu-Daudé wrote:
>
> On 28/11/22 16:16, Stefan Hajnoczi wrote:
> > On Mon, 28 Nov 2022 at 08:53, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Have qxl_get_check_slot_offset() return false if the requested
> >> buffer size does not fit within the slot mem
On 28/11/22 16:08, Gerd Hoffmann wrote:
@@ -228,7 +230,7 @@ static void qxl_unpack_chunks(void *dest, size_t size,
PCIQXLDevice *qxl,
if (offset == size) {
return;
}
-chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id);
+chunk = qxl_phys2virt
On 28/11/22 16:32, Stefan Hajnoczi wrote:
On Mon, 28 Nov 2022 at 10:25, Philippe Mathieu-Daudé wrote:
On 28/11/22 16:16, Stefan Hajnoczi wrote:
On Mon, 28 Nov 2022 at 08:53, Philippe Mathieu-Daudé wrote:
Have qxl_get_check_slot_offset() return false if the requested
buffer size does not fi
On Mon, 28 Nov 2022 at 10:46, Philippe Mathieu-Daudé wrote:
>
> On 28/11/22 16:32, Stefan Hajnoczi wrote:
> > On Mon, 28 Nov 2022 at 10:25, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> On 28/11/22 16:16, Stefan Hajnoczi wrote:
> >>> On Mon, 28 Nov 2022 at 08:53, Philippe Mathieu-Daudé
> >>> wro
On Mon, Nov 28, 2022 at 04:41:14PM +0100, Philippe Mathieu-Daudé wrote:
> On 28/11/22 16:08, Gerd Hoffmann wrote:
> > > @@ -228,7 +230,7 @@ static void qxl_unpack_chunks(void *dest, size_t
> > > size, PCIQXLDevice *qxl,
> > > if (offset == size) {
> > > return;
> > >
Markus Armbruster wrote:
> Cc: Fam Zheng
> Cc: Kevin Wolf
> Cc: Hanna Reitz
> Cc: qemu-bl...@nongnu.org
> Signed-off-by: Markus Armbruster
> Reviewed-by: Peter Maydell
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Juan Quintela
goto, uninitialized variable at declaraton and can use r
Markus Armbruster wrote:
> Suggested-by: BALATON Zoltan
> Signed-off-by: Markus Armbruster
> Reviewed-by: BALATON Zoltan
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Juan Quintela
On 28/11/22 16:41, Philippe Mathieu-Daudé wrote:
On 28/11/22 16:08, Gerd Hoffmann wrote:
Also at least one code path (processing SPICE_CURSOR_TYPE_MONO in
qxl_cursor) goes access chunk.data[] without calling
qxl_unpack_chunks(), that needs additional verification too (or
switch it to call qxl_
Daniel P. Berrangé wrote:
> On Fri, Nov 25, 2022 at 09:30:54AM +0100, Thomas Huth wrote:
>> When running the migration test compiled with Clang from Fedora 37
>> and sanitizers enabled, there is an error complaining about unlink():
>>
>> ../tests/qtest/migration-test.c:1072:12: runtime error: nu
On 28/11/22 17:18, Philippe Mathieu-Daudé wrote:
On 28/11/22 16:41, Philippe Mathieu-Daudé wrote:
On 28/11/22 16:08, Gerd Hoffmann wrote:
Also at least one code path (processing SPICE_CURSOR_TYPE_MONO in
qxl_cursor) goes access chunk.data[] without calling
qxl_unpack_chunks(), that needs addi
Hi,
Hopefully this is the final iteration to fix the vhost-user issues
that are currently plaguing the release. I've prevented the circular
closing for the vhost_dev structure by generalising the solution used
by virtio-user-blk which punts the close off to an aio instance.
The memory leak from:
..and use for both virtio-user-blk and virtio-user-gpio. This avoids
the circular close by deferring shutdown due to disconnection until a
later point. virtio-user-blk already had this mechanism in place so
generalise it as a vhost-user helper function and use for both blk and
gpio devices.
While
There was a disconnect here because vdev->host_features was set to
random rubbish. This caused a weird negotiation between the driver and
device that took no account of the features provided by the backend.
To fix this we must set vdev->host_features once we have initialised
the vhost backend.
[AJ
From: Stefano Garzarella
Commit 02b61f38d3 ("hw/virtio: incorporate backend features in features")
properly negotiates VHOST_USER_F_PROTOCOL_FEATURES with the vhost-user
backend, but we forgot to enable vrings as specified in
docs/interop/vhost-user.rst:
If ``VHOST_USER_F_PROTOCOL_FEATURES``
As per the fix to vhost-user-blk in f5b22d06fb (vhost: recheck dev
state in the vhost_migration_log routine) we really should track the
connection and starting separately.
Signed-off-by: Alex Bennée
---
include/hw/virtio/vhost-user-gpio.h | 10 ++
hw/virtio/vhost-user-gpio.c | 11
The GPIO device is a VIRTIO_F_VERSION_1 devices but running with a
legacy MMIO interface we miss out that feature bit causing confusion.
For the GPIO test force the mmio bus to support non-legacy so we can
properly test it.
Signed-off-by: Alex Bennée
Resolves: https://gitlab.com/qemu-project/qemu
The VM status should always preempt the device status for these
checks. This ensures the device is in the correct state when we
suspend the VM prior to migrations. This restores the checks to the
order they where in before the refactoring moved things around.
While we are at it lets improve our do
We have a bunch of variables associated with the device and the vhost
backend which are used inconsistently throughout the code base. Lets
start trying to bring some order by agreeing what each variable is
for.
Signed-off-by: Alex Bennée
Cc: Stefano Garzarella
Cc: "Michael S. Tsirkin"
Cc: Stefa
Thomas Huth writes:
> Print a simple help text if the script has been called with the
> wrong amount of parameters.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Alex Bennée
--
Alex Bennée
On 28/11/22 17:29, Philippe Mathieu-Daudé wrote:
On 28/11/22 17:18, Philippe Mathieu-Daudé wrote:
On 28/11/22 16:41, Philippe Mathieu-Daudé wrote:
On 28/11/22 16:08, Gerd Hoffmann wrote:
Also at least one code path (processing SPICE_CURSOR_TYPE_MONO in
qxl_cursor) goes access chunk.data[] wi
On Mon, 28 Nov 2022 at 04:28, Thomas Huth wrote:
>
> Our current release tarballs are huge and caused already some trouble
> with the server traffic in the past. However, the biggest chunk (~80%)
> of the tarball is caused by the firmware sources - which most users
> don't need anyway (assuming th
Thomas Huth writes:
> Using --single-branch and --depth 1 here helps to speed up the process
> a little bit and helps to save some networking bandwidth.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Alex Bennée
--
Alex Bennée
This is great. It will reduce qemu.org's network bandwidth consumption
and make QEMU release tarballs nicer to use due to reduced size.
I left a comment because I don't like patching the roms/ directory,
but if I'm the only one who doesn't like it then feel free to keep
that approach.
Reviewed-by
Thomas Huth writes:
> These files are of no use in a normal tarball and thus should not
> be included here.
>
> Signed-off-by: Thomas Huth
> ---
> scripts/make-release | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/make-release b/scripts/make-release
> in
Thomas Huth writes:
> We're going to ship the contents of the "roms" folder as a separate
> tarball, so we should have at least a short README in this folder
> for this.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Alex Bennée
--
Alex Bennée
Thomas Huth writes:
> Our current release tarballs are huge and caused already some trouble
> with the server traffic in the past. However, the biggest chunk (~80%)
> of the tarball is caused by the firmware sources - which most users
> don't need anyway (assuming that they just want to compile
On Mon, Nov 28, 2022 at 10:25:50AM +0100, Thomas Huth wrote:
> Our release tarballs are huge - qemu-7.2.0-rc2.tar.xz has a size of 116
> MiB. If you look at the contents, approx. 80% of the size is used for the
> firmware sources that we ship along to provide the sources for the ROM
> binaries. Thi
On Mon, Nov 28, 2022 at 04:41:00PM +, Alex Bennée wrote:
> The VM status should always preempt the device status for these
> checks. This ensures the device is in the correct state when we
> suspend the VM prior to migrations. This restores the checks to the
> order they where in before the ref
The 9p test cases use a dedicated, lite-weight 9p client implementation
(using virtio transport) under tests/qtest/libqos/ to communicate with
QEMU's 9p server.
It's already there for a long time. Let's officially assign it to 9p
maintainers.
Signed-off-by: Christian Schoenebeck
---
MAINTAINERS
On Mon, Nov 28, 2022 at 05:42:43PM +0800, Chuang Xu wrote:
>
> On 2022/11/25 上午12:40, Peter Xu wrote:
> > On Fri, Nov 18, 2022 at 04:36:48PM +0800, Chuang Xu wrote:
> > > The duration of loading non-iterable vmstate accounts for a significant
> > > portion of downtime (starting with the timestamp
On Sat, Nov 26, 2022 at 11:15:14AM +, Marc Zyngier wrote:
> > Physical hardware doesn't do this, virtual emulation shouldn't either.
>
> If you want to fix VFIO, be my guest. My rambling about the sorry
> state of this has been in the kernel for 5 years (ed8703a506a8).
We are talking about t
On 28/11/22 18:12, Christian Schoenebeck wrote:
The 9p test cases use a dedicated, lite-weight 9p client implementation
(using virtio transport) under tests/qtest/libqos/ to communicate with
QEMU's 9p server.
It's already there for a long time. Let's officially assign it to 9p
maintainers.
Sign
Hi Peter,
On 11/9/22 17:14, Peter Maydell wrote:
> Convert the TYPE_ARM_SMMUV3 device to 3-phase reset. The legacy
> reset method doesn't do anything that's invalid in the hold phase, so
> the conversion only requires changing it to a hold phase method, and
> using the 3-phase versions of the "sa
Hi Peter,
On 11/9/22 17:14, Peter Maydell wrote:
> Convert the TYPE_ARM_SMMU device to 3-phase reset. The legacy method
> doesn't do anything that's invalid in the hold phase, so the
> conversion is simple and not a behaviour change.
>
> Note that we must convert this base class before we can co
On Mon, 28 Nov 2022 at 11:42, Alex Bennée wrote:
>
> There was a disconnect here because vdev->host_features was set to
> random rubbish. This caused a weird negotiation between the driver and
> device that took no account of the features provided by the backend.
> To fix this we must set vdev->ho
* Marc Hartmayer (mhart...@linux.ibm.com) wrote:
> The virtiofsd currently crashes on s390x. This is because of a
> `sigreturn` system call. See audit log below:
>
> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0
> ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1
On Thu, 24 Nov 2022 14:41:00 +0200
Avihai Horon wrote:
> On 20/11/2022 11:34, Avihai Horon wrote:
> >
> > On 17/11/2022 19:38, Alex Williamson wrote:
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> On Thu, 17 Nov 2022 19:07:10 +0200
> >> Avihai Horon wrote:
> >>>
On Tue, 8 Nov 2022 at 02:35, Schspa Shi wrote:
>
> We use 32bit value for linux,initrd-[start/end], when we have
> loader_start > 4GB, there will be a wrong initrd_start passed
> to the kernel, and the kernel will report the following warning
> To fix it, we can change it to u64 type.
>
> Signed-
Il lun 28 nov 2022, 18:04 Daniel P. Berrangé ha
scritto:
> With my distro maintainer hat I would rather QEMU ship neither the
> ROM source, nor the ROM binaries.
>
Annd since QEMU can finally cross compile its embedded firmware modules,
too, it is now easier for distros not to use any prebuilt b
On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wrote:
> There's a claim here about added complexity that I'm not really seeing.
> It looks like we simply make an ioctl call here and scale our buffer
> based on the minimum of the returned device estimate or our upper
> bound.
I'm not ke
Stefan Hajnoczi writes:
> On Mon, 28 Nov 2022 at 11:42, Alex Bennée wrote:
>>
>> There was a disconnect here because vdev->host_features was set to
>> random rubbish. This caused a weird negotiation between the driver and
>> device that took no account of the features provided by the backend.
On Thu, Nov 24, 2022 at 5:17 AM Conor Dooley wrote:
>
> On Wed, Aug 24, 2022 at 03:17:00PM -0700, Atish Patra wrote:
> > Qemu virt machine can support few cache events and cycle/instret counters.
> > It also supports counter overflow for these events.
> >
> > Add a DT node so that OpenSBI/Linux ke
Since v2:
- Do not abort checking guest-provided addresses (Stefan)
- Handle chunked QEMUCursor (Gerd)
Since v1:
- Moved overrun check in qxl_get_check_slot_offset (Marc-André)
memory_region_get_ram_ptr() returns a host pointer for a
MemoryRegion. Sometimes we do offset calculation using this
poi
Reviewed-by: Marc-André Lureau
Signed-off-by: Philippe Mathieu-Daudé
---
hw/display/qxl.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/hw/display/qxl.h b/hw/display/qxl.h
index e74de9579d..78b3a6c9ba 100644
--- a/hw/display/qxl.h
+++ b/hw/display/qxl.h
@@ -147,6 +147,
Currently qxl_phys2virt() doesn't check for buffer overrun.
In order to do so in the next commit, pass the buffer size
as argument.
For QXLCursor in qxl_render_cursor() -> qxl_cursor() we
verify the size of the chunked data ahead, checking we can
access 'sizeof(QXLCursor) + chunk->data_size' bytes
Have qxl_get_check_slot_offset() return false if the requested
buffer size does not fit within the slot memory region.
Similarly qxl_phys2virt() now returns NULL in such case, and
qxl_dirty_one_surface() aborts.
This avoids buffer overrun in the host pointer returned by
memory_region_get_ram_ptr(
Signed-off-by: Philippe Mathieu-Daudé
---
hw/display/qxl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 0b21626aad..6772849dec 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -1384,6 +1384,7 @@ static int qxl_add_memslot(PCIQXLDevice *d, ui
Only 3 command types are logged: no need to call qxl_phys2virt()
for the other types. Using different cases will help to pass
different structure sizes to qxl_phys2virt() in a pair of commits.
Reviewed-by: Marc-André Lureau
Signed-off-by: Philippe Mathieu-Daudé
---
hw/display/qxl-logger.c | 11
On 11/24/22 02:51, Nicholas Miehlbradt wrote:
Define the DEXCR and HDEXCR as special purpose registers.
Each register occupies two SPR indicies, one which can be read in an
unprivileged state and one which can be modified in the appropriate
priviliged state, however both indicies refer to the
On 11/24/22 02:51, Nicholas Miehlbradt wrote:
Adds checks to the hashst and hashchk instructions to only execute if
enabled by the relevant aspect in the DEXCR and HDEXCR.
This behaviour is guarded behind TARGET_PPC64 since Power10 is
currently the only implementation which has the DEXCR.
Si
On Mon, 28 Nov 2022 15:40:23 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wrote:
>
> > There's a claim here about added complexity that I'm not really seeing.
> > It looks like we simply make an ioctl call here and scale our buffer
> > based on the min
On 28/11/2022 20:16, Atish Kumar Patra wrote:
> On Thu, Nov 24, 2022 at 5:17 AM Conor Dooley
> wrote:
>>
>> On Wed, Aug 24, 2022 at 03:17:00PM -0700, Atish Patra wrote:
>>> Qemu virt machine can support few cache events and cycle/instret counters.
>>> It also supports counter overflow for these e
On Mon, Nov 28, 2022 at 12:38 PM wrote:
>
> On 28/11/2022 20:16, Atish Kumar Patra wrote:
> > On Thu, Nov 24, 2022 at 5:17 AM Conor Dooley
> > wrote:
> >>
> >> On Wed, Aug 24, 2022 at 03:17:00PM -0700, Atish Patra wrote:
> >>> Qemu virt machine can support few cache events and cycle/instret coun
On Mon, Nov 28, 2022 at 01:36:30PM -0700, Alex Williamson wrote:
> On Mon, 28 Nov 2022 15:40:23 -0400
> Jason Gunthorpe wrote:
>
> > On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wrote:
> >
> > > There's a claim here about added complexity that I'm not really seeing.
> > > It looks l
Signed-off-by: Temuri Doghonadze
---
po/LINGUAS | 1 +
po/ka.po | 95 ++
2 files changed, 96 insertions(+)
create mode 100644 po/ka.po
diff --git a/po/LINGUAS b/po/LINGUAS
index 9b33a3659f..f3a9b1a802 100644
--- a/po/LINGUAS
+++ b/po/LINGUA
These patches extend QGA logging interface, primarily under Windows
guests. They enable QGA to write to Windows event log, much like
syslog() on *nix. In addition we get rid of hardcoded log level used by
ga_log().
Andrey Drobyshev (2):
qga-win: add logging to Windows event log
qga: map GLib
This patch translates GLib-specific log levels to system ones, so that
they may be used by both *nix syslog() (as a "priority" argument) and
Windows ReportEvent() (as a "wType" argument).
Currently the only codepath to write to "syslog" domain is slog()
function. However, this patch allows the in
This commit allows QGA to write to Windows event log using Win32 API's
ReportEvent() [1], much like syslog() under *nix guests.
In order to generate log message definitions we use a very basic message
text file [2], so that every QGA's message gets ID 1. The tools
"windmc" and "windres" respectiv
On Mon, 28 Nov 2022 16:56:39 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 28, 2022 at 01:36:30PM -0700, Alex Williamson wrote:
> > On Mon, 28 Nov 2022 15:40:23 -0400
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Nov 28, 2022 at 11:50:03AM -0700, Alex Williamson wrote:
> > >
> > > > There's a
On 28/11/2022 20:41, Atish Kumar Patra wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, Nov 28, 2022 at 12:38 PM wrote:
>>
>> On 28/11/2022 20:16, Atish Kumar Patra wrote:
>>> On Thu, Nov 24, 2022 at 5:17 AM Conor Dooley
>>> wrot
Cool, thanks for writing up your zoned block emulation work!
Reviewed-by: Stefan Hajnoczi
On Fri, Nov 11, 2022 at 06:08:11PM +1000, Richard Henderson wrote:
> Pack the quotient and remainder into a single uint64_t.
>
> Signed-off-by: Richard Henderson
> ---
> v2: Fix operand ordering; use tcg_extr32_i64.
> ---
> target/s390x/helper.h | 2 +-
> target/s390x/tcg/int_helper.c |
On Fri, Nov 11, 2022 at 06:08:17PM +1000, Richard Henderson wrote:
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Richard Henderson
> ---
> v2: Remove extraneous return_low128.
> ---
> target/s390x/helper.h| 22 +++---
> target/s390x/tcg/fpu_helper.c| 29 +
On Fri, Nov 11, 2022 at 06:08:18PM +1000, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> v2: Fix SPEC_in1_x1.
> ---
> target/s390x/helper.h| 32 ++--
> target/s390x/tcg/fpu_helper.c| 88 ++--
> target/s390x/tcg/translate.c
> On 28. 11. 2022., at 21:54, Andrey Drobyshev via
> wrote:
>
> This commit allows QGA to write to Windows event log using Win32 API's
> ReportEvent() [1], much like syslog() under *nix guests.
>
> In order to generate log message definitions we use a very basic message
> text file [2], so t
On Mon, 2022-11-28 at 20:29 +0800, Weiwei Li wrote:
> Modify the check for C extension to Zca (C implies Zca)
>
> Signed-off-by: Weiwei Li
> Signed-off-by: Junqiang Wang
> Reviewed-by: Richard Henderson
> Reviewed-by: Alistair Francis
> ---
> target/riscv/insn_trans/trans_rvi.c.inc | 4 ++--
>
On Fri, Nov 11, 2022 at 06:08:19PM +1000, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> target/s390x/helper.h| 2 --
> target/s390x/tcg/mem_helper.c| 52 ---
> target/s390x/tcg/translate.c | 60
>
On Fri, Nov 11, 2022 at 06:08:20PM +1000, Richard Henderson wrote:
> This case is trivial to implement inline.
>
> Signed-off-by: Richard Henderson
> ---
> target/s390x/tcg/translate.c | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Ilya Leoshkevich
101 - 200 of 237 matches
Mail list logo
