v2->v3: moved guest check into virtual_gif_enabled
VGIF allows STGI and CLGI to execute in guest mode and control virtual
interrupts in guest mode.
When the VGIF feature is enabled then:
* executing STGI in the guest sets bit 9 of the VMCB offset 60h.
* executing CLGI in the guest clears bit 9 o
Okay, it was found experimentally that the problem is reproduced if
vm.mmap_min_addr is greater than 53249. If from 0 to 53249 - everything
works. What can this be related to?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bu
I mean [0...52348] is working.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1891748
Title:
qemu-arm-static 5.1 can't run gcc
Status in QEMU:
Fix Released
Status in Juju Charms Collection:
New
>From source host viewpoint, losing a connection during migration will
cause the sockets to get stuck in sendmsg() syscall, waiting for
the receiving side to reply.
In migration, yank works by shutting-down the migration QIOChannel fd.
This causes a failure in the next sendmsg() for that fd, and t
Sorry, an error in previous message.
Fixed and detailed diagnostics:
[0... 53248] - working
[53249 ... 61440] - Cannot allocate memory
[61441 ... 65536 and higher] - Operation not permitted
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
On Thu, 29 Jul 2021 at 13:58, Gerd Hoffmann wrote:
>
> The following changes since commit f2da205cb4142259d9bc6b9d4596ebbe2426fe49:
>
> Update version for v6.1.0-rc1 release (2021-07-27 18:07:52 +0100)
>
> are available in the Git repository at:
>
> git://git.kraxel.org/qemu tags/usb-20210729-
Eduardo Habkost writes:
> When there's no specific class struct used for a QOM type, we
> normally don't define a typedef for it. Remove the typedef from
> the minimal example, as it is unnecessary.
>
> Signed-off-by: Eduardo Habkost
> ---
> docs/devel/qom.rst | 3 ---
> 1 file changed, 3 dele
On Fri, 30 Jul 2021 at 09:18, Markus Armbruster wrote:
>
> Eduardo Habkost writes:
>
> > When there's no specific class struct used for a QOM type, we
> > normally don't define a typedef for it. Remove the typedef from
> > the minimal example, as it is unnecessary.
> >
> > Signed-off-by: Eduardo
virtio-mem exposes a dynamic amount of memory within RAMBlocks by
coordinating with the VM. Memory within a RAMBlock can either get
plugged and consequently used by the VM, or unplugged and consequently no
longer used by the VM. Logical unplug is realized by discarding the
physical memory backing f
Implement it similar to the replay_populated callback.
Acked-by: Peter Xu
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 58 ++
1 file changed, 58 insertions(+)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index df91e454b2.
Introduce replay_discarded callback similar to our existing
replay_populated callback, to be used my migration code to never migrate
discarded memory.
Acked-by: Peter Xu
Signed-off-by: David Hildenbrand
---
include/exec/memory.h | 21 +
softmmu/memory.c | 11 +++
The parameter is unused, let's drop it.
Signed-off-by: David Hildenbrand
---
migration/ram.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 7a43bfd7af..bb908822d5 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -789
We don't want to migrate memory that corresponds to discarded ranges as
managed by a RamDiscardManager responsible for the mapped memory region of
the RAMBlock. The content of these pages is essentially stale and
without any guarantees for the VM ("logically unplugged").
Depending on the underlyin
We already don't ever migrate memory that corresponds to discarded ranges
as managed by a RamDiscardManager responsible for the mapped memory region
of the RAMBlock.
virtio-mem uses this mechanism to logically unplug parts of a RAMBlock.
Right now, we still populate zeropages for the whole usable
Migration code now properly handles RAMBlocks which are indirectly managed
by a RamDiscardManager. No need for manual handling via the free page
optimization interface, let's get rid of it.
Acked-by: Michael S. Tsirkin
Acked-by: Peter Xu
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-me
Currently, when someone (i.e., the VM) accesses discarded parts inside a
RAMBlock with a RamDiscardManager managing the corresponding mapped memory
region, postcopy will request migration of the corresponding page from the
source. The source, however, will never answer, because it refuses to
migrat
Hi,
On Thu, Jul 29, 2021 at 06:40:17PM +0200, Paolo Bonzini wrote:
> On 29/07/21 11:14, Gerd Hoffmann wrote:
> > The common functions could be added TCGCPUOps to allow them being called via
> > CPUClass->tcg_ops->$name instead of a direct symbol reference. Not sure
> > this
> > is a good idea
On Fri, Jul 30, 2021 at 09:43:55AM +0100, Peter Maydell wrote:
> On Fri, 30 Jul 2021 at 09:18, Markus Armbruster wrote:
> >
> > Eduardo Habkost writes:
> >
> > > When there's no specific class struct used for a QOM type, we
> > > normally don't define a typedef for it. Remove the typedef from
>
Hi,
> +/*
> + * VIRTIO_GPU_CMD_CREATE_CONTEXT with
> + * context_init
> + */
> +#define VIRTIO_GPU_F_CONTEXT_INIT4
Where is the virtio spec update for this?
take care,
Gerd
Hi,
> +/*
> + * shared memory
> + */
> +#define VIRTIO_GPU_F_HOSTMEM 5
Leftover from early interface design attempts.
The blob resources (with VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST)
should cover that now.
take care,
Gerd
> -virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem, 0);
> +virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
> VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
Squash that into patch #2
> --- a/include/standard-headers/linux/virtio_pci.h
> +++ b/include/standard-headers/linux/virtio
On Wed, Jul 28, 2021 at 03:46:31PM +0200, Antonio Caggiano wrote:
> Enable resource UUID feature and implement command resource assign UUID.
> For the moment, use the resource ID as UUID.
No, please do that properly right from start.
Needs a uuid -> resource-id table or hash in qemu. Alternative
Looks sane on a quick glance, but please have a more verbose commit
message. I can only guess this is a capset for vulkan support, but
readers of the patch should not need guess in the first place ;)
take care,
Gerd
On Wed, Jul 28, 2021 at 03:46:33PM +0200, Antonio Caggiano wrote:
> Enable VirGL unstable APIs and request Venus when initializing VirGL.
I guess having a runtime switch for that would be a good idea, and
probably have default it off while the API is unstable still.
take care,
Gerd
On 7/30/21 11:05 AM, Gerd Hoffmann wrote:
> Hi,
>
> On Thu, Jul 29, 2021 at 06:40:17PM +0200, Paolo Bonzini wrote:
>> On 29/07/21 11:14, Gerd Hoffmann wrote:
>>> The common functions could be added TCGCPUOps to allow them being called via
>>> CPUClass->tcg_ops->$name instead of a direct symbol r
Hi,
> +region = g_new0(MemoryRegion, 1);
> +memory_region_init_ram_device_ptr(region, OBJECT(g), NULL, size, data);
> +memory_region_add_subregion(&g->parent_obj.hostmem, mblob.offset,
> region);
> +memory_region_set_enabled(region, true);
You leak the region instead of properl
On Fri, 30 Jul 2021 at 04:08, Shuuichirou Ishii
wrote:
>
> The ARM_FEATURE_A64FX property was added,
> but there is no function that uses this property yet,
> so it will be removed until a function that uses it is added.
>
> Signed-off-by: Shuuichirou Ishii
> ---
> target/arm/cpu.h | 1 -
> ta
On Fri, 30 Jul 2021 at 04:08, Shuuichirou Ishii
wrote:
>
> Fix for patch consistency.
> https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg06993.html
Commit messages should describe what the patch is doing and why,
so the reader can understand it without having to cross-reference
old mailin
Shuuichirou Ishii writes:
> The ARM_FEATURE_A64FX property was added,
> but there is no function that uses this property yet,
> so it will be removed until a function that uses it is added.
>
> Signed-off-by: Shuuichirou Ishii
> ---
> target/arm/cpu.h | 1 -
> target/arm/cpu64.c | 1 -
> 2
On Fri, 30 Jul 2021 at 04:08, Shuuichirou Ishii
wrote:
>
> This is the v2 patch series.
>
> v2:
> No features have been added or removed from the v1 patch series. Removal
> of unused definitions that were added in excess, and consolidation of
> patches for the purpose of functional consistency.
>
When Hexagon was added we forgot to add it to the QEMU_ARCH_*
enumeration. This doesn't cause a visible effect because at the
moment Hexagon is linux-user only and the QEMU_ARCH_* constants are
only used in softmmu, but we might as well add it in, since it's the
only architecture currently missing
This patchset does some cleanups of arch_init.c. The bit I started
out caring about was getting rid of the TARGET_* ifdef ladder (in
patch 4 we make meson.build define QEMU_ARCH in config-target.h
instead) -- this kind of ifdef ladder is nasty because it's always
another place in the code that nee
The kvm_available() function reports whether KVM support was
compiled into the QEMU binary; it returns the value of the
CONFIG_KVM define.
The only place in the codebase where we use this function is
in qmp_query_kvm(). Now that accelerators are based on QOM
classes we can instead use accel_find("
Instead of using an ifdef ladder in arch_init.c (which we then have
to manually update every time we add or remove a target
architecture), have meson.build put "#define QEMU_ARCH QEMU_ARCH_FOO"
in the config-target.h file.
Signed-off-by: Peter Maydell
---
meson.build | 2 ++
softmmu/arc
arch_init.h only defines the QEMU_ARCH_* enumeration and the
arch_type global. Don't include it in files that don't use those.
Signed-off-by: Peter Maydell
---
blockdev.c| 1 -
hw/i386/pc.c | 1 -
hw/i386/pc_piix.c | 1 -
hw/i386/pc_q35.c | 1 -
hw/m
The xen_available() function is used only to produce an error
for some Xen-specific command line options in QEMU binaries where
Xen support was not compiled in: it just returns the value of
the CONFIG_XEN define.
Now that accelerators are QOM classes, we can check for
"does this binary have Xen co
The QEMU_ARCH_VIRTIO_* defines are used only in one file,
qdev-monitor.c. Move them to that file.
Signed-off-by: Peter Maydell
---
include/sysemu/arch_init.h | 9 -
softmmu/qdev-monitor.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/sysemu/arc
arch_init.c does very little but has a long list of #include lines.
Remove all the unnecessary ones.
Signed-off-by: Peter Maydell
---
softmmu/arch_init.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/softmmu/arch_init.c b/softmmu/arch_init.c
index 9011af74e4a..91cbf883e28 100644
---
On Thu, 29 Jul 2021 at 17:23, Stefan Hajnoczi wrote:
>
> The following changes since commit 3521ade3510eb5cefb2e27a101667f25dad89935:
>
> Merge remote-tracking branch
> 'remotes/thuth-gitlab/tags/pull-request-2021-07-29' into staging (2021-07-29
> 13:17:20 +0100)
>
> are available in the Git r
We added a stub for the arch_type global in commit 5964ed56d9a1 so
that we could compile blockdev.c into the tools. However, in commit
9db1d3a2be9bf we removed the only use of arch_type from blockdev.c.
The stub is therefore no longer needed, and we can delete it again,
together with the QEMU_ARCH
On 7/30/21 3:26 AM, Cai Huoqing wrote:
> Fix typo in comments:
> *programatically ==> programmatically
> *disconecting ==> disconnecting
> *mulitple ==> multiple
> *timout ==> timeout
> *regsiter ==> register
> *forumula ==> formula
>
> Signed-off-by: Cai Huoqing
> ---
> hw/vfio/igd.c
On 7/28/2021 12:56 AM, Zheng Chuan wrote:
> On 2021/7/8 1:20, Steve Sistare wrote:
>> Enable vfio-pci devices to be saved and restored across an exec restart
>> of qemu.
>>
>> [...]
>> --- a/migration/cpr.c
>> +++ b/migration/cpr.c
>> @@ -31,6 +31,13 @@
>> #include "hw/virtio/vhost.h"
>> #include
On 7/28/2021 12:56 AM, Zheng Chuan wrote:
> On 2021/7/20 2:38, Steven Sistare wrote:
>> On 7/19/2021 2:10 PM, Alex Williamson wrote:
>>> On Mon, 19 Jul 2021 13:44:08 -0400
>>> Steven Sistare wrote:
>>>
On 7/16/2021 4:51 PM, Alex Williamson wrote:
> On Wed, 7 Jul 2021 10:20:26 -0700
>
On Tue, 27 Jul 2021 18:04:09 +0100
Peter Maydell wrote:
> This patchset does a basic conversion of four ACPI related files in
> docs/specs from plain text to rST format. The aim of the conversion
> is not to produce a maximally pretty result, but simply to do a
> low-effort conversion that at le
On Tue, 27 Jul 2021 18:04:12 +0100
Peter Maydell wrote:
> Convert the PCI hotplug spec document to rST.
Julia,
This doc doesn't describe ACPI PCI hotplug we have now,
Care to update it?
> ---
> ...i_pci_hotplug.txt => acpi_pci_hotplug.rst} | 37 ++-
> docs/specs/index.rst
Hi, Steve
I have saw the discussion about the fork+exec mode below:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg815956.html
And I am still very curious and I want to discuss about the possibility to
support both fork+exec and exec in cpr framework.
1.Why
fork+exec could have some advan
On 7/29/21 7:55 PM, Eduardo Habkost wrote:
> Add two new subsection headings to make the separation between
> "declaration macros" and "definition macros" more visible.
>
> Signed-off-by: Eduardo Habkost
> ---
> docs/devel/qom.rst | 6 ++
> 1 file changed, 6 insertions(+)
Reviewed-by: Phili
On 7/30/21 12:59 PM, Peter Maydell wrote:
> Instead of using an ifdef ladder in arch_init.c (which we then have
> to manually update every time we add or remove a target
> architecture), have meson.build put "#define QEMU_ARCH QEMU_ARCH_FOO"
> in the config-target.h file.
>
> Signed-off-by: Peter
On 7/30/21 12:59 PM, Peter Maydell wrote:
> When Hexagon was added we forgot to add it to the QEMU_ARCH_*
> enumeration. This doesn't cause a visible effect because at the
> moment Hexagon is linux-user only and the QEMU_ARCH_* constants are
> only used in softmmu, but we might as well add it in,
On 7/30/21 12:59 PM, Peter Maydell wrote:
> arch_init.h only defines the QEMU_ARCH_* enumeration and the
> arch_type global. Don't include it in files that don't use those.
>
> Signed-off-by: Peter Maydell
> ---
> blockdev.c| 1 -
> hw/i386/pc.c | 1 -
> hw/i386/pc_p
On 7/30/21 12:59 PM, Peter Maydell wrote:
> We added a stub for the arch_type global in commit 5964ed56d9a1 so
> that we could compile blockdev.c into the tools. However, in commit
> 9db1d3a2be9bf we removed the only use of arch_type from blockdev.c.
> The stub is therefore no longer needed, and w
Cc'ing qemu-ppc@
On 7/30/21 6:25 AM, Lindsay Ryan wrote:
> Hi
> I'm trying to emulate some physical IBM Power 9's that we have. There
> seems to be plenty of examples of using x86_64 qemu, but slightly less
> for Power. Unless it's specifically for installing AIX
> Anyway, I'm trying to boot the V
On 7/30/21 3:49 AM, Cai Huoqing wrote:
> Fix typo:
> *Unknwon ==> Unknown
> *futher ==> further
> *configed ==> configured
>
> Signed-off-by: Cai Huoqing
> ---
> hw/i386/intel_iommu.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On 7/29/21 3:19 PM, Ani Sinha wrote:
> There is no need to use fresh typecasts to get references to pci device
> structs
> when there is an existing reference to pci device struct. Use existing
> reference.
> Minor cleanup.
>
> Signed-off-by: Ani Sinha
> ---
> hw/acpi/pcihp.c | 6 +++---
> 1 f
On Fri, Jul 30, 2021 at 09:49:42AM +0800, Cai Huoqing wrote:
> Fix typo:
> *Unknwon ==> Unknown
> *futher ==> further
> *configed ==> configured
>
> Signed-off-by: Cai Huoqing
Acked-by: Peter Xu
--
Peter Xu
Hello,
This series removes passing arguments to plugins through "arg=" since
it's redundant and reduces readability especially when the argument
itself is composed of a name and a value.
Also, passing arguments through "arg=" still works but is marked as
deprecated and will produce a deprecation
Passing arguments to plugins had to be done through "arg=".
This is redundant and introduces confusion especially when the argument
has a name and value (e.g. `-plugin plugin_name,arg="argname=argvalue"`).
This allows passing plugin arguments directly e.g:
`-plugin plugin_name,argname=argvalu
Since plugin arguments now expect boolean arguments, a plugin argument
name "sortby" now expects a value of "read", "write", or "address".
"io" arg is now expected to be passed as a full-form boolean parameter,
i.e. "io=on|true|yes|off|false|no"
Signed-off-by: Mahmoud Mandour
Reviewed-by: Alex B
Signed-off-by: Mahmoud Mandour
Reviewed-by: Alex Bennée
---
contrib/plugins/lockstep.c | 31 ++-
docs/devel/tcg-plugins.rst | 2 +-
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/contrib/plugins/lockstep.c b/contrib/plugins/lockstep.c
index 7fd35eb6
This call will help boolean argument parsing since arguments are now
passed to plugins as a name and value.
Signed-off-by: Mahmoud Mandour
---
include/qemu/qemu-plugin.h | 13 +
plugins/api.c | 5 +
2 files changed, 18 insertions(+)
diff --git a/include/qemu/qemu-p
Signed-off-by: Mahmoud Mandour
Reviewed-by: Alex Bennée
---
contrib/plugins/hotblocks.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/contrib/plugins/hotblocks.c b/contrib/plugins/hotblocks.c
index 4b08340143..062200a7a4 100644
--- a/contrib/plugins/hotblock
Correctly parsing plugin argument since they now must be provided as
full-form boolean parameters, e.g.:
-plugin ./contrib/plugins/libhowvec.so,verbose=on,inline=on
Also, introduced the argument "count" that accepts one opt to count
individually at a time.
Signed-off-by: Mahmoud Mandour
Revi
Parsing boolean arguments correctly (e.g. pattern=on or source=false).
Introduced a new "track" argument that takes a [read|write] value. This
substitutes passing read or write to "arg=" that is deprecated.
Also, matches are now taken one by one through the "match" argument.
Signed-off-by: Mahmou
This commit makes the plugin adhere to the new plugins arg-passing
scheme by expecting full-form boolean args instead of short-form
booleans. This necessitates that we introduce a new argument, here
"track", to accept "r", "w", or "rw".
Also, it makes arguments not positional and we only care abou
Signed-off-by: Mahmoud Mandour
Reviewed-by: Alex Bennée
---
docs/devel/tcg-plugins.rst | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 9377bc51d8..7b1a3921b6 100644
--- a/docs/devel/tcg-plugins.r
Signed-off-by: Mahmoud Mandour
Reviewed-by: Alex Bennée
---
tests/plugin/syscall.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/tests/plugin/syscall.c b/tests/plugin/syscall.c
index 6dd71092e1..484b48de49 100644
--- a/tests/plugin/syscall.c
+++ b/t
Signed-off-by: Mahmoud Mandour
Reviewed-by: Alex Bennée
---
tests/plugin/bb.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tests/plugin/bb.c b/tests/plugin/bb.c
index de09bdde4e..7d470a1011 100644
--- a/tests/plugin/bb.c
+++ b/tests/plugin/bb.c
@@ -104,10
Signed-off-by: Mahmoud Mandour
---
docs/system/deprecated.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index e2e0090878..7ae6f1f727 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -126,6 +126,13
Made argument "inline" not positional, this has two benefits. First is
that we adhere to how QEMU passes args generally, by taking the last
value of an argument and drop the others. And the second is that this
sets up a framework for potentially adding new args easily.
Signed-off-by: Mahmoud Mando
That doesn't seem good to stop handling io when guest is still running.
For example it leads to the following:
After bdrv_drain_all_begin(), during vm_shutdown() scsi_dma_writev()
calls blk_aio_pwritev(). As we are in drained section the request waits
in blk_wait_while_drained().
Next, during bdr
The container already features meson and ninja, so there is no need
to try to install it with dnf again.
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/buildtest.yml | 2 --
1 file changed, 2 deletions(-)
diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index f390f98044..38f084
Both jobs are testing more or less the same thing (building QEMU with
features disabled), so we are wasting precious CI cycles here by doing
this twice. Merge the jobs by using --without-default-features by default
and just adding some additional --disable-... switches which are not
covered by the
The patch that recently introduced the S390X_RUNNER_AVAILABLE variable
in custom-runners.yml missed that the bottom half of the file is rather
about aarch64 than s390x. Thus rename the S390X_RUNNER_AVAILABLE to
AARCH64_RUNNER_AVAILABLE in those jobs.
Finally mention both variables in our CI docume
Here are three patches for some small issues that I noticed in our
gitlab-CI files recently...
Thomas Huth (3):
gitlab-ci: Merge "build-disabled" with "build-without-default-features"
gitlab-ci: Remove superfluous "dnf install" statement
gitlab-ci: Fix ..._RUNNER_AVAILABLE variables and docu
On Thu Jul 29, 2021 at 2:31 PM CDT, Dov Murik wrote:
> The OVMF companion series has been reviewed by the new OVMF maintainer
> and merged to edk2 master branch as of edk2 commit 514b3aa08ece [1].
>
> [1] https://github.com/tianocore/edk2/commit/514b3aa08ece
Awesome! Unfortunately, it's looking li
On 7/30/21 4:38 PM, Thomas Huth wrote:
> The patch that recently introduced the S390X_RUNNER_AVAILABLE variable
> in custom-runners.yml missed that the bottom half of the file is rather
> about aarch64 than s390x. Thus rename the S390X_RUNNER_AVAILABLE to
> AARCH64_RUNNER_AVAILABLE in those jobs.
Once we let lo_inode.fd be optional, we will need its users to open the
file handle stored in lo_inode instead. This function will do that.
For now, it just returns lo_inode.fd, though.
Signed-off-by: Max Reitz
---
tools/virtiofsd/passthrough_ll.c | 150 +--
1 file
We only need to drop/switch our credentials for the (f)setxattr() call
alone, not for the openat() or fchdir() around it.
(Right now, this may not be that big of a problem, but with inodes being
identified by file handles instead of an O_PATH fd, we will need
open_by_handle_at() calls here, which
Accessing lo_inode.fd must generally happen through lo_inode_fd(), and
lo_fd() is no exception; and then it must pass on the TempFd it has
received from lo_inode_fd().
(Note that all lo_fd() calls now use proper error handling, where all of
them were in-line before; i.e. they were used in place of
Currently, lo_inode.fhandle is always NULL and so always keep an O_PATH
FD in lo_inode.fd. Therefore, when the respective inode is unlinked,
its inode ID will remain in use until we drop our lo_inode (and
lo_inode_put() thus closes the FD). Therefore, lo_find() can safely use
the inode ID as an l
Hi,
v1 cover letter for an overview:
https://listman.redhat.com/archives/virtio-fs/2021-June/msg00033.html
v2 cover letter:
https://listman.redhat.com/archives/virtio-fs/2021-June/msg00074.html
For v3, at first I attempted to have errors related to file handle
generation (name_to_handle_at()) be
This new field is an alternative to lo_inode.fd: Either of the two must
be set. In case an O_PATH FD is needed for some lo_inode, it is either
taken from lo_inode.fd, if valid, or a temporary FD is opened with
open_by_handle_at().
Using a file handle instead of an FD has the advantage of keeping
The xattr functions want a non-O_PATH FD, so they reopen the lo_inode.fd
with the flags they need through /proc/self/fd.
Similarly, lo_opendir() needs an O_RDONLY FD. Instead of the
/proc/self/fd trick, it just uses openat(fd, "."), because the FD is
guaranteed to be a directory, so this works.
We are planning to add file handles to lo_inode objects as an
alternative to lo_inode.fd. That means that everywhere where we
currently reference lo_inode.fd, we will have to open a temporary file
descriptor that needs to be closed after use.
So instead of directly accessing lo_inode.fd, there wi
When the inode_file_handles option is set, try to generate a file handle
for new inodes instead of opening an O_PATH FD.
Being able to open these again will require CAP_DAC_READ_SEARCH, so the
description text tells the user they will also need to specify
-o modcaps=+dac_read_search.
Generating a
lo_find() right now takes two lookup keys for two maps, namely the file
handle for inodes_by_handle and the statx information for inodes_by_ids.
However, we only need the statx information if looking up the inode by
the file handle failed.
There are two callers of lo_find(): The first one, lo_do_l
Strictly speaking, this is not necessary, because lo_inode_open() will
always return a new FD owned by the caller, so TempFd.owned will always
be true.
However, auto-cleanup is nice, and in some cases this plays nicely with
an lo_inode_fd() call in another conditional branch (see lo_setattr()).
S
Just making sure Cedric is also seeing this...
-Klaus
On Fri, Jul 30, 2021 at 10:27 AM Philippe Mathieu-Daudé
wrote:
> Cc'ing qemu-ppc@
>
> On 7/30/21 6:25 AM, Lindsay Ryan wrote:
> > Hi
> > I'm trying to emulate some physical IBM Power 9's that we have. There
> > seems to be plenty of example
On 29.07.21 18:29, Vladimir Sementsov-Ogievskiy wrote:
29.07.2021 16:47, Max Reitz wrote:
On 29.07.21 13:35, Vladimir Sementsov-Ogievskiy wrote:
29.07.2021 13:38, Max Reitz wrote:
On 29.07.21 12:02, Vladimir Sementsov-Ogievskiy wrote:
28.07.2021 10:00, Max Reitz wrote:
On 27.07.21 18:47, Vla
"make check-acceptance" takes way way too long. I just did a run
on an arm-and-aarch64-targets-only debug build and it took over
half an hour, and this despite it skipping or cancelling 26 out
of 58 tests!
I think that ~10 minutes runtime is reasonable. 30 is not;
ideally no individual test would
On 27.07.21 21:04, Dr. David Alan Gilbert wrote:
* David Hildenbrand (da...@redhat.com) wrote:
Let's simplify the case when we only want a single thread and don't have
to mess with signal handlers.
Signed-off-by: David Hildenbrand
---
util/oslib-posix.c | 8
1 file changed, 8 inser
Unlike A-profile, for M-profile the UDIV and SDIV insns can be
configured to raise an exception on division by zero, using the CCR
DIV_0_TRP bit. This patchset implements that missing functionality
by having the udiv and sdiv helpers raise an exception if needed.
Some questions:
Is it worth allo
We're about to make a code change to the sdiv and udiv helper
functions, so first fix their indentation and coding style.
Signed-off-by: Peter Maydell
---
target/arm/helper.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/help
Unlike A-profile, for M-profile the UDIV and SDIV insns can be
configured to raise an exception on division by zero, using the CCR
DIV_0_TRP bit.
Implement support for setting this bit by making the helper functions
raise the appropriate exception.
Signed-off-by: Peter Maydell
---
target/arm/cp
I agree, making these manual tasks until we find a fix for this is the
only solution I can think of too.
Daniele
On 7/28/2021 3:51 AM, Thomas Huth wrote:
These two jobs are currently failing very often - the linker seems to
get killed due to out-of-memory problems. Since apparently nobody has
On 7/30/21 5:12 PM, Peter Maydell wrote:
> "make check-acceptance" takes way way too long. I just did a run
> on an arm-and-aarch64-targets-only debug build and it took over
> half an hour, and this despite it skipping or cancelling 26 out
> of 58 tests!
>
> I think that ~10 minutes runtime is rea
On Fri, 30 Jul 2021 at 16:12, Peter Maydell wrote:
>
> "make check-acceptance" takes way way too long. I just did a run
> on an arm-and-aarch64-targets-only debug build and it took over
> half an hour, and this despite it skipping or cancelling 26 out
> of 58 tests!
>
> I think that ~10 minutes ru
Hello there.
I'm a student and I'm writing my term paper. Part of it is the record
the trace of x86 ELF on x86_64 Linux. For record I use PANDA. And I
stacked with very strange problem: there is no system calls in my trace.
When I see this I was very surprised and make simple grabber of
transl
On Fri, 30 Jul 2021 at 17:19, Nikita Gnilozub-Volobuev
wrote:
> I'm a student and I'm writing my term paper. Part of it is the record
> the trace of x86 ELF on x86_64 Linux. For record I use PANDA.
Hi; PANDA is based on a fork of an older version of QEMU, with
considerable alterations. You are pr
Hello,
On 7/30/21 3:25 PM, Philippe Mathieu-Daudé wrote:
> Cc'ing qemu-ppc@
>
> On 7/30/21 6:25 AM, Lindsay Ryan wrote:
>> Hi
>> I'm trying to emulate some physical IBM Power 9's that we have. There
>> seems to be plenty of examples of using x86_64 qemu, but slightly less
>> for Power.
For bare
1 - 100 of 180 matches
Mail list logo
